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

From tschatzl at openjdk.org  Tue Oct  7 20:13:36 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 7 Oct 2025 20:13:36 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v2]
In-Reply-To: <XdIf5AMddR6zeFngh7Oqv9hXV1j92utMQobDI5M8Nk4=.d43b2e34-b130-4b2b-9304-2d5d45259ff0@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
 <XdIf5AMddR6zeFngh7Oqv9hXV1j92utMQobDI5M8Nk4=.d43b2e34-b130-4b2b-9304-2d5d45259ff0@github.com>
Message-ID: <XhbDycaQTaU4o8WbMGaRL_52o2x0d8Tysm4mvjQCMIA=.a3750b66-fa38-4909-8dae-36bcf9963479@github.com>

On Fri, 26 Sep 2025 13:27:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Just a random comment: why are the locations of young gen and old gen swapped in Serial and Parallel, is there a reason? (Functionally it does not seem so).

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

PR Comment: https://git.openjdk.org/jdk/pull/27513#issuecomment-3360275835

From kdnilsen at openjdk.org  Tue Oct  7 20:40:42 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 20:40:42 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: <NC5KbBoZQkqnB-3BF-m4h53CAp_s9-jDA8uycxQq148=.346e0f4e-812f-4d54-9b55-33220167aae5@github.com>

On Thu, 2 Oct 2025 23:39:32 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/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?

Removed.

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

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

From wkemper at openjdk.org  Tue Oct  7 21:18:06 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 7 Oct 2025 21:18:06 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: <Z5RQ4VmAs4E3MnqKk5waMvvXN022mE2cmvp8-g0Khps=.08ad3d03-08f8-4479-ae3f-91c7cecd68e0@github.com>

On Mon, 6 Oct 2025 22:35: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/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.)

I called the complementary method `get_live_bytes_in_tenurable_regions`. How about `get_live_bytes_in_untenurable_regions`?

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

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

From kdnilsen at openjdk.org  Tue Oct  7 21:50:03 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 21:50:03 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: <Us7LDKqzId8bo1c-Mwt9tecybaK6Og0E5n05UFuxiEs=.84a82eac-dd49-444d-b4b3-94b25b4b1527@github.com>

On Thu, 2 Oct 2025 23:43:00 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/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?

Removing that one.  Don't know what I was thinking...

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

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

From kdnilsen at openjdk.org  Tue Oct  7 21:54:39 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 21:54:39 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: <_ifVkS55O5eNYo5e3b-qu8F026vovEWlyOyRLbnF5Vs=.56aab75a-0a4f-4c07-8caf-8c1489e7ec94@github.com>

On Thu, 2 Oct 2025 23:48:43 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/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`?

It should be that way.  Yes.  But we have been known to violate these conditions, especially when unsigned arithmetic underflows (i.e. small_unsigned_value - large_unsigned_value yields really big unsigned_value)

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

I've reverted this change.  In a different PR, we might decide to address this in a different way.  We have multiple typedefs for idx_t even within the shenandoah development directory..

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

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

From kdnilsen at openjdk.org  Tue Oct  7 22:00:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 22:00:22 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v19]
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: <5UAnGN3TiTYZSVcLUKLq-WIrpi3_h6rBAMhdcer6lxQ=.6b299e43-1166-4dc6-b258-3c3b30b5d292@github.com>

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

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary methods
>
> 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?

ShenandoahHeap::initialize() makes use of SoftMaxHeapSize.  If the SoftMaxHeapSizeConstraintFunc is handled "after memory init", the value of SoftMaxHeapSize is not yet available when we try to use it.

I welcome an alternative approach if you have any ideas.

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

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

From kdnilsen at openjdk.org  Tue Oct  7 22:00:26 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 22:00:26 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: <AIfMpTKxvHe0Vs-YaOnPgitCd5Snlf6e2Xe3L27KR7o=.42e013ef-11d5-4e20-a0a1-ce638661e811@github.com>

On Thu, 2 Oct 2025 23:55:42 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/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

I've fixed this here, and in neighboring declarations of same file.

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

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

From kdnilsen at openjdk.org  Tue Oct  7 22:07:10 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 22:07:10 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v14]
In-Reply-To: <7gs_aeIVgmVkDT5AkqMAd5zn-1bfcIHkwYY5ZbvObFA=.ae5e7d12-1cc2-4521-b408-8a2e7b3829a5@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <ow6Nd42Z36Qmu32f4wV67tJWjEHAT296eTExYs83VMw=.5066c6b9-882d-4ec4-a2ac-b1c661965ebd@github.com>
 <j80QwLMBFP9sHusg37FaUpTaR-rBKPL8yAeDpzJbVD4=.b4eb3185-eeb2-4a5b-921a-d8a03fdf507b@github.com>
 <7gs_aeIVgmVkDT5AkqMAd5zn-1bfcIHkwYY5ZbvObFA=.ae5e7d12-1cc2-4521-b408-8a2e7b3829a5@github.com>
Message-ID: <c0RIqHPNAES2lT8b_n1HtJmMiKAmIEHlSFsj3tK1T9s=.1ce2dfbb-d6c2-43e7-8066-da274cd1e988@github.com>

On Tue, 7 Oct 2025 22:03:34 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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.
>
> After review, I think it is appropriate that the argument type be declared idx_t.

After review of context, I believe it is appropriate that these arguments be declared idx_t.

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

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

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

On Fri, 3 Oct 2025 21:54:32 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

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

After review, I think it is appropriate that the argument type be declared idx_t.

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

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

From wkemper at openjdk.org  Tue Oct  7 22:24:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 7 Oct 2025 22:24:18 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: <c0deYfp9H2MYnX0BdsFulINUNVf5gknuI1YWDjtYZ5M=.fc3d8376-d381-43fd-896d-c0fefa5ab607@github.com>

On Mon, 6 Oct 2025 23:17:01 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 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.)

In `compute_evacuation_reserves` we are setting the promotion reserve to the maximum possible to handle everything tenurable this cycle (this is still capped by the maximum evacuation reserve for old). I was reluctant to scale the promotion reserve by `ShenandoahPromoEvacWaste`  for fear it would over commit the collector's reserves and lead to OOM errors during evacuation.

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

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

From wkemper at openjdk.org  Tue Oct  7 22:32:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 7 Oct 2025 22:32:56 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v4]
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: <u9GVAOeNkg5TL2dBBEWLDZNrMvxBYlFdUeXdRQl1VIs=.4e1ebef5-8a2c-49f8-974a-15d840ad75eb@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:

  Review feedback, bug fixes

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

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

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

  Stats: 58 lines in 6 files changed: 26 ins; 18 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/27632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27632/head:pull/27632

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

From kdnilsen at openjdk.org  Tue Oct  7 22:56:27 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 22:56:27 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v20]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <p59HL6-4KhstauMHwLDFf7PTTK1RlzSfHvfWMwRxYAU=.85d8fbb8-4db0-46bb-adf6-1fc929fb77b8@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 four additional commits since the last revision:

 - add override to method declaration
 - remove unneeded variables from ShenandoahGeneration
 - fix indentation
 - remove meaningless assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/26a516ca..4db0cbe4

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

  Stats: 42 lines in 11 files changed: 0 ins; 20 del; 22 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 23:44:32 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 23:44:32 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v4]
In-Reply-To: <c0deYfp9H2MYnX0BdsFulINUNVf5gknuI1YWDjtYZ5M=.fc3d8376-d381-43fd-896d-c0fefa5ab607@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>
 <c0deYfp9H2MYnX0BdsFulINUNVf5gknuI1YWDjtYZ5M=.fc3d8376-d381-43fd-896d-c0fefa5ab607@github.com>
Message-ID: <7xGe1GZZMDQlU380bkZlAGkgMsI-Q_jRD6qSVJrM664=.640873a9-2c9d-4297-b64b-ec74c7819442@github.com>

On Tue, 7 Oct 2025 22:21:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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.)
>
> In `compute_evacuation_reserves` we are setting the promotion reserve to the maximum possible to handle everything tenurable this cycle (this is still capped by the maximum evacuation reserve for old). I was reluctant to scale the promotion reserve by `ShenandoahPromoEvacWaste`  for fear it would over commit the collector's reserves and lead to OOM errors during evacuation.

So in the new design, we have full awareness of all promotable objects, and we've already done our best to budget for those.  So there's no such thing as "unanticipated promotions".

Separate question is whether we scale promotion reserve by ShenandoahPromoEvacWaste.  So if old is larger than necessary to handle the anticipated mixed evacuations and promotions, the new code is essentially saying "use this extra space for mixed evacuations rather than for promotions".   Since we're not expanding the promoted_reserve, promotions will not be allowed to touch it.

Am I understanding the intent correctly?

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

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

From kdnilsen at openjdk.org  Tue Oct  7 23:48:52 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 7 Oct 2025 23:48:52 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v3]
In-Reply-To: <Z5RQ4VmAs4E3MnqKk5waMvvXN022mE2cmvp8-g0Khps=.08ad3d03-08f8-4479-ae3f-91c7cecd68e0@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>
 <Z5RQ4VmAs4E3MnqKk5waMvvXN022mE2cmvp8-g0Khps=.08ad3d03-08f8-4479-ae3f-91c7cecd68e0@github.com>
Message-ID: <mBD0mE_1BcCRgJR137CEPOZPSRby8JNsFJJK3F_35Co=.5026848f-dc37-4897-b5c4-66d75309e4f6@github.com>

On Tue, 7 Oct 2025 21:15:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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.)
>
> I called the complementary method `get_live_bytes_in_tenurable_regions`. How about `get_live_bytes_in_untenurable_regions`?

I'm still maybe a bit confused.  Is it get_untenurable_live_bytes_in_young_regions()?  Are we distinguishing?

So we have a total of N live bytes within young regions that have been placed into the collection set.  We expect that P bytes (P < N) will be promoted, and the remaining S bytes (S + P == N) will be evacuated to "survivor space" within young.

Does get_live_bytes_in_untenurable_regions() equal P + S?

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

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

From tschatzl at openjdk.org  Wed Oct  8 07:53:11 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 07:53:11 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: <8ylD16cDLJJCp50DLei-HwFiIyTOdmUbb66jAo_Rw0w=.d678136b-82c7-478d-997e-d2ea8b6317c1@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 tschatzl (Reviewer).

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

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

From azafari at openjdk.org  Wed Oct  8 08:32:34 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Wed, 8 Oct 2025 08:32:34 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: <jsShxguBAG7oDcQgEi4aXSTuVtsg2qtegr96pDw4NRg=.e16de8c5-9ab1-445b-b44b-acf948ce6318@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

Dear @dholmes-ora, other reviewers want to receive more comments here. Would you please step in. TIA

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

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3380352929

From lkorinth at openjdk.org  Wed Oct  8 09:03:41 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 8 Oct 2025 09:03:41 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: <dLGSU4vsfYcRe8LLoexyVDSg9XwxBoT9NxdIoloc7Yo=.eea4ce6d-2789-4336-a446-125200686136@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

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

> 1110:   return (size_t)MIN2(value, (T)std::numeric_limits<size_t>::max());
> 1111: }
> 1112: 

Maybe something more generic like this:

// return the value of B clamped by the numeric limits of S, casted to S
template<class S, class B>
S clamp_into_from(B value) {
  static_assert(std::numeric_limits<B>::min() <= std::numeric_limits<S>::min(), "make sure the big type min can hold the small type min");
  static_assert(std::numeric_limits<B>::max() >= std::numeric_limits<S>::max(), "make sure the big type max can hold the small type max");
  B v = clamp<B>(value, std::numeric_limits<S>::min(), std::numeric_limits<S>::max());
  return static_cast<S>(v);
}

and place it after clamp?

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

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

From ayang at openjdk.org  Wed Oct  8 09:32:29 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 09:32:29 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: <X-Ru58Xm6uzUl0a9q6qdtvM8HL7_TzCcT02hY3NptSY=.75019347-1e90-451e-ba59-5602af42fd2f@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

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27671#issuecomment-3380642268

From ayang at openjdk.org  Wed Oct  8 09:32:31 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 09:32:31 GMT
Subject: Integrated: 8369277: Remove unused
 CodeCacheUnloadingTask::_num_workers
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: <nmOMJZw5GLdSybTnLSMSx1weFckdUli9vJ1ZwIDEzxE=.7789af4f-58d5-427e-a3a7-e750131389de@github.com>

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

> Trivial removing dead code.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: c6695064
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c66950643e4f43b5997b223289eefdde589589fa
Stats:     16 lines in 8 files changed: 0 ins; 8 del; 8 mod

8369277: Remove unused CodeCacheUnloadingTask::_num_workers

Reviewed-by: shade, tschatzl

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

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

From lkorinth at openjdk.org  Wed Oct  8 09:49:29 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 8 Oct 2025 09:49:29 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5]
In-Reply-To: <dLGSU4vsfYcRe8LLoexyVDSg9XwxBoT9NxdIoloc7Yo=.eea4ce6d-2789-4336-a446-125200686136@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
 <dLGSU4vsfYcRe8LLoexyVDSg9XwxBoT9NxdIoloc7Yo=.eea4ce6d-2789-4336-a446-125200686136@github.com>
Message-ID: <SieffH__AFxLHgyelj8R7K-vIZmPPOqvGNCeqRxoOw4=.57c85a8e-ceed-49df-9192-994bf4f0d614@github.com>

On Wed, 8 Oct 2025 09:00:39 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> 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
>
> src/hotspot/share/utilities/globalDefinitions.hpp line 1112:
> 
>> 1110:   return (size_t)MIN2(value, (T)std::numeric_limits<size_t>::max());
>> 1111: }
>> 1112: 
> 
> Maybe something more generic like this:
> 
> // return the value of B clamped by the numeric limits of S, casted to S
> template<class S, class B>
> S clamp_into_from(B value) {
>   static_assert(std::numeric_limits<B>::min() <= std::numeric_limits<S>::min(), "make sure the big type min can hold the small type min");
>   static_assert(std::numeric_limits<B>::max() >= std::numeric_limits<S>::max(), "make sure the big type max can hold the small type max");
>   B v = clamp<B>(value, std::numeric_limits<S>::min(), std::numeric_limits<S>::max());
>   return static_cast<S>(v);
> }
> 
> and place it after clamp?

I think my proposal is not optimal, please instead specialize your method to uint64_t and place it in arguments.cpp.

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

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

From jsikstro at openjdk.org  Wed Oct  8 09:57:38 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 8 Oct 2025 09:57:38 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v6]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <uPSdqRB8qVZXey2VKbVcvhH_AO0I3W1o1GwX7BY7LJU=.9c46adb4-311a-4ddf-a1a7-94012eae7603@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:

  Make limit_by_size_t_max to a static function in arguments.cpp

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

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

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

  Stats: 10 lines in 2 files changed: 4 ins; 6 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 jsikstro at openjdk.org  Wed Oct  8 09:57:39 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 8 Oct 2025 09:57:39 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v5]
In-Reply-To: <SieffH__AFxLHgyelj8R7K-vIZmPPOqvGNCeqRxoOw4=.57c85a8e-ceed-49df-9192-994bf4f0d614@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <d9an5CGCKrvOjqW7dAsFMaV_xwXJvIefYfKemQSnaak=.b2014068-c794-40dd-8114-1faf2f6eeaf2@github.com>
 <dLGSU4vsfYcRe8LLoexyVDSg9XwxBoT9NxdIoloc7Yo=.eea4ce6d-2789-4336-a446-125200686136@github.com>
 <SieffH__AFxLHgyelj8R7K-vIZmPPOqvGNCeqRxoOw4=.57c85a8e-ceed-49df-9192-994bf4f0d614@github.com>
Message-ID: <w3K3h5-_C-l38fBsFOoP1eUgJ2Rg-lV-h8Y3_PnF69U=.fe62b273-e210-4890-ae8b-1ff1dbc033bc@github.com>

On Wed, 8 Oct 2025 09:47:02 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions.hpp line 1112:
>> 
>>> 1110:   return (size_t)MIN2(value, (T)std::numeric_limits<size_t>::max());
>>> 1111: }
>>> 1112: 
>> 
>> Maybe something more generic like this:
>> 
>> // return the value of B clamped by the numeric limits of S, casted to S
>> template<class S, class B>
>> S clamp_into_from(B value) {
>>   static_assert(std::numeric_limits<B>::min() <= std::numeric_limits<S>::min(), "make sure the big type min can hold the small type min");
>>   static_assert(std::numeric_limits<B>::max() >= std::numeric_limits<S>::max(), "make sure the big type max can hold the small type max");
>>   B v = clamp<B>(value, std::numeric_limits<S>::min(), std::numeric_limits<S>::max());
>>   return static_cast<S>(v);
>> }
>> 
>> and place it after clamp?
>
> I think my proposal is not optimal, please instead specialize your method to uint64_t and place it in arguments.cpp.

I agree, let's make it local to arguments.cpp.

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

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

From ayang at openjdk.org  Wed Oct  8 10:56:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 10:56:03 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v2]
In-Reply-To: <XhbDycaQTaU4o8WbMGaRL_52o2x0d8Tysm4mvjQCMIA=.a3750b66-fa38-4909-8dae-36bcf9963479@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
 <XdIf5AMddR6zeFngh7Oqv9hXV1j92utMQobDI5M8Nk4=.d43b2e34-b130-4b2b-9304-2d5d45259ff0@github.com>
 <XhbDycaQTaU4o8WbMGaRL_52o2x0d8Tysm4mvjQCMIA=.a3750b66-fa38-4909-8dae-36bcf9963479@github.com>
Message-ID: <ODhllrAwIDJOFx49JlrvMYcbKGxTXn04RdWVUx5u8_Y=.5fef5b82-cb06-400d-9609-900f2ab06ac8@github.com>

On Thu, 2 Oct 2025 10:04:32 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> why are the locations of young gen and old gen swapped in Serial and Parallel

Placing old-gen first makes support for non-fixed gen-boundary easier, which ParallelGC used to have. Nowadays, the two layouts make little diff.

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

PR Comment: https://git.openjdk.org/jdk/pull/27513#issuecomment-3380955810

From ayang at openjdk.org  Wed Oct  8 11:05:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 11:05:44 GMT
Subject: RFR: 8369420: Parallel: Using multiple workers for class unloading
Message-ID: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>

Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.

Test: tier1-5

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

Commit messages:
 - pgc-class-unloading

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

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

From tschatzl at openjdk.org  Wed Oct  8 11:09:04 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 11:09:04 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: <Iyy8diRwj8Hh8rT3JjAXSCMLmq5KUDlWktBj3XDhScs=.1c94f700-9249-44f0-b3c1-292333b0cc07@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

Marked as reviewed by tschatzl (Reviewer).

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

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

From tschatzl at openjdk.org  Wed Oct  8 11:12:02 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 11:12:02 GMT
Subject: RFR: 8369097: Parallel: Support allocation in from space when heap
 is too full [v2]
In-Reply-To: <tEPyKb2hRrAVZqICMLhKWB1Uu8uw92ahSXCpAe2pDmI=.3f51ab7b-e6d2-4d9b-a826-725a386386ea@github.com>
References: <uEZ5wcprvd6EY5dh9ZI52Br4ybO9L3Z5CkldaEuh2wE=.b9e07a4d-c62e-473d-b502-d831cb2a5b7a@github.com>
 <tEPyKb2hRrAVZqICMLhKWB1Uu8uw92ahSXCpAe2pDmI=.3f51ab7b-e6d2-4d9b-a826-725a386386ea@github.com>
Message-ID: <I-dD6k1Xr4vy0NyxLT6XPQgAB6EDxwyLDHDwESy1E04=.3c87e1fb-372e-4a95-9d92-23fdcf1321d9@github.com>

On Tue, 7 Oct 2025 18:25:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Seems good.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27620#pullrequestreview-3314304123

From ayang at openjdk.org  Wed Oct  8 11:24:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 11:24:16 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: <JcpmwYaECteKm-YJcGQ4IH_VwQEEAxht8N607X54sIc=.8d4f7a5d-5935-45c0-afb8-e69371eda097@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

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27675#issuecomment-3381055090

From ayang at openjdk.org  Wed Oct  8 11:24:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 11:24:17 GMT
Subject: Integrated: 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: <r0yxVSevbkR5h2ZFEZa0IkC__eCyn6GCikL86qp0LW0=.dbebe25c-b880-467a-96ea-d0d62cbdc160@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

This pull request has now been integrated.

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

8369286: Parallel: Assertion failure in mutableNUMASpace

Reviewed-by: jsikstro, tschatzl

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

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

From ayang at openjdk.org  Wed Oct  8 11:25:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 11:25:05 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v6]
In-Reply-To: <uPSdqRB8qVZXey2VKbVcvhH_AO0I3W1o1GwX7BY7LJU=.9c46adb4-311a-4ddf-a1a7-94012eae7603@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <uPSdqRB8qVZXey2VKbVcvhH_AO0I3W1o1GwX7BY7LJU=.9c46adb4-311a-4ddf-a1a7-94012eae7603@github.com>
Message-ID: <-jc1OS_5p7LgxFY_YEeH_mHtBjGCFVrjiZ8uza8sWL8=.a6c5b1c8-79ed-4c6e-8ba2-03e18ee3dc77@github.com>

On Wed, 8 Oct 2025 09:57:38 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:
> 
>   Make limit_by_size_t_max to a static function in arguments.cpp

Marked as reviewed by ayang (Reviewer).

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

> 1508: static const size_t DefaultHeapBaseMinAddress = HeapBaseMinAddress;
> 1509: 
> 1510: static size_t limit_by_size_t_max(uint64_t value) {

I wonder if `clamp_by_size_t_max` sounds better. Up to you.

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

PR Review: https://git.openjdk.org/jdk/pull/27224#pullrequestreview-3314359536
PR Review Comment: https://git.openjdk.org/jdk/pull/27224#discussion_r2413529193

From shade at openjdk.org  Wed Oct  8 11:30:04 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 8 Oct 2025 11:30:04 GMT
Subject: RFR: 8264851: Shenandoah: Rework control loop mechanics to use
 timed waits
In-Reply-To: <ROt--V437nRJ09DJ3R4V1WSk02YAzeaf4LZZUTTR1V4=.65a89969-77d8-44f8-98d5-15ed704d3095@github.com>
References: <ROt--V437nRJ09DJ3R4V1WSk02YAzeaf4LZZUTTR1V4=.65a89969-77d8-44f8-98d5-15ed704d3095@github.com>
Message-ID: <u5sM-eaZqW5MJ2n7nUguON-bjGkCzJFzhv9QXubx_2g=.b5eedf86-1eea-4b59-914e-0575a8565946@github.com>

On Thu, 25 Sep 2025 20:35:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We use a similar mechanism in `shGenerationalControlThread` already. Using a timed wait allows the control thread to be woken up before the wait expires.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27502#pullrequestreview-3314374701

From jsikstro at openjdk.org  Wed Oct  8 11:32:44 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 8 Oct 2025 11:32:44 GMT
Subject: RFR: 8367413: Refactor types in Arguments::set_heap_size() [v7]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@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 limit_by_size_t_max to clamp_by_size_t_max

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27224/files
  - new: https://git.openjdk.org/jdk/pull/27224/files/b46d124e..47163464

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

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 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 lkorinth at openjdk.org  Wed Oct  8 11:45:06 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 8 Oct 2025 11:45:06 GMT
Subject: RFR: 8367413: Fix potential truncation error in
 Arguments::set_heap_size() [v7]
In-Reply-To: <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
Message-ID: <vzI8qkPsy51s_tH6Nd23IHgETBBFPUfYngsFZiY579I=.2a7be23b-a580-4fbe-8910-e02e09ec924a@github.com>

On Wed, 8 Oct 2025 11:32:44 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 limit_by_size_t_max to clamp_by_size_t_max

Looks very good to me.

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

Marked as reviewed by lkorinth (Reviewer).

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

From ayang at openjdk.org  Wed Oct  8 11:56:25 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 11:56:25 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v3]
In-Reply-To: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
Message-ID: <dGQ6VndiO9WBhOK8dHP8C66QHZ4Iu85NxO5_91iv81g=.37755591-00b8-42e0-9d59-4952f6d0c18f@github.com>

> Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full.
> 
> This is needed only when `UseAdaptiveSizePolicy` is on, because this is intended to avoid including extra OS-time in gc-pause-time tracking, used for young-gen resizing.
> 
> Test: tier1-3

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

 - sizet
 - Merge branch 'master' into pgc-os-free-mem
 - Merge branch 'master' into pgc-os-free-mem
 - review
 - Merge branch 'master' into pgc-os-free-mem
 - pgc-os-free-mem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27068/files
  - new: https://git.openjdk.org/jdk/pull/27068/files/f8449f31..2267e5c0

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

  Stats: 192898 lines in 2530 files changed: 149763 ins; 27094 del; 16041 mod
  Patch: https://git.openjdk.org/jdk/pull/27068.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27068/head:pull/27068

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

From fandreuzzi at openjdk.org  Wed Oct  8 12:44:32 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 8 Oct 2025 12:44:32 GMT
Subject: RFR: 8369420: Parallel: Using multiple workers for class unloading
In-Reply-To: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
Message-ID: <ymJE5iYiVrvlcEcuedL0vAPTagvzBJmHl-KW7OjOUy8=.188383d6-97e9-4bd7-a62c-b1737dcadf4d@github.com>

On Wed, 8 Oct 2025 10:58:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
> 
> Test: tier1-5

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1167:

> 1165: 
> 1166: public:
> 1167:   PSParallelCleaningTask(uint num_workers,

Is `num_workers` used somewhere?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27689#discussion_r2413729656

From ayang at openjdk.org  Wed Oct  8 13:05:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 13:05:15 GMT
Subject: RFR: 8369420: Parallel: Using multiple workers for class unloading
 [v2]
In-Reply-To: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
Message-ID: <o2Yps0bxLMQwnGnpYy0JEalMsvAXt1xeAmsysxLj3CI=.48276f89-56f7-457a-b84c-73239d31251e@github.com>

> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
> 
> Test: tier1-5

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27689/files
  - new: https://git.openjdk.org/jdk/pull/27689/files/85b2968a..93597b44

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

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

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

From fandreuzzi at openjdk.org  Wed Oct  8 13:11:19 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 8 Oct 2025 13:11:19 GMT
Subject: RFR: 8369420: Parallel: Using multiple workers for class unloading
 [v2]
In-Reply-To: <o2Yps0bxLMQwnGnpYy0JEalMsvAXt1xeAmsysxLj3CI=.48276f89-56f7-457a-b84c-73239d31251e@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
 <o2Yps0bxLMQwnGnpYy0JEalMsvAXt1xeAmsysxLj3CI=.48276f89-56f7-457a-b84c-73239d31251e@github.com>
Message-ID: <YSXYZKfUxDQYet7ZbqAh_g6bmq9eNPxpNVeTGlmV6I0=.20f54be5-13a2-43ae-84d4-102fd3a1ea33@github.com>

On Wed, 8 Oct 2025 13:05:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27689#pullrequestreview-3314740916

From ayang at openjdk.org  Wed Oct  8 13:14:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 13:14:35 GMT
Subject: RFR: 8367413: Fix potential truncation error in
 Arguments::set_heap_size() [v7]
In-Reply-To: <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
Message-ID: <Yx___8q4UiUlOeOP2oxSnqUkibpnxy4mLCJEF69Wsd8=.48969f18-0ff0-4120-a358-ceb30ac0049c@github.com>

On Wed, 8 Oct 2025 11:32:44 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 limit_by_size_t_max to clamp_by_size_t_max

Marked as reviewed by ayang (Reviewer).

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

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

From jsikstro at openjdk.org  Wed Oct  8 13:31:25 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 8 Oct 2025 13:31:25 GMT
Subject: RFR: 8367413: Fix potential truncation error in
 Arguments::set_heap_size() [v8]
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <BuvaA-UpQQXmiDgKc7lhM6T5C4btYD6QLW7-L-Xw6NM=.7e1851db-60d6-4d9d-9bf2-855ae89867d9@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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
 - Rename limit_by_size_t_max to clamp_by_size_t_max
 - Make limit_by_size_t_max to a static function in arguments.cpp
 - Rename ram_limit_set to has_ram_limit
 - Revert MaxRAM default removals, defer to future enhancement
 - 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.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/23fcbb0b...f5649cb7

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

Changes: https://git.openjdk.org/jdk/pull/27224/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27224&range=07
  Stats: 73 lines in 1 file changed: 18 ins; 6 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 tschatzl at openjdk.org  Wed Oct  8 14:11:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 14:11:03 GMT
Subject: RFR: 8369420: Parallel: Using multiple workers for class unloading
 [v2]
In-Reply-To: <o2Yps0bxLMQwnGnpYy0JEalMsvAXt1xeAmsysxLj3CI=.48276f89-56f7-457a-b84c-73239d31251e@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
 <o2Yps0bxLMQwnGnpYy0JEalMsvAXt1xeAmsysxLj3CI=.48276f89-56f7-457a-b84c-73239d31251e@github.com>
Message-ID: <TbC2mU1Xu9dqtegktO_WHePWfE42kjfO4JI2a0wEHIw=.b24d2d52-298f-43a3-8b98-72dcf495db21@github.com>

On Wed, 8 Oct 2025 13:05:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by tschatzl (Reviewer).

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1177:

> 1175:       // Serial work; only first worker.
> 1176:       // Clean JVMCI metadata handles.
> 1177:       JVMCI_ONLY(JVMCI::do_unloading(_unloading_occurred));

Potentially do not execute this if `EnableJVMCI` is false. Probably does not change a lot.

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

PR Review: https://git.openjdk.org/jdk/pull/27689#pullrequestreview-3315000652
PR Review Comment: https://git.openjdk.org/jdk/pull/27689#discussion_r2413988771

From tschatzl at openjdk.org  Wed Oct  8 14:24:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 14:24:03 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: <7v5S0BxHxHnGL2FjldX-4eN-d7T-IFwRUBUNR0V3uy0=.0bf6fe46-9ba1-4e9c-b803-2e5447164461@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).

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27644#pullrequestreview-3315062162

From fandreuzzi at openjdk.org  Wed Oct  8 14:24:04 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 8 Oct 2025 14:24:04 GMT
Subject: Integrated: 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: <gcdV8tyaKiT40udUJokpKWjebAPQ-HCfGLcWlUiDPoU=.87c05e13-3d71-4403-b0bb-4279a3074430@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).

This pull request has now been integrated.

Changeset: 927aa3f8
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/927aa3f8da34fb71b692661bebb89d20bfa85648
Stats:     53 lines in 8 files changed: 7 ins; 39 del; 7 mod

8369178: G1: Use NMethodMarkingScope and ThreadsClaimTokenScope in G1RootProcessor

Reviewed-by: ayang, tschatzl

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

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

From ayang at openjdk.org  Wed Oct  8 14:38:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 8 Oct 2025 14:38:44 GMT
Subject: RFR: 8369420: Parallel: Use multiple workers for class unloading
 [v3]
In-Reply-To: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
Message-ID: <cPmugAtIvwNzWGvT4kR-pzV-UJQxo5C8-wnEgML36GA=.03530600-d91a-428e-a79b-2c2b757e445c@github.com>

> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
> 
> Test: tier1-5

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27689/files
  - new: https://git.openjdk.org/jdk/pull/27689/files/93597b44..4ab4e65d

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

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

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

From tschatzl at openjdk.org  Wed Oct  8 14:49:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 14:49:45 GMT
Subject: RFR: 8369420: Parallel: Use multiple workers for class unloading
 [v3]
In-Reply-To: <cPmugAtIvwNzWGvT4kR-pzV-UJQxo5C8-wnEgML36GA=.03530600-d91a-428e-a79b-2c2b757e445c@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
 <cPmugAtIvwNzWGvT4kR-pzV-UJQxo5C8-wnEgML36GA=.03530600-d91a-428e-a79b-2c2b757e445c@github.com>
Message-ID: <SER9rELP8v2L8RE7mAfg3ammB-5a-WA1D8CkjUMyDGA=.848116ab-63fc-4db1-8665-b0f17c900fa4@github.com>

On Wed, 8 Oct 2025 14:38:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27689#pullrequestreview-3315196576

From fandreuzzi at openjdk.org  Wed Oct  8 14:53:54 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 8 Oct 2025 14:53:54 GMT
Subject: RFR: 8369420: Parallel: Use multiple workers for class unloading
 [v3]
In-Reply-To: <cPmugAtIvwNzWGvT4kR-pzV-UJQxo5C8-wnEgML36GA=.03530600-d91a-428e-a79b-2c2b757e445c@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
 <cPmugAtIvwNzWGvT4kR-pzV-UJQxo5C8-wnEgML36GA=.03530600-d91a-428e-a79b-2c2b757e445c@github.com>
Message-ID: <hSsLgGxgMbu0SFkzWCuzFiwvuEA7alxoisPJaY_6oB0=.37adc2a6-fc0b-4095-80c4-d5aa0eef1be7@github.com>

On Wed, 8 Oct 2025 14:38:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27689#pullrequestreview-3315220655

From zgu at openjdk.org  Wed Oct  8 15:30:17 2025
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 8 Oct 2025 15:30:17 GMT
Subject: RFR: 8369420: Parallel: Use multiple workers for class unloading
 [v3]
In-Reply-To: <cPmugAtIvwNzWGvT4kR-pzV-UJQxo5C8-wnEgML36GA=.03530600-d91a-428e-a79b-2c2b757e445c@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
 <cPmugAtIvwNzWGvT4kR-pzV-UJQxo5C8-wnEgML36GA=.03530600-d91a-428e-a79b-2c2b757e445c@github.com>
Message-ID: <nHPBB7wj6uk-NNfSLgQbZ_Hp_TIAAs8MExeEiNZvTGg=.999b5de5-31c3-48c6-9de0-83ab93a5e871@github.com>

On Wed, 8 Oct 2025 14:38:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

LGTM

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

Marked as reviewed by zgu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27689#pullrequestreview-3315406059

From fandreuzzi at openjdk.org  Wed Oct  8 15:47:24 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 8 Oct 2025 15:47:24 GMT
Subject: RFR: 8369433: G1: Replace G1MarkScope with NMethodMarkingScope
Message-ID: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>

Replacing `G1MarkScope` with `NMethodMarkingScope`, since they have equivalent implementations.

Passes tier1 and tier2 (fastdebug).

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

Commit messages:
 - replace

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

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

From tschatzl at openjdk.org  Wed Oct  8 15:53:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 15:53:28 GMT
Subject: RFR: 8048180: Eager reclaim of humongous objects with references
 [v2]
In-Reply-To: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
Message-ID: <DfqY-7nz1gC99XftU2P_6HC9m0fl030863TiqbGMiZU=.c8a91493-75bb-46aa-be7e-43e3e76aa123@github.com>

> Hi all,
> 
>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
> 
> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
> 
> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
> 
> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
> 
> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>  
> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
> 
> Testing: new test cases, gha, tier1-5
> 
> Thanks,
>   Thomas

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

  * walulyai review, improved comments, example

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27525/files
  - new: https://git.openjdk.org/jdk/pull/27525/files/153f0a9d..44c62fcb

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

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

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

From tschatzl at openjdk.org  Wed Oct  8 16:12:20 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 16:12:20 GMT
Subject: RFR: 8048180: Eager reclaim of humongous objects with references
 [v3]
In-Reply-To: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
Message-ID: <24xyP8ZcsKjFctIa01NYTAOnc1HnQHLh-HxcfOsf6ns=.f034e1b3-1a7b-47a7-81c6-0213abb647b3@github.com>

> Hi all,
> 
>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
> 
> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
> 
> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
> 
> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
> 
> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>  
> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
> 
> Testing: new test cases, gha, tier1-5
> 
> Thanks,
>   Thomas

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

  * more documentation work

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27525/files
  - new: https://git.openjdk.org/jdk/pull/27525/files/44c62fcb..7bf219a8

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

  Stats: 57 lines in 1 file changed: 24 ins; 20 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/27525.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27525/head:pull/27525

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

From tschatzl at openjdk.org  Wed Oct  8 16:16:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 8 Oct 2025 16:16:45 GMT
Subject: RFR: 8369433: G1: Replace G1MarkScope with NMethodMarkingScope
In-Reply-To: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>
References: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>
Message-ID: <vcFL0P3WA5hkA6SKA_G0ZLdoYWYLaygzWehvTEHyvOQ=.f71adc63-3dc8-43d1-a85c-88e4c6007481@github.com>

On Wed, 8 Oct 2025 15:39:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replacing `G1MarkScope` with `NMethodMarkingScope`, since they have equivalent implementations.
> 
> Passes tier1 and tier2 (fastdebug).

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27697#pullrequestreview-3315597129

From xpeng at openjdk.org  Wed Oct  8 16:16:50 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 8 Oct 2025 16:16:50 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v4]
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <jxV08hUQML8wiz8ewhmZ6orPLImarkygpEYaThVnR6Y=.45609afb-7c04-43aa-a0b3-672e6049fc2e@github.com>

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works:
> * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array).
> * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive  directly allocatable regions in the array storing directly allocatable region.
> * If mutator thread fails after trying 3 directly allocatable regions, it will:
>    * Take heap lock
>    * Try to retire the directly allocatable regions which are ready to retire.
>    *  Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired.
>    *  Satisfy mutator allocation request if possible.
> 
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores:
> Openjdk TIP:
> 
> [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====...

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

 - Merge branch 'openjdk:master' into cas-alloc-1
 - format
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'master' into cas-alloc-1
 - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Fix errors caused by renaming ofAtomic to AtomicAccess
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Remove unused flag
 - ... and 124 more: https://git.openjdk.org/jdk/compare/79bcc7b8...14943e56

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

Changes: https://git.openjdk.org/jdk/pull/26171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=03
  Stats: 735 lines in 16 files changed: 674 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

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

From kdnilsen at openjdk.org  Wed Oct  8 16:57:13 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 8 Oct 2025 16:57:13 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v21]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <R6HFAtTuWFS9PuYtuaGwRN8rV-_skb2jhkC4Q6iLgZw=.5eadeb4a-0e3e-4982-9b94-406a1f25f134@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:

  fix test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/4db0cbe4..6c48bf10

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

  Stats: 1 line in 1 file changed: 0 ins; 0 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  Wed Oct  8 16:57:17 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 8 Oct 2025 16:57:17 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v14]
In-Reply-To: <j80QwLMBFP9sHusg37FaUpTaR-rBKPL8yAeDpzJbVD4=.b4eb3185-eeb2-4a5b-921a-d8a03fdf507b@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <ow6Nd42Z36Qmu32f4wV67tJWjEHAT296eTExYs83VMw=.5066c6b9-882d-4ec4-a2ac-b1c661965ebd@github.com>
 <j80QwLMBFP9sHusg37FaUpTaR-rBKPL8yAeDpzJbVD4=.b4eb3185-eeb2-4a5b-921a-d8a03fdf507b@github.com>
Message-ID: <Ix9dDAgmRp6I-_6lXgZ77C_brNTXxD9xk_m9ufh3-U8=.5ae61490-5de1-4187-9fb4-2249a1f298fb@github.com>

On Fri, 3 Oct 2025 21:49:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

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

Done.

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

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

From wkemper at openjdk.org  Wed Oct  8 17:43:04 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Oct 2025 17:43:04 GMT
Subject: RFR: 8264851: Shenandoah: Rework control loop mechanics to use
 timed waits [v2]
In-Reply-To: <ROt--V437nRJ09DJ3R4V1WSk02YAzeaf4LZZUTTR1V4=.65a89969-77d8-44f8-98d5-15ed704d3095@github.com>
References: <ROt--V437nRJ09DJ3R4V1WSk02YAzeaf4LZZUTTR1V4=.65a89969-77d8-44f8-98d5-15ed704d3095@github.com>
Message-ID: <JQwOS0r3cNxdwtSoWf2mKKegB6hqkroDNK6fvFiU1bY=.60a7d222-1f8e-4a7e-ad19-9d4420d88c84@github.com>

> We use a similar mechanism in `shGenerationalControlThread` already. Using a timed wait allows the control thread to be woken up before the wait expires.

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

 - Merge remote-tracking branch 'jdk/master' into use-timed-wait-for-control-thread
 - Add documentation and make new method private
 - Use timed wait/notify for more timely control thread reactions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27502/files
  - new: https://git.openjdk.org/jdk/pull/27502/files/73c1849a..fd47d57f

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

  Stats: 22555 lines in 759 files changed: 13114 ins; 5271 del; 4170 mod
  Patch: https://git.openjdk.org/jdk/pull/27502.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27502/head:pull/27502

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

From wkemper at openjdk.org  Wed Oct  8 17:51:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Oct 2025 17:51:36 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v21]
In-Reply-To: <R6HFAtTuWFS9PuYtuaGwRN8rV-_skb2jhkC4Q6iLgZw=.5eadeb4a-0e3e-4982-9b94-406a1f25f134@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <R6HFAtTuWFS9PuYtuaGwRN8rV-_skb2jhkC4Q6iLgZw=.5eadeb4a-0e3e-4982-9b94-406a1f25f134@github.com>
Message-ID: <ZCXneTXnM6-1jzGSCXe2NqV45YepGzFSccIB-Ja4xJc=.7757d485-6b82-480d-ac7d-f4396ae1115a@github.com>

On Wed, 8 Oct 2025 16:57:13 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:
> 
>   fix test

This is a tremendous simplification.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26867#pullrequestreview-3315903968

From kdnilsen at openjdk.org  Wed Oct  8 18:04:35 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 8 Oct 2025 18:04:35 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v22]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <VxvFM87KeGvJOnOY36qj7gVjXuviBvtvoBB20ScOjz0=.aa34b900-ee86-437d-b2d6-5605a056a9c7@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:

  fix override declaration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/6c48bf10..6ec50218

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

  Stats: 1 line in 1 file changed: 0 ins; 0 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  Wed Oct  8 18:04:38 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 8 Oct 2025 18:04:38 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v14]
In-Reply-To: <Ix9dDAgmRp6I-_6lXgZ77C_brNTXxD9xk_m9ufh3-U8=.5ae61490-5de1-4187-9fb4-2249a1f298fb@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <ow6Nd42Z36Qmu32f4wV67tJWjEHAT296eTExYs83VMw=.5066c6b9-882d-4ec4-a2ac-b1c661965ebd@github.com>
 <j80QwLMBFP9sHusg37FaUpTaR-rBKPL8yAeDpzJbVD4=.b4eb3185-eeb2-4a5b-921a-d8a03fdf507b@github.com>
 <Ix9dDAgmRp6I-_6lXgZ77C_brNTXxD9xk_m9ufh3-U8=.5ae61490-5de1-4187-9fb4-2249a1f298fb@github.com>
Message-ID: <YghWcBnqU9Q0ZnDve3ecGT7AxM5s6sVa24yqF8CHvUs=.2b8edee3-d799-46d8-89c9-021c4b0ff8c2@github.com>

On Wed, 8 Oct 2025 16:50:52 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

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

removed.

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

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

From wkemper at openjdk.org  Wed Oct  8 18:05:08 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Oct 2025 18:05:08 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v3]
In-Reply-To: <mBD0mE_1BcCRgJR137CEPOZPSRby8JNsFJJK3F_35Co=.5026848f-dc37-4897-b5c4-66d75309e4f6@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>
 <Z5RQ4VmAs4E3MnqKk5waMvvXN022mE2cmvp8-g0Khps=.08ad3d03-08f8-4479-ae3f-91c7cecd68e0@github.com>
 <mBD0mE_1BcCRgJR137CEPOZPSRby8JNsFJJK3F_35Co=.5026848f-dc37-4897-b5c4-66d75309e4f6@github.com>
Message-ID: <II_OA6j-VMjwnk1XB5688OK5seMomdZGD7B7WT8uXeY=.744caa48-cc03-4e39-b22a-1711f16d9720@github.com>

On Tue, 7 Oct 2025 23:46:15 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> I called the complementary method `get_live_bytes_in_tenurable_regions`. How about `get_live_bytes_in_untenurable_regions`?
>
> I'm still maybe a bit confused.  Is it get_untenurable_live_bytes_in_young_regions()?  Are we distinguishing?
> 
> So we have a total of N live bytes within young regions that have been placed into the collection set.  We expect that P bytes (P < N) will be promoted, and the remaining S bytes (S + P == N) will be evacuated to "survivor space" within young.
> 
> Does get_live_bytes_in_untenurable_regions() equal P + S?

The _tenure_ here refers to the regions the objects reside in, not the objects themselves. `get_live_bytes_in_tenurable_regions` is the sum of live bytes in all regions with an age above the tenuring threshold (we expect to promote _all_ of these, though some promotions may fail). It's complement `get_live_bytes_in_untenurable_regions` is the sum of live bytes in all regions with an age less than the tenuring threshold (we expect to promote _some_ of these, but we don't really know how many). This was part of the reason I wanted to rename these methods. They  represent the provenance of the objects in the collection set, not necessarily the regions they will be evacuated to.

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

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

From wkemper at openjdk.org  Wed Oct  8 18:16:28 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Oct 2025 18:16:28 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v4]
In-Reply-To: <7xGe1GZZMDQlU380bkZlAGkgMsI-Q_jRD6qSVJrM664=.640873a9-2c9d-4297-b64b-ec74c7819442@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>
 <c0deYfp9H2MYnX0BdsFulINUNVf5gknuI1YWDjtYZ5M=.fc3d8376-d381-43fd-896d-c0fefa5ab607@github.com>
 <7xGe1GZZMDQlU380bkZlAGkgMsI-Q_jRD6qSVJrM664=.640873a9-2c9d-4297-b64b-ec74c7819442@github.com>
Message-ID: <nEc_iM749PTRefylVx2mqZDq1tPPRkk2wEh932BKT6k=.d5dbbd87-6c65-4a38-a769-e83ba5501829@github.com>

On Tue, 7 Oct 2025 23:41:53 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> In `compute_evacuation_reserves` we are setting the promotion reserve to the maximum possible to handle everything tenurable this cycle (this is still capped by the maximum evacuation reserve for old). I was reluctant to scale the promotion reserve by `ShenandoahPromoEvacWaste`  for fear it would over commit the collector's reserves and lead to OOM errors during evacuation.
>
> So in the new design, we have full awareness of all promotable objects, and we've already done our best to budget for those.  So there's no such thing as "unanticipated promotions".
> 
> Separate question is whether we scale promotion reserve by ShenandoahPromoEvacWaste.  So if old is larger than necessary to handle the anticipated mixed evacuations and promotions, the new code is essentially saying "use this extra space for mixed evacuations rather than for promotions".   Since we're not expanding the promoted_reserve, promotions will not be allowed to touch it.
> 
> Am I understanding the intent correctly?

In `compute_evacuation_budgets`, if there are mixed collection candidates we set the initial promotion reserve to zero and the old evacuation reserve to the maximum. However, we then restrict old evacuation reserve to only empty regions. The difference between `old available` and `old unaffiliated` is given to the promotion reserve. Here again, I didn't want to scale the promotion reserve because it's basically the scraps of the old generation and I worry about over committing the old reserve. When there are no mixed collections, we use the entirety of old for promotions. Any old regions not needed for old evacuations or promotions are transferred to the young generation as they were before this change.

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

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

From wkemper at openjdk.org  Wed Oct  8 18:17:32 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Oct 2025 18:17:32 GMT
Subject: Integrated: 8264851: Shenandoah: Rework control loop mechanics to use
 timed waits
In-Reply-To: <ROt--V437nRJ09DJ3R4V1WSk02YAzeaf4LZZUTTR1V4=.65a89969-77d8-44f8-98d5-15ed704d3095@github.com>
References: <ROt--V437nRJ09DJ3R4V1WSk02YAzeaf4LZZUTTR1V4=.65a89969-77d8-44f8-98d5-15ed704d3095@github.com>
Message-ID: <2UuiyrNOm1teK24_RgKvp0t4811KGAkJ4k5e3g_P0yE=.1b04d645-5f2d-43e3-b6a3-a91fd12ab714@github.com>

On Thu, 25 Sep 2025 20:35:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We use a similar mechanism in `shGenerationalControlThread` already. Using a timed wait allows the control thread to be woken up before the wait expires.

This pull request has now been integrated.

Changeset: 92f2ab2e
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92f2ab2e1b5a7c02ea6d3a3a07c7fbbfc725cdea
Stats:     28 lines in 2 files changed: 18 ins; 6 del; 4 mod

8264851: Shenandoah: Rework control loop mechanics to use timed waits

Reviewed-by: kdnilsen, shade

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

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

From kdnilsen at openjdk.org  Wed Oct  8 18:33:15 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 8 Oct 2025 18:33:15 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v23]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <nxtPk0TfmeCOkgaZfHU8aRtpsuyD9Fed2hAJv_xMBPU=.d2cdfdff-d755-45f2-b7dc-4ef2921e3b89@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:

  fix anothr override declaration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/6ec50218..4c3c38bc

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

  Stats: 1 line in 1 file changed: 0 ins; 0 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 wkemper at openjdk.org  Wed Oct  8 18:53:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Oct 2025 18:53:22 GMT
Subject: RFR: 8369447: GenShen: Regulator thread may observe inconsistent
 states
Message-ID: <5Qa66lljxDIXH8mOo9oyCZTDjZ2OyhgHsurqkfKKhGY=.a784a918-bb7b-4a86-bad6-195ee1800650@github.com>

Shenandoah's generational mode runs a separate thread to monitor the heap during old collections. This thread is responsible for deciding to start collections. When the thread which actually runs collections (the control thread) changes the state of various gc components _on a safepoint_, it has the expectation that these changes will become visible to mutator threads atomically, and consistently. However, the regulator thread does not participate in safepoints and may observe gc components in inconsistent states and so make incorrect choices about trying to start GC cycles.

For example:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp:625), pid=3796044, tid=3796163
# assert(_old_generation->state() == ShenandoahOldGeneration::MARKING) failed: Unexpected old gen state: Waiting for Bootstrap
#

The solution here is to make the regulator thread participate in safepoints. There is no need for it to run during a safepoint.

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

Commit messages:
 - Merge remote-tracking branch 'jdk/master' into suspend-regulator-thread
 - Suspend regulator thread during safepoints

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

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

From wkemper at openjdk.org  Wed Oct  8 19:33:10 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 8 Oct 2025 19:33:10 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled assertion
 failure
Message-ID: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>

There are certain code paths in Shenandoah's generational mode that need to _know_ which generation is being collected, but it is not possible to pass this information on the stack (barriers, for example). To address this, we introduced an `_active_generation` member in `ShenandoahHeap`. Over time, the usage of this field grew beyond its intended purpose and we began to have issues where not all threads would see a consistent value for this field. To address _this_ issue, we added another field `_gc_generation` which was only meant to be used by GC threads. At this point, we have three different ways to determine which generation is being collected: the _active_ generation, the _gc_ generation, and the usual function parameters and member fields of the gc components. This PR removes `_gc_generation` and reduces the use of `_active_generation` to only those places where it is not possible to get this information from other means (barriers, mostly). All GC components that can have this
  information passed through function calls, now do so.

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

Commit messages:
 - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
 - Remove _gc_generation from ShenandoahHeap
 - Little cleanup, remove one active generation usage
 - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
 - Finish removing usages of gc_generation, start on reducing usages of active_generation
 - Fix build
 - Use existing _generation field instead of Heap::_gc_generation where possible
 - Only shenandoah vm operations participate in active/gc generation scheme

Changes: https://git.openjdk.org/jdk/pull/27703/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27703&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369068
  Stats: 495 lines in 32 files changed: 119 ins; 149 del; 227 mod
  Patch: https://git.openjdk.org/jdk/pull/27703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27703/head:pull/27703

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

From dholmes at openjdk.org  Thu Oct  9 02:03:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:03:16 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: <o7O0MNu6ATtffPBmT7ITE4GhNCvmu0YCxl-exqxBj1I=.8aebc999-430f-468a-a9e4-93e20caca650@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

Sorry @afshin-zafari but this PR has me quite confused. The code changes do not reflect the PR description. The PR description does not obviously connect to the JBS problem statement. And the code changes in the PR seem unrelated to the value of aligned_heap_base_min_address as referenced in JBS.

And the cast changes in memoryReserver.cpp seem completely unrelated.

That said, I do not know how all of these heap variables interact and relate, so you really need the GC folk to understand and approve this.

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

> 286:   // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value.
> 287:   // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx.
> 288:   if (value + MaxHeapSize < MaxHeapSize) { // overflow

Sorry I am struggling to see how this check differs in practice to the existing check:

(value > (max_uintx - MaxHeapSize))

Further, the comment before the new check seems to relate to the existing check.

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

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

From ysr at openjdk.org  Thu Oct  9 02:13:09 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 9 Oct 2025 02:13:09 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: <b8tVsZGnEjAcDe9Gv_FxrFUKRIjjxKVUqWMmpdsRsuk=.4ad87533-66ee-4a9f-bc9e-3ef4f8d2f58d@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.

Left some comments that may simplify `clear_cancelled_gc()` slightly (improving comprehension complexity a bit).

I see that there is a longish comment about the evac oom handler. It might be worthwhile where the counters are cleared to explain when we are safe to clear the counnters. (May be it's explained somewhere in the block comment in `shenandoahEvacOOMHandler.hpp` class definition but it wasn't obvious when the clearing is safe.)

src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 116:

> 114:     if (request.cause == GCCause::_shenandoah_concurrent_gc) {
> 115:       request.generation = _heap->young_generation();
> 116:       _heap->clear_cancelled_gc(false);

It appears as if this was the _only_ case where `clear_cancelled_gc()` was called while not clearing the oom_handler.

Should `clear_cancelled_gc()` be modified by removing the option/argument for clearing or not the oom_handler?

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

> 457:   inline GCCause::Cause cancelled_cause() const;
> 458: 
> 459:   // Clears the cancellation cause and optionally resets the oom handler (cancelling an

See comment above re "optional reset of oom handler" etc. related simplication.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27662#pullrequestreview-3316976435
PR Review Comment: https://git.openjdk.org/jdk/pull/27662#discussion_r2415375564
PR Review Comment: https://git.openjdk.org/jdk/pull/27662#discussion_r2415376309

From ysr at openjdk.org  Thu Oct  9 02:25:00 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 9 Oct 2025 02:25:00 GMT
Subject: RFR: 8368501: Shenandoah: GC progress evaluation does not use
 generation
In-Reply-To: <Qn6FDlj32BhpX--A-sebLeUUJpc0zk_jlA39Tm9hbSA=.43c28844-62cf-44a2-a3cc-6b2b85744592@github.com>
References: <Qn6FDlj32BhpX--A-sebLeUUJpc0zk_jlA39Tm9hbSA=.43c28844-62cf-44a2-a3cc-6b2b85744592@github.com>
Message-ID: <XoWjnHny2TXIdOPXKY3zT_DKkaWUKtvWvtjIChwUF6w=.9a40810a-8848-4277-87a8-73067ba615f8@github.com>

On Mon, 29 Sep 2025 21:24:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove unused `generation` parameter from stop-the-world GC progress evaluation. Also, have `shMetrics` use the freeset for `usage`  details. This is a follow up to a comment from an unrelated PR: https://github.com/openjdk/jdk/pull/27456#issuecomment-3325724362.

Nice cleanup, thanks!

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27561#pullrequestreview-3317009418

From ysr at openjdk.org  Thu Oct  9 02:31:12 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 9 Oct 2025 02:31:12 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v23]
In-Reply-To: <nxtPk0TfmeCOkgaZfHU8aRtpsuyD9Fed2hAJv_xMBPU=.d2cdfdff-d755-45f2-b7dc-4ef2921e3b89@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <nxtPk0TfmeCOkgaZfHU8aRtpsuyD9Fed2hAJv_xMBPU=.d2cdfdff-d755-45f2-b7dc-4ef2921e3b89@github.com>
Message-ID: <Iykb6BzmAAQOCFr-5k4KvkHpNopibLvGxEansC6sGXI=.2cdbbe4e-9ce5-4a3e-b22e-67f57e47fe90@github.com>

On Wed, 8 Oct 2025 18:33:15 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:
> 
>   fix anothr override declaration

Will pick this up in a bit but thought I should flush the comments (which I already made in verbal form earlier today at one of our meetings).

Sorry for the delay on this, but on it now and will get it done later tonight.

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

PR Review: https://git.openjdk.org/jdk/pull/26867#pullrequestreview-3316341505

From ysr at openjdk.org  Thu Oct  9 02:31:15 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 9 Oct 2025 02:31:15 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v23]
In-Reply-To: <5UAnGN3TiTYZSVcLUKLq-WIrpi3_h6rBAMhdcer6lxQ=.6b299e43-1166-4dc6-b258-3c3b30b5d292@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>
 <5UAnGN3TiTYZSVcLUKLq-WIrpi3_h6rBAMhdcer6lxQ=.6b299e43-1166-4dc6-b258-3c3b30b5d292@github.com>
Message-ID: <56BKWUn6QrR08Yus8f-M-SF3fUT-gjzNDEfUkmOAsok=.b0345ab1-cb3f-4b9a-b741-0bf437f9885d@github.com>

On Tue, 7 Oct 2025 21:58:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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?
>
> ShenandoahHeap::initialize() makes use of SoftMaxHeapSize.  If the SoftMaxHeapSizeConstraintFunc is handled "after memory init", the value of SoftMaxHeapSize is not yet available when we try to use it.
> 
> I welcome an alternative approach if you have any ideas.

Did all tests pass, in particular `TestSoftMaxHeapSize`? The test now happens earlier. I am not sure why the value itself isn't available before, like you say. I am guessing you want to check the value after whatever adjustments have been made in `initialize()`? The value of the flag should be available already, irrespective of when the constraints check is done.


enum class JVMFlagConstraintPhase : char {
  // Will be validated during argument processing (Arguments::parse_argument).
  AtParse         = 0,
  // Will be validated inside Threads::create_vm(), right after Arguments::apply_ergo().
  AfterErgo       = 1,
  // Will be validated inside universe_init(), right after Metaspace::global_initialize().
  AfterMemoryInit = 2
};

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

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

From ysr at openjdk.org  Thu Oct  9 02:31:16 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 9 Oct 2025 02:31:16 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v23]
In-Reply-To: <56BKWUn6QrR08Yus8f-M-SF3fUT-gjzNDEfUkmOAsok=.b0345ab1-cb3f-4b9a-b741-0bf437f9885d@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>
 <5UAnGN3TiTYZSVcLUKLq-WIrpi3_h6rBAMhdcer6lxQ=.6b299e43-1166-4dc6-b258-3c3b30b5d292@github.com>
 <56BKWUn6QrR08Yus8f-M-SF3fUT-gjzNDEfUkmOAsok=.b0345ab1-cb3f-4b9a-b741-0bf437f9885d@github.com>
Message-ID: <bGZCxSzE6wIgvSupETgizEd-G0px4JGkxvFveADJUJk=.1b69646f-64d6-496d-b183-2f3028f7fc5a@github.com>

On Wed, 8 Oct 2025 20:08:25 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> ShenandoahHeap::initialize() makes use of SoftMaxHeapSize.  If the SoftMaxHeapSizeConstraintFunc is handled "after memory init", the value of SoftMaxHeapSize is not yet available when we try to use it.
>> 
>> I welcome an alternative approach if you have any ideas.
>
> Did all tests pass, in particular `TestSoftMaxHeapSize`? The test now happens earlier. I am not sure why the value itself isn't available before, like you say. I am guessing you want to check the value after whatever adjustments have been made in `initialize()`? The value of the flag should be available already, irrespective of when the constraints check is done.
> 
> 
> enum class JVMFlagConstraintPhase : char {
>   // Will be validated during argument processing (Arguments::parse_argument).
>   AtParse         = 0,
>   // Will be validated inside Threads::create_vm(), right after Arguments::apply_ergo().
>   AfterErgo       = 1,
>   // Will be validated inside universe_init(), right after Metaspace::global_initialize().
>   AfterMemoryInit = 2
> };

In particular, in its current form, the test asks for the value to be <= MaxHeapSize, and ergo merely arranges to set it to MaxHeapSize, rendering any subsequent adjustments in `initialize()` to be not tested. (That in itself is perhaps OK, but we should probably check that other GCs are ok with moving the constraints check earlier. In particular, zGC adjusts the value in its initialize() and might _want_ the check later after its adjustments are done.)


GCArguments::initialize_heap_flags_and_sizes():
...
  if (FLAG_IS_DEFAULT(SoftMaxHeapSize)) {
    FLAG_SET_ERGO(SoftMaxHeapSize, MaxHeapSize);
  }
...



ZArguments::initialize_heap_flags_and_sizes():
...
  if (!FLAG_IS_CMDLINE(MaxHeapSize) &&
      !FLAG_IS_CMDLINE(MaxRAMPercentage) &&
      !FLAG_IS_CMDLINE(SoftMaxHeapSize)) {
    // We are really just guessing how much memory the program needs.
    // When that is the case, we don't want the soft and hard limits to be the same
    // as it can cause flakiness in the number of GC threads used, in order to keep
    // to a random number we just pulled out of thin air.
    FLAG_SET_ERGO(SoftMaxHeapSize, MaxHeapSize * 90 / 100);
  }
...


I'm not convinced the change above to move the constraints check sooner is needed in order to _use_ the value of SoftMaxHeapSize in `ShenandoahHeap::initialize()`.

What's the error you see without this change?

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

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

From kdnilsen at openjdk.org  Thu Oct  9 02:41:48 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 9 Oct 2025 02:41:48 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v24]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <sFPN5XGWAMeWVVojbKfaKebb7wMQp9jGHhbzIHAu7Cg=.f0e4c8ce-97b1-4a48-b84d-0ee7fbed497c@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 change to SoftMaxHeapSizeConstraintFunc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/4c3c38bc..9c2dc8bd

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

  Stats: 1 line in 1 file changed: 0 ins; 0 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 dholmes at openjdk.org  Thu Oct  9 02:56:12 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Oct 2025 02:56:12 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: <Bc-AJ9ooqAz_9t6yBmHCwBLVbBuHyB3ttwZQAvx7IIE=.f4aef02c-27ef-4a81-89fd-263640cea3d7@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

Also I think this might need to account for the changes to `Arguments::set_heap_size` being done in https://github.com/openjdk/jdk/pull/27224

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

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3383863313

From jsikstro at openjdk.org  Thu Oct  9 08:21:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 9 Oct 2025 08:21:03 GMT
Subject: Integrated: 8367413: Fix potential truncation error in
 Arguments::set_heap_size()
In-Reply-To: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
Message-ID: <WxRAtaIFey0xGsVPIK_6KApML94nDIK293-n7LAGdeI=.1c7b512a-949b-47a7-8a7e-9c243a0c5748@github.com>

On Thu, 11 Sep 2025 12:39:18 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

This pull request has now been integrated.

Changeset: af2fbd5a
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af2fbd5a7182cabdd88764b5653d2ce666f05d70
Stats:     73 lines in 1 file changed: 18 ins; 6 del; 49 mod

8367413: Fix potential truncation error in Arguments::set_heap_size()

Reviewed-by: ayang, lkorinth

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

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

From jsikstro at openjdk.org  Thu Oct  9 08:21:01 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 9 Oct 2025 08:21:01 GMT
Subject: RFR: 8367413: Fix potential truncation error in
 Arguments::set_heap_size() [v8]
In-Reply-To: <Yx___8q4UiUlOeOP2oxSnqUkibpnxy4mLCJEF69Wsd8=.48969f18-0ff0-4120-a358-ceb30ac0049c@github.com>
References: <DXuXOuRev9OXdfEOsaiFmHtz9mxKDQzGoHi_hcBlzDU=.47307354-b9df-4b3f-9dd1-6fa6071aa8a8@github.com>
 <bJ2sBQT8DZU81Z3gpe57qYSoSB8IUAse81ETMve2odA=.56418a5f-d45b-42be-af2d-45f3254ea040@github.com>
 <Yx___8q4UiUlOeOP2oxSnqUkibpnxy4mLCJEF69Wsd8=.48969f18-0ff0-4120-a358-ceb30ac0049c@github.com>
Message-ID: <PzNRah3SAKayRFZjLY7SHIiUf6gpbZ2vCnjr5aQ-qBs=.1dfd6464-cfca-403d-abff-886f9d900962@github.com>

On Wed, 8 Oct 2025 13:11:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge branch 'master' into JDK-8367413_arguments_sizet_julong
>>  - Rename limit_by_size_t_max to clamp_by_size_t_max
>>  - Make limit_by_size_t_max to a static function in arguments.cpp
>>  - Rename ram_limit_set to has_ram_limit
>>  - Revert MaxRAM default removals, defer to future enhancement
>>  - 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.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/23fcbb0b...f5649cb7
>
> Marked as reviewed by ayang (Reviewer).

For sanity I reran tier1-4, which looks good. Thank you for the reviews @albertnetymk and @lkorinth.

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

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

From ayang at openjdk.org  Thu Oct  9 09:27:21 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 9 Oct 2025 09:27:21 GMT
Subject: RFR: 8369433: G1: Replace G1MarkScope with NMethodMarkingScope
In-Reply-To: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>
References: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>
Message-ID: <-HiuHUwPdPdF1vDXET6t1EeK9siLl-tlb6Ask6FopgE=.98593136-3382-4580-942b-f86bc709d805@github.com>

On Wed, 8 Oct 2025 15:39:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replacing `G1MarkScope` with `NMethodMarkingScope`, since they have equivalent implementations.
> 
> Passes tier1 and tier2 (fastdebug).

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27697#pullrequestreview-3318008040

From iwalulya at openjdk.org  Thu Oct  9 11:52:04 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 9 Oct 2025 11:52:04 GMT
Subject: RFR: 8048180: Eager reclaim of humongous objects with references
 [v3]
In-Reply-To: <24xyP8ZcsKjFctIa01NYTAOnc1HnQHLh-HxcfOsf6ns=.f034e1b3-1a7b-47a7-81c6-0213abb647b3@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
 <24xyP8ZcsKjFctIa01NYTAOnc1HnQHLh-HxcfOsf6ns=.f034e1b3-1a7b-47a7-81c6-0213abb647b3@github.com>
Message-ID: <z77VZNbWjMdwLDgYU-5q-VSArLxpNbSeeoarv5Z6_AA=.d962549c-72c5-4e88-af07-2ace2088ff1d@github.com>

On Wed, 8 Oct 2025 16:12:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
>> 
>> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
>> 
>> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
>> 
>> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
>> 
>> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>>  
>> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
>> 
>> Testing: new test cases, gha, tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * more documentation work

LGTM!

Nit:

src/hotspot/share/gc/g1/g1_globals.hpp line 299:

> 297:           "for eager reclaim. Will be selected ergonomically by default.")  \
> 298:                                                                             \
> 299:   product(bool, G1EagerReclaimWithRefs, true, DIAGNOSTIC,                   \

Is there any compelling use case where turning this off would be a good option? Otherwise, I suggest we don't add it.

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27525#pullrequestreview-3318583105
PR Review Comment: https://git.openjdk.org/jdk/pull/27525#discussion_r2416522712

From tschatzl at openjdk.org  Thu Oct  9 12:33:12 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 9 Oct 2025 12:33:12 GMT
Subject: RFR: 8048180: Eager reclaim of humongous objects with references
 [v3]
In-Reply-To: <z77VZNbWjMdwLDgYU-5q-VSArLxpNbSeeoarv5Z6_AA=.d962549c-72c5-4e88-af07-2ace2088ff1d@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
 <24xyP8ZcsKjFctIa01NYTAOnc1HnQHLh-HxcfOsf6ns=.f034e1b3-1a7b-47a7-81c6-0213abb647b3@github.com>
 <z77VZNbWjMdwLDgYU-5q-VSArLxpNbSeeoarv5Z6_AA=.d962549c-72c5-4e88-af07-2ace2088ff1d@github.com>
Message-ID: <UjUiOQoCF23v0TbaeCKer2r-gi9tE7_GWHSqjwFALW4=.4ebdecc2-ca75-44aa-b9a8-f96746f84d05@github.com>

On Thu, 9 Oct 2025 11:49:03 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * more documentation work
>
> src/hotspot/share/gc/g1/g1_globals.hpp line 299:
> 
>> 297:           "for eager reclaim. Will be selected ergonomically by default.")  \
>> 298:                                                                             \
>> 299:   product(bool, G1EagerReclaimWithRefs, true, DIAGNOSTIC,                   \
> 
> Is there any compelling use case where turning this off would be a good option? Otherwise, I suggest we don't add it.

No, just being able to turn it off in case there are problems.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27525#discussion_r2416633031

From ayang at openjdk.org  Thu Oct  9 12:35:25 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 9 Oct 2025 12:35:25 GMT
Subject: RFR: 8369501: Parallel: Add UseAdaptiveSizePolicy requirement to
 TestDynShrinkHeap.java
Message-ID: <U3EAg0A6zpG7EMRoe50l079OtyhIWgegrRHzFiXEnNA=.98cf4423-6279-4daf-b994-6d53f3ef568a@github.com>

Add a `@requires` to this test so that it will be skipped if `UseAdaptiveSizePolicy` is off.

Test: tier1-3

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

Commit messages:
 - jtreg-flag

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

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

From fandreuzzi at openjdk.org  Thu Oct  9 12:38:14 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 9 Oct 2025 12:38:14 GMT
Subject: RFR: 8369433: G1: Replace G1MarkScope with NMethodMarkingScope
In-Reply-To: <vcFL0P3WA5hkA6SKA_G0ZLdoYWYLaygzWehvTEHyvOQ=.f71adc63-3dc8-43d1-a85c-88e4c6007481@github.com>
References: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>
 <vcFL0P3WA5hkA6SKA_G0ZLdoYWYLaygzWehvTEHyvOQ=.f71adc63-3dc8-43d1-a85c-88e4c6007481@github.com>
Message-ID: <UPVrsNe-mA-viRoLvYnD59vTRU8XDt7NrZllU8gzOYc=.b444ef7c-08ab-46c8-a313-7cf8769a3199@github.com>

On Wed, 8 Oct 2025 16:14:20 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Replacing `G1MarkScope` with `NMethodMarkingScope`, since they have equivalent implementations.
>> 
>> Passes tier1 and tier2 (fastdebug).
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks for the review @tschatzl and @albertnetymk.

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

PR Comment: https://git.openjdk.org/jdk/pull/27697#issuecomment-3385665190

From duke at openjdk.org  Thu Oct  9 12:38:15 2025
From: duke at openjdk.org (duke)
Date: Thu, 9 Oct 2025 12:38:15 GMT
Subject: RFR: 8369433: G1: Replace G1MarkScope with NMethodMarkingScope
In-Reply-To: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>
References: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>
Message-ID: <xsQP-0YCEXDLztQ1CMll2rB-oBfl-zaMQ0BvSXFySeI=.950e936b-f888-4290-b5fa-cad133ca2932@github.com>

On Wed, 8 Oct 2025 15:39:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replacing `G1MarkScope` with `NMethodMarkingScope`, since they have equivalent implementations.
> 
> Passes tier1 and tier2 (fastdebug).

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27697#issuecomment-3385667344

From tschatzl at openjdk.org  Thu Oct  9 12:39:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 9 Oct 2025 12:39:53 GMT
Subject: RFR: 8048180: Eager reclaim of humongous objects with references
 [v4]
In-Reply-To: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
Message-ID: <SP5v_AspB4EdQb3gzzIZYwLgNoy1WaBVXx559DRMKQg=.c32fafdd-b9e8-47b3-804f-aab8578334ec@github.com>

> Hi all,
> 
>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
> 
> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
> 
> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
> 
> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
> 
> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>  
> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
> 
> Testing: new test cases, gha, tier1-5
> 
> Thanks,
>   Thomas

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

 - Merge branch 'master' into 8048180-investigate-eager-reclaim-of-reference-arrays
 - * more documentation work
 - * walulyai review, improved comments, example
 - * also check for actual region reclamation
   
   * enable reference array reclaim anywhere during non-marking, enable during rebuild
   
   * additional test for all situation
   
   * fix guarantee for humongous regular objects
   
   * need to clear card table of eagerly reclaimed regions
   
   * do not redirty recently freed humongous regions to avoid stray card marks
   
   * card table of humongous-continues regions has not been cleared
   
   * some cleanup
   
   * include non-typeArrays allocated after mark start in candidates
   * and allow non-typeArray candidates right after marking completed
   
   * update test case to also check allocations after marking
   * additional documentation
   
   * rename test case
   
   * more explanations
   
   * move back free humongous regions to post evacuate 2. There does not seem to be a reason to put it there, and it clashes with RecalculateUsedTask.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27525/files
  - new: https://git.openjdk.org/jdk/pull/27525/files/7bf219a8..afcac13a

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

  Stats: 33737 lines in 1034 files changed: 19851 ins; 7931 del; 5955 mod
  Patch: https://git.openjdk.org/jdk/pull/27525.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27525/head:pull/27525

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

From fandreuzzi at openjdk.org  Thu Oct  9 12:45:13 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 9 Oct 2025 12:45:13 GMT
Subject: Integrated: 8369433: G1: Replace G1MarkScope with NMethodMarkingScope
In-Reply-To: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>
References: <jYk2PC7X-aXYKkPVG7aoVwIzDiz1XVOOLR3lELPyr4I=.0eb840ea-b767-4590-9cb1-772131f5d49c@github.com>
Message-ID: <G5pHXkIPmRU6O24OAknq5FFNbPGHHN8lmDGFf_npyG0=.075ed24f-db79-49bc-a71b-3446cee8536c@github.com>

On Wed, 8 Oct 2025 15:39:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> Replacing `G1MarkScope` with `NMethodMarkingScope`, since they have equivalent implementations.
> 
> Passes tier1 and tier2 (fastdebug).

This pull request has now been integrated.

Changeset: 9def7bfe
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9def7bfea263f6f77f0bd9d4c16f00b7a0834243
Stats:     6 lines in 1 file changed: 1 ins; 4 del; 1 mod

8369433: G1: Replace G1MarkScope with NMethodMarkingScope

Reviewed-by: tschatzl, ayang

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

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

From ayang at openjdk.org  Thu Oct  9 12:52:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 9 Oct 2025 12:52:19 GMT
Subject: RFR: 8048180: Eager reclaim of humongous objects with references
 [v4]
In-Reply-To: <SP5v_AspB4EdQb3gzzIZYwLgNoy1WaBVXx559DRMKQg=.c32fafdd-b9e8-47b3-804f-aab8578334ec@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
 <SP5v_AspB4EdQb3gzzIZYwLgNoy1WaBVXx559DRMKQg=.c32fafdd-b9e8-47b3-804f-aab8578334ec@github.com>
Message-ID: <3fZ_ZIbAH5ZPoVJBSZaOyINSeZMJi1sQqnaUvxHrWdA=.e88b2d01-0e0b-4b5f-a0c0-3f5950452eba@github.com>

On Thu, 9 Oct 2025 12:39:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
>> 
>> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
>> 
>> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
>> 
>> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
>> 
>> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>>  
>> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
>> 
>> Testing: new test cases, gha, tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8048180-investigate-eager-reclaim-of-reference-arrays
>  - * more documentation work
>  - * walulyai review, improved comments, example
>  - * also check for actual region reclamation
>    
>    * enable reference array reclaim anywhere during non-marking, enable during rebuild
>    
>    * additional test for all situation
>    
>    * fix guarantee for humongous regular objects
>    
>    * need to clear card table of eagerly reclaimed regions
>    
>    * do not redirty recently freed humongous regions to avoid stray card marks
>    
>    * card table of humongous-continues regions has not been cleared
>    
>    * some cleanup
>    
>    * include non-typeArrays allocated after mark start in candidates
>    * and allow non-typeArray candidates right after marking completed
>    
>    * update test case to also check allocations after marking
>    * additional documentation
>    
>    * rename test case
>    
>    * more explanations
>    
>    * move back free humongous regions to post evacuate 2. There does not seem to be a reason to put it there, and it clashes with RecalculateUsedTask.

Maybe the title should have `G1: ` prefix?

src/hotspot/share/gc/g1/g1YoungCollector.cpp line 401:

> 399:       bool mark_in_progress = _g1h->collector_state()->mark_in_progress();
> 400:       return (obj->is_typeArray() || (G1EagerReclaimWithRefs && (allocated_after_mark_start || !mark_in_progress))) &&
> 401:              _g1h->is_potential_eager_reclaim_candidate(region);

I'd suggest rewriting this a bit (e.g. using early-return or sth) -- the current form is not super clear.

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

PR Review: https://git.openjdk.org/jdk/pull/27525#pullrequestreview-3318815681
PR Review Comment: https://git.openjdk.org/jdk/pull/27525#discussion_r2416688088

From tschatzl at openjdk.org  Thu Oct  9 13:01:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 9 Oct 2025 13:01:27 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v5]
In-Reply-To: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
Message-ID: <6Pi1SBxJC0Su6UC1yUdkV4BKBq3MSoRtA3YQVvv9WTo=.ce0cfd8a-7614-42ad-8887-47f6d4c1caa8@github.com>

> Hi all,
> 
>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
> 
> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
> 
> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
> 
> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
> 
> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>  
> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
> 
> Testing: new test cases, gha, tier1-5
> 
> Thanks,
>   Thomas

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

  * use enums instead of rows of booleans to make test more understandable, from iwalulya

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27525/files
  - new: https://git.openjdk.org/jdk/pull/27525/files/afcac13a..d5dcfc86

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

  Stats: 67 lines in 1 file changed: 31 ins; 1 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/27525.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27525/head:pull/27525

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

From tschatzl at openjdk.org  Thu Oct  9 13:01:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 9 Oct 2025 13:01:29 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v4]
In-Reply-To: <3fZ_ZIbAH5ZPoVJBSZaOyINSeZMJi1sQqnaUvxHrWdA=.e88b2d01-0e0b-4b5f-a0c0-3f5950452eba@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
 <SP5v_AspB4EdQb3gzzIZYwLgNoy1WaBVXx559DRMKQg=.c32fafdd-b9e8-47b3-804f-aab8578334ec@github.com>
 <3fZ_ZIbAH5ZPoVJBSZaOyINSeZMJi1sQqnaUvxHrWdA=.e88b2d01-0e0b-4b5f-a0c0-3f5950452eba@github.com>
Message-ID: <WQMACzEdE6B2SP1uYy9KVb-MVbHCDu8QNjI63dP_Lto=.a92e232b-59fc-4621-ac6e-4616790a5c0f@github.com>

On Thu, 9 Oct 2025 12:49:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Maybe the title should have `G1: ` prefix?

It's a very old enhancement. Fixed.

> src/hotspot/share/gc/g1/g1YoungCollector.cpp line 401:
> 
>> 399:       bool mark_in_progress = _g1h->collector_state()->mark_in_progress();
>> 400:       return (obj->is_typeArray() || (G1EagerReclaimWithRefs && (allocated_after_mark_start || !mark_in_progress))) &&
>> 401:              _g1h->is_potential_eager_reclaim_candidate(region);
> 
> I'd suggest rewriting this a bit (e.g. using early-return or sth) -- the current form is not super clear.

Are you okay with removing the `G1EagerReclaimWithRefs` flag? Then it becomes a bit easier by itself.

The logical or does not lend itself very well to early returns.

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

PR Comment: https://git.openjdk.org/jdk/pull/27525#issuecomment-3385743346
PR Review Comment: https://git.openjdk.org/jdk/pull/27525#discussion_r2416713016

From tschatzl at openjdk.org  Thu Oct  9 13:11:48 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 9 Oct 2025 13:11:48 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v4]
In-Reply-To: <WQMACzEdE6B2SP1uYy9KVb-MVbHCDu8QNjI63dP_Lto=.a92e232b-59fc-4621-ac6e-4616790a5c0f@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
 <SP5v_AspB4EdQb3gzzIZYwLgNoy1WaBVXx559DRMKQg=.c32fafdd-b9e8-47b3-804f-aab8578334ec@github.com>
 <3fZ_ZIbAH5ZPoVJBSZaOyINSeZMJi1sQqnaUvxHrWdA=.e88b2d01-0e0b-4b5f-a0c0-3f5950452eba@github.com>
 <WQMACzEdE6B2SP1uYy9KVb-MVbHCDu8QNjI63dP_Lto=.a92e232b-59fc-4621-ac6e-4616790a5c0f@github.com>
Message-ID: <3u12eKqjaMrtSrrwaGWSed8UyW_5qGkQLl1aphD4tRo=.4627d381-c4d2-41ed-97f3-3e954035569e@github.com>

On Thu, 9 Oct 2025 12:58:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1YoungCollector.cpp line 401:
>> 
>>> 399:       bool mark_in_progress = _g1h->collector_state()->mark_in_progress();
>>> 400:       return (obj->is_typeArray() || (G1EagerReclaimWithRefs && (allocated_after_mark_start || !mark_in_progress))) &&
>>> 401:              _g1h->is_potential_eager_reclaim_candidate(region);
>> 
>> I'd suggest rewriting this a bit (e.g. using early-return or sth) -- the current form is not super clear.
>
> Are you okay with removing the `G1EagerReclaimWithRefs` flag? Then it becomes a bit easier by itself.
> 
> The logical or does not lend itself very well to early returns.

Suggestion:

      if (!obj->is_typeArray()) {
        if (!G1EagerReclaimWithRefs) {
          return false;
        }
        // All regions that were allocated before marking have a TAMS != bottom.
        bool allocated_before_mark_start = region->bottom() != _g1h->concurrent_mark()->top_at_mark_start(region);
        bool mark_in_progress = _g1h->collector_state()->mark_in_progress();

        if (allocated_before_mark_start && mark_in_progress) {
          return false;
        }
      }
      return _g1h->is_potential_eager_reclaim_candidate(region);

Maybe something like this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27525#discussion_r2416743143

From tschatzl at openjdk.org  Thu Oct  9 13:16:24 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 9 Oct 2025 13:16:24 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v6]
In-Reply-To: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
Message-ID: <Sl2MbyoanjDPnOZ6Un2BvXH_U57Pgfy483AK4745Vi0=.f9bd51d6-036e-4704-b26e-086547213837@github.com>

> Hi all,
> 
>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
> 
> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
> 
> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
> 
> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
> 
> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>  
> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
> 
> Testing: new test cases, gha, tier1-5
> 
> Thanks,
>   Thomas

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

  * fix parameter documentation in the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27525/files
  - new: https://git.openjdk.org/jdk/pull/27525/files/d5dcfc86..1f426a79

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

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

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

From jsikstro at openjdk.org  Thu Oct  9 13:55:30 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 9 Oct 2025 13:55:30 GMT
Subject: RFR: 8369501: Parallel: Add UseAdaptiveSizePolicy requirement to
 TestDynShrinkHeap.java
In-Reply-To: <U3EAg0A6zpG7EMRoe50l079OtyhIWgegrRHzFiXEnNA=.98cf4423-6279-4daf-b994-6d53f3ef568a@github.com>
References: <U3EAg0A6zpG7EMRoe50l079OtyhIWgegrRHzFiXEnNA=.98cf4423-6279-4daf-b994-6d53f3ef568a@github.com>
Message-ID: <v8UAAjt9tN0MWqNtNmg4IG6oHuHM4BT0T2EmOxzP8D0=.e401fb58-ab8c-4505-adff-9e428deb26c8@github.com>

On Thu, 9 Oct 2025 12:29:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add a `@requires` to this test so that it will be skipped if `UseAdaptiveSizePolicy` is off.
> 
> Test: tier1-3

Looks good!

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27724#pullrequestreview-3319102326

From tschatzl at openjdk.org  Thu Oct  9 14:16:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 9 Oct 2025 14:16:03 GMT
Subject: RFR: 8369501: Parallel: Add UseAdaptiveSizePolicy requirement to
 TestDynShrinkHeap.java
In-Reply-To: <U3EAg0A6zpG7EMRoe50l079OtyhIWgegrRHzFiXEnNA=.98cf4423-6279-4daf-b994-6d53f3ef568a@github.com>
References: <U3EAg0A6zpG7EMRoe50l079OtyhIWgegrRHzFiXEnNA=.98cf4423-6279-4daf-b994-6d53f3ef568a@github.com>
Message-ID: <n-NyiQDSPqSiLXivMH98bbAb49dwQ6xN838CmliBJy4=.49c4048b-3da9-4c5f-bc6c-a35a83c710e2@github.com>

On Thu, 9 Oct 2025 12:29:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add a `@requires` to this test so that it will be skipped if `UseAdaptiveSizePolicy` is off.
> 
> Test: tier1-3

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27724#pullrequestreview-3319209789

From tschatzl at openjdk.org  Thu Oct  9 14:24:12 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 9 Oct 2025 14:24:12 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v7]
In-Reply-To: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
Message-ID: <D4Tt5VJnZyf9qwHixrlRV0eWf3y_vUcufwO9nb5HLt0=.daa186ec-dfd6-4807-afbf-31d9c11eedae@github.com>

> Hi all,
> 
>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
> 
> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
> 
> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
> 
> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
> 
> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>  
> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
> 
> Testing: new test cases, gha, tier1-5
> 
> Thanks,
>   Thomas

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

  * remove G1EagerReclaimWithRefs flag
  * improve readability of condition to make a humongous object eager reclaim candidate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27525/files
  - new: https://git.openjdk.org/jdk/pull/27525/files/1f426a79..fbb3282c

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

  Stats: 18 lines in 4 files changed: 7 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/27525.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27525/head:pull/27525

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

From kdnilsen at openjdk.org  Thu Oct  9 15:38:31 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 9 Oct 2025 15:38:31 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v25]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <ALo3o-FABwYhVxkPQmHOSzkhpqvowev4H09sEnH4yVQ=.a1e2a976-0b3b-4a39-a234-4be68c2bf8f0@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:

  clamp SoftMaxHeapSize during initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/9c2dc8bd..9b36ee38

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

  Stats: 1 line in 1 file changed: 0 ins; 0 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 duke at openjdk.org  Thu Oct  9 15:46:45 2025
From: duke at openjdk.org (Benjamin Peterson)
Date: Thu, 9 Oct 2025 15:46:45 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v7]
In-Reply-To: <D4Tt5VJnZyf9qwHixrlRV0eWf3y_vUcufwO9nb5HLt0=.daa186ec-dfd6-4807-afbf-31d9c11eedae@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
 <D4Tt5VJnZyf9qwHixrlRV0eWf3y_vUcufwO9nb5HLt0=.daa186ec-dfd6-4807-afbf-31d9c11eedae@github.com>
Message-ID: <Jro6M_mL3qeKizmHnQtWJNjZmUohZBKf47X0pYo4-Yw=.c4c0a107-3650-43f0-af4e-f9bf430faf96@github.com>

On Thu, 9 Oct 2025 14:24:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
>> 
>> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
>> 
>> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
>> 
>> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
>> 
>> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>>  
>> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
>> 
>> Testing: new test cases, gha, tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove G1EagerReclaimWithRefs flag
>   * improve readability of condition to make a humongous object eager reclaim candidate

src/hotspot/share/gc/g1/g1RemSetTrackingPolicy.cpp line 56:

> 54: 
> 55:   bool selected_for_rebuild = false;
> 56:   // Humongous regions containing type-array objs are remset-tracked to

comment needs an update?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27525#discussion_r2417196485

From ayang at openjdk.org  Thu Oct  9 18:02:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 9 Oct 2025 18:02:14 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v10]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <PRyBugfW89KkrkVGE-8FS6SgVRhl9ZdeAnCae1NrKBc=.8be95742-6e4a-4fcf-91aa-7914f0ddd0f5@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 14 additional commits since the last revision:

 - Merge branch 'master' into pgc-largepage
 - review
 - Merge branch 'master' into pgc-largepage
 - review
 - review
 - review
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - page-size
 - ... and 4 more: https://git.openjdk.org/jdk/compare/95bd1bb8...e02d0bf8

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/421f1c4d..e02d0bf8

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

  Stats: 13086 lines in 471 files changed: 8379 ins; 2430 del; 2277 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 wkemper at openjdk.org  Thu Oct  9 18:23:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Oct 2025 18:23:18 GMT
Subject: RFR: 8367646: [GenShen] Control thread may overwrite gc
 cancellation cause set by mutator [v2]
In-Reply-To: <b8tVsZGnEjAcDe9Gv_FxrFUKRIjjxKVUqWMmpdsRsuk=.4ad87533-66ee-4a9f-bc9e-3ef4f8d2f58d@github.com>
References: <RkO54i4ljRW9vD9TgxLmiXr5d513yDJXfjaoT8A4V7A=.d9716380-6be9-4b04-a588-621fc81621db@github.com>
 <b8tVsZGnEjAcDe9Gv_FxrFUKRIjjxKVUqWMmpdsRsuk=.4ad87533-66ee-4a9f-bc9e-3ef4f8d2f58d@github.com>
Message-ID: <7BoGRpmSZdCjG9_UU0rXLPsE-kuqVItzKJf-cg6zABA=.f64b879b-2f00-464b-98f7-f358a8c5920e@github.com>

On Thu, 9 Oct 2025 01:55:52 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix cancellation time management, simplify normal cancellation API
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp line 116:
> 
>> 114:     if (request.cause == GCCause::_shenandoah_concurrent_gc) {
>> 115:       request.generation = _heap->young_generation();
>> 116:       _heap->clear_cancelled_gc(false);
> 
> It appears as if this was the _only_ case where `clear_cancelled_gc()` was called while not clearing the oom_handler.
> 
> Should `clear_cancelled_gc()` be modified by removing the option/argument for clearing or not the oom_handler?

Good catch. When fixing this, I also realized that the new `clear_cancellation` wasn't handling the `_cancel_requested_time` as it should.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27662#discussion_r2417607745

From wkemper at openjdk.org  Thu Oct  9 18:23:17 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Oct 2025 18:23:17 GMT
Subject: RFR: 8367646: [GenShen] Control thread may overwrite gc
 cancellation cause set by mutator [v2]
In-Reply-To: <RkO54i4ljRW9vD9TgxLmiXr5d513yDJXfjaoT8A4V7A=.d9716380-6be9-4b04-a588-621fc81621db@github.com>
References: <RkO54i4ljRW9vD9TgxLmiXr5d513yDJXfjaoT8A4V7A=.d9716380-6be9-4b04-a588-621fc81621db@github.com>
Message-ID: <A-35ACFfmQ-D19Rdb-oXVnldd4-o_91D_qX3anDWmFs=.90eae913-fc24-4dfa-83f1-983a1bc46653@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 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.

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

  Fix cancellation time management, simplify normal cancellation API

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27662/files
  - new: https://git.openjdk.org/jdk/pull/27662/files/d9697d83..b3a96523

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

  Stats: 23 lines in 5 files changed: 8 ins; 2 del; 13 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 wkemper at openjdk.org  Thu Oct  9 18:28:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 9 Oct 2025 18:28:21 GMT
Subject: Integrated: 8368501: Shenandoah: GC progress evaluation does not use
 generation
In-Reply-To: <Qn6FDlj32BhpX--A-sebLeUUJpc0zk_jlA39Tm9hbSA=.43c28844-62cf-44a2-a3cc-6b2b85744592@github.com>
References: <Qn6FDlj32BhpX--A-sebLeUUJpc0zk_jlA39Tm9hbSA=.43c28844-62cf-44a2-a3cc-6b2b85744592@github.com>
Message-ID: <LdusbaDNBuR4iiNZ6bOWEO31qXilogLqL5Y7UZBVsvo=.b2238e3f-1ec3-40bb-98ee-c23cbe98478e@github.com>

On Mon, 29 Sep 2025 21:24:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove unused `generation` parameter from stop-the-world GC progress evaluation. Also, have `shMetrics` use the freeset for `usage`  details. This is a follow up to a comment from an unrelated PR: https://github.com/openjdk/jdk/pull/27456#issuecomment-3325724362.

This pull request has now been integrated.

Changeset: 501fa204
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/501fa2041a77139a9ac42fef69f28b1fd50fee65
Stats:     79 lines in 4 files changed: 6 ins; 37 del; 36 mod

8368501: Shenandoah: GC progress evaluation does not use generation

Reviewed-by: ysr

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

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

From ayang at openjdk.org  Thu Oct  9 19:42:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 9 Oct 2025 19:42:16 GMT
Subject: RFR: 8369420: Parallel: Use multiple workers for class unloading
 [v3]
In-Reply-To: <cPmugAtIvwNzWGvT4kR-pzV-UJQxo5C8-wnEgML36GA=.03530600-d91a-428e-a79b-2c2b757e445c@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
 <cPmugAtIvwNzWGvT4kR-pzV-UJQxo5C8-wnEgML36GA=.03530600-d91a-428e-a79b-2c2b757e445c@github.com>
Message-ID: <szkLmwBtQW5uddjDqVW3Yp5HdBOkNj3q3C2_21E69BY=.e25414ac-ffe3-4505-b8b8-128758fa5daa@github.com>

On Wed, 8 Oct 2025 14:38:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27689#issuecomment-3387249443

From ayang at openjdk.org  Thu Oct  9 19:42:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 9 Oct 2025 19:42:17 GMT
Subject: Integrated: 8369420: Parallel: Use multiple workers for class
 unloading
In-Reply-To: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
References: <V8JFI65NJVZtRORqwbuial74uSRm77wQ2-oTUSnd9bI=.707a1d62-5b32-41c5-a115-3a33a810376e@github.com>
Message-ID: <QBJhL_iQJYqtzQGizDzca77WoF0KUlUsqExiuVl4TwY=.1ebc1b19-38df-4fcd-a543-23c6e0ae3642@github.com>

On Wed, 8 Oct 2025 10:58:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Support parallel class unloading in ParallelGC. Much inspiration taken from `G1ParallelCleaningTask`.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: 1cdd241f
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1cdd241ff3ed57a4df4bac54b2659d68d161b53c
Stats:     46 lines in 1 file changed: 35 ins; 7 del; 4 mod

8369420: Parallel: Use multiple workers for class unloading

Reviewed-by: fandreuzzi, tschatzl, zgu

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

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

From ysr at openjdk.org  Thu Oct  9 23:38:04 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 9 Oct 2025 23:38:04 GMT
Subject: RFR: 8367646: [GenShen] Control thread may overwrite gc
 cancellation cause set by mutator [v2]
In-Reply-To: <A-35ACFfmQ-D19Rdb-oXVnldd4-o_91D_qX3anDWmFs=.90eae913-fc24-4dfa-83f1-983a1bc46653@github.com>
References: <RkO54i4ljRW9vD9TgxLmiXr5d513yDJXfjaoT8A4V7A=.d9716380-6be9-4b04-a588-621fc81621db@github.com>
 <A-35ACFfmQ-D19Rdb-oXVnldd4-o_91D_qX3anDWmFs=.90eae913-fc24-4dfa-83f1-983a1bc46653@github.com>
Message-ID: <rW9DvdZy8BnIGpFv17NwkI8_Bc327Ku-v_DwoDa49lU=.49196539-e266-4c35-b8ca-5fb95519e06b@github.com>

On Thu, 9 Oct 2025 18:23:17 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.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cancellation time management, simplify normal cancellation API

LGTM!

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

Marked as reviewed by ysr (Reviewer).

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

From ysr at openjdk.org  Thu Oct  9 23:47:05 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 9 Oct 2025 23:47:05 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v4]
In-Reply-To: <u9GVAOeNkg5TL2dBBEWLDZNrMvxBYlFdUeXdRQl1VIs=.4e1ebef5-8a2c-49f8-974a-15d840ad75eb@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
 <u9GVAOeNkg5TL2dBBEWLDZNrMvxBYlFdUeXdRQl1VIs=.4e1ebef5-8a2c-49f8-974a-15d840ad75eb@github.com>
Message-ID: <yjkVPu3243hAsJoevFrjsH7v-_1UBiwGFCJEB6MkARI=.21b4b659-85df-4dec-b478-9fc1ae7ada17@github.com>

On Tue, 7 Oct 2025 22:32:56 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:
> 
>   Review feedback, bug fixes

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

@earthling-amzn : Can the comparisons be done in each of the two classes, i.e. x86 and aarch64, separately? Not sure if it'll give more statistically significant differences between test and control.

Was there any significant difference (on x86 or aarch64 separately) on SPECjbb?

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

PR Comment: https://git.openjdk.org/jdk/pull/27632#issuecomment-3387799702

From wkemper at openjdk.org  Fri Oct 10 00:19:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 10 Oct 2025 00:19:13 GMT
Subject: Integrated: 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: <OQJuIlZmaWHuf7nPSrQzjqp0XcZpZ7N6RDs1wakHVbo=.0709528b-d772-4cb2-95e2-0f6429c50a09@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.

This pull request has now been integrated.

Changeset: d6e2d4eb
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d6e2d4eb1f87016ab158b62c61c33c4bf92a0ed4
Stats:     32 lines in 6 files changed: 19 ins; 5 del; 8 mod

8367646: [GenShen] Control thread may overwrite gc cancellation cause set by mutator

Reviewed-by: ysr, kdnilsen

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

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

From tschatzl at openjdk.org  Fri Oct 10 07:14:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 10 Oct 2025 07:14:40 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v8]
In-Reply-To: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
Message-ID: <ofLk7CDj-xOpOgtGxNrHtHrEVaFWxuDtAXuqNYPe5lk=.ea2f7e8b-57bd-47f8-9871-e5fedfc81ffe@github.com>

> Hi all,
> 
>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
> 
> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
> 
> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
> 
> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
> 
> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>  
> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
> 
> Testing: new test cases, gha, tier1-5
> 
> Thanks,
>   Thomas

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

  * fix up documentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27525/files
  - new: https://git.openjdk.org/jdk/pull/27525/files/fbb3282c..28fd9809

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

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

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

From tschatzl at openjdk.org  Fri Oct 10 07:43:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 10 Oct 2025 07:43:39 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v9]
In-Reply-To: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
Message-ID: <biaw9oJpNRhpR1QXQbiAh3pP-WMZpoDWxUt8jCHepI0=.8fb8114b-edd4-4f05-bc9f-c06841f9386e@github.com>

> Hi all,
> 
>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
> 
> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
> 
> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
> 
> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
> 
> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>  
> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
> 
> Testing: new test cases, gha, tier1-5
> 
> Thanks,
>   Thomas

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

  * some more documentation corrections

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27525/files
  - new: https://git.openjdk.org/jdk/pull/27525/files/28fd9809..f2113f59

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

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

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

From aboldtch at openjdk.org  Fri Oct 10 07:54:28 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 10 Oct 2025 07:54:28 GMT
Subject: RFR: 8351137: ZGC: Improve ZValueStorage alignment support [v5]
In-Reply-To: <GNS93cR60yXhAg3e7xq700RXmu-pYa6muIwmfJIBrac=.f1991bdf-d6fc-4255-8f04-c5717455baa6@github.com>
References: <GNS93cR60yXhAg3e7xq700RXmu-pYa6muIwmfJIBrac=.f1991bdf-d6fc-4255-8f04-c5717455baa6@github.com>
Message-ID: <kjs7P1yKOA53i6i0aMfGFzQ-Kt9IHATpviOUpUJC7D4=.0d02c2a5-4904-405c-9177-de9ff766492a@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 five additional commits since the last revision:

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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23887/files
  - new: https://git.openjdk.org/jdk/pull/23887/files/989be624..3855f1e7

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

  Stats: 13098 lines in 507 files changed: 8331 ins; 2505 del; 2262 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 aboldtch at openjdk.org  Fri Oct 10 07:54:46 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 10 Oct 2025 07:54:46 GMT
Subject: RFR: 8367317: ZGC:
 ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow [v4]
In-Reply-To: <MrtRg-MtrMA5rRk0qu4Jd2tTJuMdEVi43XeQF05jUtI=.6ebb93f7-39d1-4f13-aaff-db62d99a0846@github.com>
References: <MrtRg-MtrMA5rRk0qu4Jd2tTJuMdEVi43XeQF05jUtI=.6ebb93f7-39d1-4f13-aaff-db62d99a0846@github.com>
Message-ID: <F1LGmfdM8UPyHo1_SRxA4-hJbY2F1pGXjOZVEhMAdk4=.7f979882-3cd3-466c-9fb1-3eec664e6ff0@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 four additional commits since the last revision:

 - Merge tag 'jdk-26+19' into JDK-8367317
   
   Added tag jdk-26+19 for changeset b37a1a33
 - 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/0068e956..da962d1f

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

  Stats: 13098 lines in 507 files changed: 8331 ins; 2505 del; 2262 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 ayang at openjdk.org  Fri Oct 10 10:22:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 10:22:03 GMT
Subject: RFR: 8369501: Parallel: Add UseAdaptiveSizePolicy requirement to
 TestDynShrinkHeap.java
In-Reply-To: <U3EAg0A6zpG7EMRoe50l079OtyhIWgegrRHzFiXEnNA=.98cf4423-6279-4daf-b994-6d53f3ef568a@github.com>
References: <U3EAg0A6zpG7EMRoe50l079OtyhIWgegrRHzFiXEnNA=.98cf4423-6279-4daf-b994-6d53f3ef568a@github.com>
Message-ID: <OV1TAChystVmkeDBiVjlrYR2nJteWNkuVrVSwXHU6Rw=.c7ca3af0-3ad4-4657-9578-81611443ef41@github.com>

On Thu, 9 Oct 2025 12:29:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add a `@requires` to this test so that it will be skipped if `UseAdaptiveSizePolicy` is off.
> 
> Test: tier1-3

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27724#issuecomment-3389219969

From ayang at openjdk.org  Fri Oct 10 10:22:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 10:22:04 GMT
Subject: Integrated: 8369501: Parallel: Add UseAdaptiveSizePolicy requirement
 to TestDynShrinkHeap.java
In-Reply-To: <U3EAg0A6zpG7EMRoe50l079OtyhIWgegrRHzFiXEnNA=.98cf4423-6279-4daf-b994-6d53f3ef568a@github.com>
References: <U3EAg0A6zpG7EMRoe50l079OtyhIWgegrRHzFiXEnNA=.98cf4423-6279-4daf-b994-6d53f3ef568a@github.com>
Message-ID: <cEg2w6ZCGthwzHNrJOKwYd7oKjFxKHj4-0n7aZ9jMoo=.716d6a84-9ed7-4bd4-87c4-bda8ba891c29@github.com>

On Thu, 9 Oct 2025 12:29:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add a `@requires` to this test so that it will be skipped if `UseAdaptiveSizePolicy` is off.
> 
> Test: tier1-3

This pull request has now been integrated.

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

8369501: Parallel: Add UseAdaptiveSizePolicy requirement to TestDynShrinkHeap.java

Reviewed-by: jsikstro, tschatzl

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

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

From ayang at openjdk.org  Fri Oct 10 10:24:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 10:24:19 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v11]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <7YuWeb6DicHor6bJexJeaMHUYYh2drv2jpj-8WMgAyg=.00e935c9-ba97-487a-bb94-2f9ab5953cfc@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 15 additional commits since the last revision:

 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - review
 - Merge branch 'master' into pgc-largepage
 - review
 - review
 - review
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - ... and 5 more: https://git.openjdk.org/jdk/compare/266d2e3f...dca26616

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/e02d0bf8..dca26616

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

  Stats: 2992 lines in 81 files changed: 2039 ins; 737 del; 216 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  Fri Oct 10 11:24:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 11:24:03 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v9]
In-Reply-To: <biaw9oJpNRhpR1QXQbiAh3pP-WMZpoDWxUt8jCHepI0=.8fb8114b-edd4-4f05-bc9f-c06841f9386e@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
 <biaw9oJpNRhpR1QXQbiAh3pP-WMZpoDWxUt8jCHepI0=.8fb8114b-edd4-4f05-bc9f-c06841f9386e@github.com>
Message-ID: <eD6K9zZbOCviss92reqzF0GCM6wCOIt7oQqwfo4YvxM=.282a3313-f245-423d-8ee0-3aff8b9f74b4@github.com>

On Fri, 10 Oct 2025 07:43:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
>> 
>> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
>> 
>> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
>> 
>> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
>> 
>> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>>  
>> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
>> 
>> Testing: new test cases, gha, tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * some more documentation corrections

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27525#pullrequestreview-3322745951

From jsikstro at openjdk.org  Fri Oct 10 11:38:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 10 Oct 2025 11:38:07 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v11]
In-Reply-To: <7YuWeb6DicHor6bJexJeaMHUYYh2drv2jpj-8WMgAyg=.00e935c9-ba97-487a-bb94-2f9ab5953cfc@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <7YuWeb6DicHor6bJexJeaMHUYYh2drv2jpj-8WMgAyg=.00e935c9-ba97-487a-bb94-2f9ab5953cfc@github.com>
Message-ID: <-VmhyEUjFQL-ij7T7MqH8QbvkJZyhBxbhxdwe91T2AI=.a2978773-192d-40d3-b6d6-a9a0cf288c3c@github.com>

On Fri, 10 Oct 2025 10:24:19 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 15 additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - review
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/edcedec4...dca26616

I have a few small comments, but I think this looks pretty good now.

src/hotspot/share/gc/parallel/mutableNUMASpace.cpp line 368:

> 366:         new_region = MemRegion(ps->end(), end());
> 367:       }
> 368:     }

This is technically fine, but maybe we can combine the else and the if to something like below to fit better with the comments?

if (i == 0) { // Bottom chunk
...
} else if (i < lgrp_spaces()->length() - 1) { // Middle chunks
...
} else { // Top chunk
...
}

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

PR Review: https://git.openjdk.org/jdk/pull/26700#pullrequestreview-3309512696
PR Review Comment: https://git.openjdk.org/jdk/pull/26700#discussion_r2419401651

From jsikstro at openjdk.org  Fri Oct 10 11:38:10 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 10 Oct 2025 11:38:10 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v9]
In-Reply-To: <T6RXJdnu8g2qYttfO-U5dClh6O9y-c1kT67kTRF7Nis=.6d5a6f48-1f97-4295-adf1-201d1565e916@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <T6RXJdnu8g2qYttfO-U5dClh6O9y-c1kT67kTRF7Nis=.6d5a6f48-1f97-4295-adf1-201d1565e916@github.com>
Message-ID: <tuIt3d_WMEcLdS3_o_xTmEvD5ZE78mvluSE8Vkwh8Tw=.6fbb0479-becc-433c-8b35-503c86ef9247@github.com>

On Fri, 3 Oct 2025 14:44:15 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 incrementally with one additional commit since the last revision:
> 
>   review

src/hotspot/share/gc/parallel/mutableNUMASpace.hpp line 129:

> 127: 
> 128:   size_t _base_space_size;
> 129:   void set_base_space_size(size_t v)                 { _base_space_size = v;      }

These are unused.

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

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

From iwalulya at openjdk.org  Fri Oct 10 11:40:03 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 10 Oct 2025 11:40:03 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v9]
In-Reply-To: <biaw9oJpNRhpR1QXQbiAh3pP-WMZpoDWxUt8jCHepI0=.8fb8114b-edd4-4f05-bc9f-c06841f9386e@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
 <biaw9oJpNRhpR1QXQbiAh3pP-WMZpoDWxUt8jCHepI0=.8fb8114b-edd4-4f05-bc9f-c06841f9386e@github.com>
Message-ID: <nTt9eRHRHZEOrnhZ3N4XYVZMNrlbyyYsURxHkO-ERQA=.0a677f81-09a7-42b2-9c32-f95a42f1b916@github.com>

On Fri, 10 Oct 2025 07:43:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
>> 
>> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
>> 
>> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
>> 
>> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
>> 
>> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>>  
>> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
>> 
>> Testing: new test cases, gha, tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * some more documentation corrections

Still good!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27525#pullrequestreview-3322832549

From ayang at openjdk.org  Fri Oct 10 12:39:21 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 12:39:21 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v12]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <V-slA9QaaIYkGI8efREcKDnYVjVJyycH7lBh_OHwUIY=.6704ab74-47c6-47c4-b988-26e504a9323a@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/dca26616..a6bafe71

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

  Stats: 12 lines in 2 files changed: 0 ins; 5 del; 7 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 fandreuzzi at openjdk.org  Fri Oct 10 12:52:07 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 10 Oct 2025 12:52:07 GMT
Subject: RFR: 8369097: Parallel: Support allocation in from space when heap
 is too full [v2]
In-Reply-To: <tEPyKb2hRrAVZqICMLhKWB1Uu8uw92ahSXCpAe2pDmI=.3f51ab7b-e6d2-4d9b-a826-725a386386ea@github.com>
References: <uEZ5wcprvd6EY5dh9ZI52Br4ybO9L3Z5CkldaEuh2wE=.b9e07a4d-c62e-473d-b502-d831cb2a5b7a@github.com>
 <tEPyKb2hRrAVZqICMLhKWB1Uu8uw92ahSXCpAe2pDmI=.3f51ab7b-e6d2-4d9b-a826-725a386386ea@github.com>
Message-ID: <sHEK3ZFlmipk-oDPVpzY0uBxZ2SCK29WSSFCKkDXxlc=.df35a3f8-931e-47b5-8fb1-adf7fd2dadd0@github.com>

On Tue, 7 Oct 2025 18:25:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27620#pullrequestreview-3323226509

From jsikstro at openjdk.org  Fri Oct 10 14:16:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 10 Oct 2025 14:16:55 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v12]
In-Reply-To: <V-slA9QaaIYkGI8efREcKDnYVjVJyycH7lBh_OHwUIY=.6704ab74-47c6-47c4-b988-26e504a9323a@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <V-slA9QaaIYkGI8efREcKDnYVjVJyycH7lBh_OHwUIY=.6704ab74-47c6-47c4-b988-26e504a9323a@github.com>
Message-ID: <Tjx_n1Q6Z-w9m2iKDFSKLXIxzlLudrbdfi48gBbeHXw=.9b56cafd-7ac6-4bfe-8ee2-0b8cd7a8e929@github.com>

On Fri, 10 Oct 2025 12:39:21 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 incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by jsikstro (Reviewer).

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

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

From ayang at openjdk.org  Fri Oct 10 14:47:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 14:47:22 GMT
Subject: RFR: 8369571: Parallel: Use ThreadsClaimTokenScope in PSAdjustTask
Message-ID: <jVdTn-ro42G0dvB6GuW7ZKQ89Lp5AGccowIro8zHvAo=.e55f17ec-c1c0-4cd1-abe2-8a1b6e044fe8@github.com>

Trivial lifting threads claim token logic into using the existing `ThreadsClaimTokenScope`.

Test: tier1

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

Commit messages:
 - pgc-thread-claim-scope

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

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

From fandreuzzi at openjdk.org  Fri Oct 10 14:51:54 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 10 Oct 2025 14:51:54 GMT
Subject: RFR: 8369571: Parallel: Use ThreadsClaimTokenScope in PSAdjustTask
In-Reply-To: <jVdTn-ro42G0dvB6GuW7ZKQ89Lp5AGccowIro8zHvAo=.e55f17ec-c1c0-4cd1-abe2-8a1b6e044fe8@github.com>
References: <jVdTn-ro42G0dvB6GuW7ZKQ89Lp5AGccowIro8zHvAo=.e55f17ec-c1c0-4cd1-abe2-8a1b6e044fe8@github.com>
Message-ID: <383b6SIVPVU1-WmSF--IlZVhyZIQpuD1ER6Yp_w7t7M=.6a02265a-0d59-4337-b8ac-483ee49b3f49@github.com>

On Fri, 10 Oct 2025 14:39:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial lifting threads claim token logic into using the existing `ThreadsClaimTokenScope`.
> 
> Test: tier1

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27746#pullrequestreview-3324055955

From ayang at openjdk.org  Fri Oct 10 18:04:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 18:04:13 GMT
Subject: RFR: 8369097: Parallel: Support allocation in from space when heap
 is too full [v2]
In-Reply-To: <tEPyKb2hRrAVZqICMLhKWB1Uu8uw92ahSXCpAe2pDmI=.3f51ab7b-e6d2-4d9b-a826-725a386386ea@github.com>
References: <uEZ5wcprvd6EY5dh9ZI52Br4ybO9L3Z5CkldaEuh2wE=.b9e07a4d-c62e-473d-b502-d831cb2a5b7a@github.com>
 <tEPyKb2hRrAVZqICMLhKWB1Uu8uw92ahSXCpAe2pDmI=.3f51ab7b-e6d2-4d9b-a826-725a386386ea@github.com>
Message-ID: <Cy1ht8ofsZpR9KfJDFr0E1OA-peBNqdpKyTbDs6ZBg8=.39a4d6b3-1875-48fe-8fd5-8f8b8a3f6c3a@github.com>

On Tue, 7 Oct 2025 18:25:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27620#issuecomment-3391562895

From ayang at openjdk.org  Fri Oct 10 18:04:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 18:04:15 GMT
Subject: Integrated: 8369097: Parallel: Support allocation in from space when
 heap is too full
In-Reply-To: <uEZ5wcprvd6EY5dh9ZI52Br4ybO9L3Z5CkldaEuh2wE=.b9e07a4d-c62e-473d-b502-d831cb2a5b7a@github.com>
References: <uEZ5wcprvd6EY5dh9ZI52Br4ybO9L3Z5CkldaEuh2wE=.b9e07a4d-c62e-473d-b502-d831cb2a5b7a@github.com>
Message-ID: <j4A1UN3f18IiVkyamvLVZAPFKU7mEw4b5K4TE8D-rHo=.c0ad7bc0-7883-4d53-abbc-74bde9123f23@github.com>

On Fri, 3 Oct 2025 08:31:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 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

This pull request has now been integrated.

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

8369097: Parallel: Support allocation in from space when heap is too full

Reviewed-by: tschatzl, fandreuzzi

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

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

From wkemper at openjdk.org  Fri Oct 10 19:49:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 10 Oct 2025 19:49:47 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v5]
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: <Ky5kzy7jSV4jT3YKfDrnA2KqAFfVlGdnuT52NSq6_go=.76d5eabb-0806-4bfa-8eaf-99fd43eec8a9@github.com>

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

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

 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Review feedback, bug fixes
 - Fix windows build more
 - Fix windows build
 - 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
 - ... and 46 more: https://git.openjdk.org/jdk/compare/7e29d294...c51ed54c

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

Changes: https://git.openjdk.org/jdk/pull/27632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=04
  Stats: 340 lines in 16 files changed: 172 ins; 91 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/27632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27632/head:pull/27632

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

From xpeng at openjdk.org  Fri Oct 10 23:15:15 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 10 Oct 2025 23:15:15 GMT
Subject: RFR: 8369611: Remove safepoint synchronization from
 ParallelScavengeHeap and SerialHeap
Message-ID: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>

In the discussion of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), @kimbarrett pointed out that StringDedup thread is now derived from JavaThread, but ParallelScavengeHeap and SerialHeap still have conditional STS synchronization at safepoint, which is not needed, as a result of removing the conditional STS synchronization, we could remove the remove safepoint synchronization from ParallelScavengeHeap and SerialHeap.

Test:
  - [x] tier1

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

Commit messages:
 - 8369611: Remove safepoint synchronization from ParallelScavengeHeap and SerialHeap

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

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

From kbarrett at openjdk.org  Sat Oct 11 04:52:01 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 11 Oct 2025 04:52:01 GMT
Subject: RFR: 8369611: Remove safepoint synchronization from
 ParallelScavengeHeap and SerialHeap
In-Reply-To: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
References: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
Message-ID: <L1ltV8Da-hiXSHYpToffLIoPoxOn02-4s3VdPJ7NOiQ=.bed61a11-b77d-4e53-a26e-c10c45346f20@github.com>

On Fri, 10 Oct 2025 22:38:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the discussion of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), @kimbarrett pointed out that StringDedup thread is now derived from JavaThread, but ParallelScavengeHeap and SerialHeap still have conditional STS synchronization at safepoint, which is not needed, as a result of removing the conditional STS synchronization, we could remove the remove safepoint synchronization from ParallelScavengeHeap and SerialHeap.
> 
> Test:
>   - [x] tier1

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27755#pullrequestreview-3326648080

From ayang at openjdk.org  Sat Oct 11 10:10:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 11 Oct 2025 10:10:00 GMT
Subject: RFR: 8369611: Remove safepoint synchronization from
 ParallelScavengeHeap and SerialHeap
In-Reply-To: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
References: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
Message-ID: <tHY2hNivmXikhBx4aRQnqnSGFlr2A9Zg68yCBWuP5Ik=.900eeba6-3a5d-487a-a19e-8bd6a7405a59@github.com>

On Fri, 10 Oct 2025 22:38:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the discussion of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), @kimbarrett pointed out that StringDedup thread is now derived from JavaThread, but ParallelScavengeHeap and SerialHeap still have conditional STS synchronization at safepoint, which is not needed, as a result of removing the conditional STS synchronization, we could remove the remove safepoint synchronization from ParallelScavengeHeap and SerialHeap.
> 
> Test:
>   - [x] tier1

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27755#pullrequestreview-3326948873

From shade at openjdk.org  Mon Oct 13 07:36:04 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 13 Oct 2025 07:36:04 GMT
Subject: RFR: 8369611: Remove safepoint synchronization from
 ParallelScavengeHeap and SerialHeap
In-Reply-To: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
References: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
Message-ID: <hD-xJflu8rPn9Qf0ajoY4ysj2_Q-YTZkxrOYA73ZUSM=.b19447e7-1720-456a-8d78-eb48bc6c6adc@github.com>

On Fri, 10 Oct 2025 22:38:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the discussion of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), @kimbarrett pointed out that StringDedup thread is now derived from JavaThread, but ParallelScavengeHeap and SerialHeap still have conditional STS synchronization at safepoint, which is not needed, as a result of removing the conditional STS synchronization, we could remove the remove safepoint synchronization from ParallelScavengeHeap and SerialHeap.
> 
> Test:
>   - [x] tier1

Makes sense, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27755#pullrequestreview-3330292497

From tschatzl at openjdk.org  Mon Oct 13 08:12:08 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 Oct 2025 08:12:08 GMT
Subject: RFR: 8369571: Parallel: Use ThreadsClaimTokenScope in PSAdjustTask
In-Reply-To: <jVdTn-ro42G0dvB6GuW7ZKQ89Lp5AGccowIro8zHvAo=.e55f17ec-c1c0-4cd1-abe2-8a1b6e044fe8@github.com>
References: <jVdTn-ro42G0dvB6GuW7ZKQ89Lp5AGccowIro8zHvAo=.e55f17ec-c1c0-4cd1-abe2-8a1b6e044fe8@github.com>
Message-ID: <sPuNSb5yfWWRgl7BCsumcOinK1Rgj1zJfMtOgOVVLOI=.baf63568-6a3e-4648-a5fb-58c847478b6e@github.com>

On Fri, 10 Oct 2025 14:39:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial lifting threads claim token logic into using the existing `ThreadsClaimTokenScope`.
> 
> Test: tier1

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27746#pullrequestreview-3330399973

From ayang at openjdk.org  Mon Oct 13 09:27:24 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 13 Oct 2025 09:27:24 GMT
Subject: RFR: 8369571: Parallel: Use ThreadsClaimTokenScope in PSAdjustTask
In-Reply-To: <jVdTn-ro42G0dvB6GuW7ZKQ89Lp5AGccowIro8zHvAo=.e55f17ec-c1c0-4cd1-abe2-8a1b6e044fe8@github.com>
References: <jVdTn-ro42G0dvB6GuW7ZKQ89Lp5AGccowIro8zHvAo=.e55f17ec-c1c0-4cd1-abe2-8a1b6e044fe8@github.com>
Message-ID: <9uS61Hbpg2p4byuAGZH4n6_5X4HsjPi--zT8uiZMMFE=.45c35af0-ddc2-44f3-a076-c9c9836713ce@github.com>

On Fri, 10 Oct 2025 14:39:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial lifting threads claim token logic into using the existing `ThreadsClaimTokenScope`.
> 
> Test: tier1

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27746#issuecomment-3396601279

From ayang at openjdk.org  Mon Oct 13 09:27:24 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 13 Oct 2025 09:27:24 GMT
Subject: Integrated: 8369571: Parallel: Use ThreadsClaimTokenScope in
 PSAdjustTask
In-Reply-To: <jVdTn-ro42G0dvB6GuW7ZKQ89Lp5AGccowIro8zHvAo=.e55f17ec-c1c0-4cd1-abe2-8a1b6e044fe8@github.com>
References: <jVdTn-ro42G0dvB6GuW7ZKQ89Lp5AGccowIro8zHvAo=.e55f17ec-c1c0-4cd1-abe2-8a1b6e044fe8@github.com>
Message-ID: <jRGEqHG4Y6zhQYrkWrnmktFlVwvZI76gXKtevrhOm08=.1efe32de-901e-4162-a9b0-40b4e35edb7e@github.com>

On Fri, 10 Oct 2025 14:39:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial lifting threads claim token logic into using the existing `ThreadsClaimTokenScope`.
> 
> Test: tier1

This pull request has now been integrated.

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

8369571: Parallel: Use ThreadsClaimTokenScope in PSAdjustTask

Reviewed-by: fandreuzzi, tschatzl

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

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

From ayang at openjdk.org  Mon Oct 13 09:37:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 13 Oct 2025 09:37:03 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v3]
In-Reply-To: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
Message-ID: <JqITJ_1rjkMp3QENj_5CqLR86J-L5Wj4tL28hDofyFE=.dd9c62ef-7b9a-415b-b387-7b8c9bca1499@github.com>

> Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc.
> 
> 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 three additional commits since the last revision:

 - Merge branch 'master' into sgc-expand-allocate
 - review
 - sgc-expand-allocate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27513/files
  - new: https://git.openjdk.org/jdk/pull/27513/files/57a88bd4..36d52e42

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

  Stats: 23459 lines in 811 files changed: 14449 ins; 4692 del; 4318 mod
  Patch: https://git.openjdk.org/jdk/pull/27513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27513/head:pull/27513

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

From tschatzl at openjdk.org  Mon Oct 13 10:52:01 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 Oct 2025 10:52:01 GMT
Subject: RFR: 8369611: Remove safepoint synchronization from
 ParallelScavengeHeap and SerialHeap
In-Reply-To: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
References: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
Message-ID: <USkR0iWS0yZH07t1dNctTE21X8IcLMyw0rCn6AD8Dag=.e99e8cbe-598f-4487-8b1e-e6b9c7077df1@github.com>

On Fri, 10 Oct 2025 22:38:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the discussion of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), @kimbarrett pointed out that StringDedup thread is now derived from JavaThread, but ParallelScavengeHeap and SerialHeap still have conditional STS synchronization at safepoint, which is not needed, as a result of removing the conditional STS synchronization, we could remove the remove safepoint synchronization from ParallelScavengeHeap and SerialHeap.
> 
> Test:
>   - [x] tier1

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27755#pullrequestreview-3330999015

From jsikstro at openjdk.org  Mon Oct 13 11:36:18 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 13 Oct 2025 11:36:18 GMT
Subject: RFR: 8369658: Client emulation mode set MaxRAM too late
Message-ID: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>

Hello,

While working on the proposal for the potential deprecation of MaxRAM (see [JDK-8369347](https://bugs.openjdk.org/browse/JDK-8369347)) I saw that `CompilerConfig::ergo_initialize()` sets the value for `MaxRAM` after ergonomic heap sizing is already done, which is the only place in the VM that cares about `MaxRAM`. I suggest we move setting the value of `MaxRAM` to `Arguments::set_heap_size()` to fix this.

Even though the `MaxRAM` flag might be deprecated, the code should still account for the fact that client emulation mode might lower the maximum amount of physical memory that can be used for the Java heap. If the flag is removed, we'd still want to lower the maximum memory, so it makes sense to have the code in `Arguments::set_heap_size()` in both cases.

Testing:
* Currently running Oracle's tier1-2
* Local test with `java -XX:+NeverActAsServerClassMachine -Xlog:gc+init` to see that the lower limit is reflected in ergonomic heap sizing.

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

Commit messages:
 - 8369658: Client emulation mode set MaxRAM too late

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

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

From ayang at openjdk.org  Mon Oct 13 12:48:29 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 13 Oct 2025 12:48:29 GMT
Subject: RFR: 8369681: Parallel: Remove conditional check in
 ParallelScavengeHeap::verify
Message-ID: <sD0Y26mh3gwh47yJYkYsoxRUTy1zlJCaHVJKVUIDB4I=.c8e1216b-d7a9-4e31-a807-fcbf8a3022c7@github.com>

Remove unnecessary `total_collections` checking before verification.

Test: tier1-5

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

Commit messages:
 - pgc-remove-if

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

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

From fandreuzzi at openjdk.org  Mon Oct 13 13:45:34 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 13 Oct 2025 13:45:34 GMT
Subject: RFR: 8369681: Parallel: Remove conditional check in
 ParallelScavengeHeap::verify
In-Reply-To: <sD0Y26mh3gwh47yJYkYsoxRUTy1zlJCaHVJKVUIDB4I=.c8e1216b-d7a9-4e31-a807-fcbf8a3022c7@github.com>
References: <sD0Y26mh3gwh47yJYkYsoxRUTy1zlJCaHVJKVUIDB4I=.c8e1216b-d7a9-4e31-a807-fcbf8a3022c7@github.com>
Message-ID: <tcOAZRGa9qADnNrvBSl0QIZownoTn75MRZGKbRXMCUw=.b4f855b7-f9a3-428c-8272-f5a64bab65d6@github.com>

On Mon, 13 Oct 2025 12:41:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Remove unnecessary `total_collections` checking before verification.
> 
> Test: tier1-5

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27769#pullrequestreview-3331699109

From tschatzl at openjdk.org  Mon Oct 13 14:54:14 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 Oct 2025 14:54:14 GMT
Subject: RFR: 8048180: G1: Eager reclaim of humongous objects with
 references [v9]
In-Reply-To: <biaw9oJpNRhpR1QXQbiAh3pP-WMZpoDWxUt8jCHepI0=.8fb8114b-edd4-4f05-bc9f-c06841f9386e@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
 <biaw9oJpNRhpR1QXQbiAh3pP-WMZpoDWxUt8jCHepI0=.8fb8114b-edd4-4f05-bc9f-c06841f9386e@github.com>
Message-ID: <MTedWxkEnfFJip6FGbf_w5ENpbvDAAB8U_0F7syZ2b0=.9386527b-1fb0-459c-b4fe-511b8acd7076@github.com>

On Fri, 10 Oct 2025 07:43:39 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
>> 
>> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
>> 
>> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
>> 
>> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
>> 
>> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>>  
>> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
>> 
>> Testing: new test cases, gha, tier1-5
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * some more documentation corrections

Reran tier1-5 without issues.

Thanks @albertnetymk @walulyai @benjaminp for your input!

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

PR Comment: https://git.openjdk.org/jdk/pull/27525#issuecomment-3397847000

From tschatzl at openjdk.org  Mon Oct 13 14:54:14 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 13 Oct 2025 14:54:14 GMT
Subject: Integrated: 8048180: G1: Eager reclaim of humongous objects with
 references
In-Reply-To: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
References: <ixC38GBhL2heOKhDOBVg6AlqZJ9hE8iuUGB48gB2lEo=.df1eadf2-2997-4b13-ae42-918d39041e35@github.com>
Message-ID: <6m6DP6KXXww6gMwT9WN5mYOq0NqiyWVxob0cjbfqmvE=.276f3ab6-6a68-4b58-8cf8-f2b4c9c6c99f@github.com>

On Fri, 26 Sep 2025 11:53:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to G1 that enables eager reclaim of humongous objects with references, either objArrays or just really large objects.
> 
> It works the same as other humongous object's eager reclaim, with the caveat that I disabled it during concurrent mark to avoid problems with SATB. There is fairly extensive documentation about why I think this works, and how in the comment in `g1YoungCollector.cpp`.
> 
> The test case exhaustively tests all combinations of when a particular type of object should be able to be reclaimed depending on when it is allocated (only for `typeArray` and `objArray` - huge objects work the same as the latter).
> 
> I added a diagnostic flag `G1EagerReclaimWithRefs` to allow disabling this particular functionality for diagnostic purposes, but I think it's not really necessary, and I'm open to remove it.
> 
> The following screenshot shows pause times before (purple) and after (brown) of one of the [Optaplanner](https://www.optaplanner.org/blog/2021/09/15/HowMuchFasterIsJava17.html) benchmarks as a result of this change.
>  
> <img width="702" height="485" alt="Screenshot 2025-09-26 at 13 59 05" src="https://github.com/user-attachments/assets/995e9e27-f861-44bd-8ced-3bd952e314e8" />
> 
> Testing: new test cases, gha, tier1-5
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: f292d7c6
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f292d7c66c6279f929eb37ffcc1857a269f72e3d
Stats:     412 lines in 10 files changed: 232 ins; 114 del; 66 mod

8048180: G1: Eager reclaim of humongous objects with references

Co-authored-by: Ivan Walulya <iwalulya at openjdk.org>
Reviewed-by: iwalulya, ayang

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

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

From xpeng at openjdk.org  Mon Oct 13 15:03:24 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 13 Oct 2025 15:03:24 GMT
Subject: RFR: 8369611: Remove safepoint synchronization from
 ParallelScavengeHeap and SerialHeap
In-Reply-To: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
References: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
Message-ID: <UyFrjceU7XmLEaAE5-fc6_w1etH0itltpAUrcYdMohA=.15c9df44-9919-4490-a81b-f06eda12e63f@github.com>

On Fri, 10 Oct 2025 22:38:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the discussion of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), @kimbarrett pointed out that StringDedup thread is now derived from JavaThread, but ParallelScavengeHeap and SerialHeap still have conditional STS synchronization at safepoint, which is not needed, as a result of removing the conditional STS synchronization, we could remove the remove safepoint synchronization from ParallelScavengeHeap and SerialHeap.
> 
> Test:
>   - [x] tier1

Thanks all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27755#issuecomment-3397885000

From xpeng at openjdk.org  Mon Oct 13 15:06:46 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 13 Oct 2025 15:06:46 GMT
Subject: Integrated: 8369611: Remove safepoint synchronization from
 ParallelScavengeHeap and SerialHeap
In-Reply-To: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
References: <enDkVNa9ZgaXprjkvF0FtGv0u6IdJHArFCARCRgLGBA=.d1b42fae-b867-44aa-8bd5-5d28bc6425d1@github.com>
Message-ID: <FCiMYEp9CJnDwQ5DIG1UOUW4XtPhHIHv69byKgUoPMk=.9c029655-982c-4308-b556-933421c99b0d@github.com>

On Fri, 10 Oct 2025 22:38:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> In the discussion of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), @kimbarrett pointed out that StringDedup thread is now derived from JavaThread, but ParallelScavengeHeap and SerialHeap still have conditional STS synchronization at safepoint, which is not needed, as a result of removing the conditional STS synchronization, we could remove the remove safepoint synchronization from ParallelScavengeHeap and SerialHeap.
> 
> Test:
>   - [x] tier1

This pull request has now been integrated.

Changeset: 551cd03b
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/551cd03b99feb34d98703b7d04571f92f83f2471
Stats:     29 lines in 4 files changed: 0 ins; 29 del; 0 mod

8369611: Remove safepoint synchronization from ParallelScavengeHeap and SerialHeap

Reviewed-by: kbarrett, ayang, shade, tschatzl

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

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

From kdnilsen at openjdk.org  Mon Oct 13 22:18:38 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 13 Oct 2025 22:18:38 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v12]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <2yyHGosCQCiu03jYG7lG82_2WrppAZqVQgDATo8bcfQ=.9c8bed3d-980f-499f-a467-a5cd1d90b6b8@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 with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates
 - remove _mixed_candidate_garbage_words from ShenandoahHeapRegion
 - reviewer feedback to reduce code duplication
 - Fix compilation errors after merge
 - Merge remote-tracking branch 'jdk/master' into fix-live-data-for-mixed-evac-candidates
 - Fix uninitialized variable
 - Remove deprecation conditional compiles
 - Adjust candidate live memory for each mixed evac
 - Refactor for better abstraction
 - Fix set_live() after full gc
 - ... and 35 more: https://git.openjdk.org/jdk/compare/92f2ab2e...24322e75

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

Changes: https://git.openjdk.org/jdk/pull/24319/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24319&range=11
  Stats: 110 lines in 11 files changed: 68 ins; 28 del; 14 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 aboldtch at openjdk.org  Tue Oct 14 06:53:03 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 14 Oct 2025 06:53:03 GMT
Subject: RFR: 8369658: Client emulation mode sets MaxRAM too late
In-Reply-To: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
References: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
Message-ID: <nwDCR9LkSkTNxEOWXqCDag4Ng7VSxtbYXY1wd9wb_8c=.c84396f9-89c8-478a-9e89-04f7d11b882e@github.com>

On Mon, 13 Oct 2025 11:25:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> While working on the proposal for the potential deprecation of MaxRAM (see [JDK-8369347](https://bugs.openjdk.org/browse/JDK-8369347)) I saw that `CompilerConfig::ergo_initialize()` sets the value for `MaxRAM` after ergonomic heap sizing is already done, which is the only place in the VM that cares about `MaxRAM`. I suggest we move setting the value of `MaxRAM` to `Arguments::set_heap_size()` to fix this.
> 
> Even though the `MaxRAM` flag might be deprecated, the code should still account for the fact that client emulation mode might lower the maximum amount of physical memory that can be used for the Java heap. If the flag is removed, we'd still want to lower the maximum memory, so it makes sense to have the code in `Arguments::set_heap_size()` in both cases.
> 
> Testing:
> * Currently running Oracle's tier1-2
> * Local test with `java -XX:+NeverActAsServerClassMachine -Xlog:gc+init` to see that the lower limit is reflected in ergonomic heap sizing.

Looks good, I see little risk with taking the patch as is. I had one suggestion for making `should_set_client_emulation_mode_flags` a bit more robust / less scary. 

Sidenote:
`NeverActAsServerClassMachine` in the java.md seems to suggest that `MaxRAM` is "The maximum amount of memory that the JVM may use". While its section on `MaxRAM` explicitly says it is only for the java heap.

Sidenote2:
`NeverActAsServerClassMachine` and `AlwaysActAsServerClassMachine` seem very scewed. First that we allow them to be contradictory, `NeverActAsServerClassMachine` outweighs `AlwaysActAsServerClassMachine`, and we only care about `AlwaysActAsServerClassMachine` for the GC selection, but not the compiler. I wonder if the compiler also should have used `is_server_class_machine`. But regardless, the best thing is probably just to not change behaviour and hopefully be able to remove the flags in the future. At least consolidate them into one flag. Especially after JEP-523.

src/hotspot/share/compiler/compilerDefinitions.cpp line 562:

> 560:       }
> 561:     } else if (!has_c2() && !is_jvmci_compiler()) {
> 562:       return true;

Pre-existing: 
Just a note that this `!has_c2` seems so strange, as we set the values that are set inside `set_client_emulation_mode_flags();` to other defaults than those in `c1_globals_<arch>.hpp`. So we override those defaults here always. Some defaults seem to be the same but some are different. Which seems very strange.  `CICompilerCount` is the only flag which is not from that file but its default is also correctly 1 if c2 has been built out.

src/hotspot/share/compiler/compilerDefinitions.cpp line 576:

> 574:   if (should_set_client_emulation_mode_flags()) {
> 575:     set_client_emulation_mode_flags();
> 576:   }

Should there be a comment here which mentions that this decision has already been taken (and acted on) in `GCArguments::set_heap_size`?

 Someone that is not aware might start ergonomically changing flags between the first and second call to `should_set_client_emulation_mode_flags` which changes its decision. 

Alternatively `should_set_client_emulation_mode_flags` could be implemented as a set once property.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27765#pullrequestreview-3334091882
PR Review Comment: https://git.openjdk.org/jdk/pull/27765#discussion_r2428057465
PR Review Comment: https://git.openjdk.org/jdk/pull/27765#discussion_r2428065386

From tschatzl at openjdk.org  Tue Oct 14 07:06:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 07:06:35 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet
Message-ID: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>

Hi all,

  please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.

Testing: local compilation, gha

Thanks,
  Thomas

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

Commit messages:
 - 8369793

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

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

From stefank at openjdk.org  Tue Oct 14 07:15:16 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 14 Oct 2025 07:15:16 GMT
Subject: RFR: 8369658: Client emulation mode sets MaxRAM too late
In-Reply-To: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
References: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
Message-ID: <9lJi9yul_WYS6_JXQyazgkc9r2JGIdcJr2Y7iOR285I=.68d93617-1917-4e80-a642-b0dd19d27348@github.com>

On Mon, 13 Oct 2025 11:25:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> While working on the proposal for the potential deprecation of MaxRAM (see [JDK-8369347](https://bugs.openjdk.org/browse/JDK-8369347)) I saw that `CompilerConfig::ergo_initialize()` sets the value for `MaxRAM` after ergonomic heap sizing is already done, which is the only place in the VM that cares about `MaxRAM`. I suggest we move setting the value of `MaxRAM` to `Arguments::set_heap_size()` to fix this.
> 
> Even though the `MaxRAM` flag might be deprecated, the code should still account for the fact that client emulation mode might lower the maximum amount of physical memory that can be used for the Java heap. If the flag is removed, we'd still want to lower the maximum memory, so it makes sense to have the code in `Arguments::set_heap_size()` in both cases.
> 
> Testing:
> * Currently running Oracle's tier1-2
> * Local test with `java -XX:+NeverActAsServerClassMachine -Xlog:gc+init` to see that the lower limit is reflected in ergonomic heap sizing.

> Especially after JEP-523.

The `NeverActAsServerClassMachine` and `AlwaysActAsServerClassMachine` flags don't seem to be well-known and frequently used flags. If we are moving towards JEP-523 (Make G1 the Default Garbage Collector in All Environments), should we also take the opportunity to get rid of these flags to lower the maintenance cost / risk of having these flags?

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

PR Review: https://git.openjdk.org/jdk/pull/27765#pullrequestreview-3334197621

From tschatzl at openjdk.org  Tue Oct 14 07:21:47 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 07:21:47 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v2]
In-Reply-To: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
Message-ID: <EMJjeJWrwBb5dYRnR7AnPAi1dU7gZ-2iNh8LgQhKis4=.38a22503-46af-4b33-8f8c-a20bb49b706c@github.com>

> Hi all,
> 
>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

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

  * also remove gtest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27786/files
  - new: https://git.openjdk.org/jdk/pull/27786/files/0850d7d9..537b137b

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

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

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

From stefank at openjdk.org  Tue Oct 14 07:21:47 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 14 Oct 2025 07:21:47 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v2]
In-Reply-To: <EMJjeJWrwBb5dYRnR7AnPAi1dU7gZ-2iNh8LgQhKis4=.38a22503-46af-4b33-8f8c-a20bb49b706c@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <EMJjeJWrwBb5dYRnR7AnPAi1dU7gZ-2iNh8LgQhKis4=.38a22503-46af-4b33-8f8c-a20bb49b706c@github.com>
Message-ID: <qqKan8C8lNXa-PbFNPbJdcHHSh-RR8Xkc-rf958Ca7A=.79383d9b-aae6-4c4a-a371-7c91b4d86cc3@github.com>

On Tue, 14 Oct 2025 07:18:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * also remove gtest

Do you also need to remove test_g1FreeIdSet.cpp?

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

PR Review: https://git.openjdk.org/jdk/pull/27786#pullrequestreview-3334204865

From stefank at openjdk.org  Tue Oct 14 07:30:05 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 14 Oct 2025 07:30:05 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v2]
In-Reply-To: <EMJjeJWrwBb5dYRnR7AnPAi1dU7gZ-2iNh8LgQhKis4=.38a22503-46af-4b33-8f8c-a20bb49b706c@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <EMJjeJWrwBb5dYRnR7AnPAi1dU7gZ-2iNh8LgQhKis4=.38a22503-46af-4b33-8f8c-a20bb49b706c@github.com>
Message-ID: <hSaWi3Suw1fvhTk_oVeYAwuKNx6GrNXLCGAmMlDYhxw=.0b7aeff2-d347-423b-8794-24287a02822a@github.com>

On Tue, 14 Oct 2025 07:21:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * also remove gtest

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27786#pullrequestreview-3334246049

From sjohanss at openjdk.org  Tue Oct 14 07:30:05 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 14 Oct 2025 07:30:05 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v2]
In-Reply-To: <EMJjeJWrwBb5dYRnR7AnPAi1dU7gZ-2iNh8LgQhKis4=.38a22503-46af-4b33-8f8c-a20bb49b706c@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <EMJjeJWrwBb5dYRnR7AnPAi1dU7gZ-2iNh8LgQhKis4=.38a22503-46af-4b33-8f8c-a20bb49b706c@github.com>
Message-ID: <me-5Ldwi5DWyM2O5FYanOc5uOAB5ivNbggcJSeyOjFo=.b4b222cd-3bf4-4d10-b0c2-d6349baf3c95@github.com>

On Tue, 14 Oct 2025 07:21:47 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * also remove gtest

I guess this should be removed as well:
https://github.com/tschatzl/jdk/blob/537b137be9dc7e1e22492198f56485b9c0772e63/make/hotspot/lib/CompileJvm.gmk#L192

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

PR Comment: https://git.openjdk.org/jdk/pull/27786#issuecomment-3400466506

From tschatzl at openjdk.org  Tue Oct 14 07:40:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 07:40:38 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
Message-ID: <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>

> Hi all,
> 
>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

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

  * remove more g1freeidset.cpp references from makefiles

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27786/files
  - new: https://git.openjdk.org/jdk/pull/27786/files/537b137b..f08118b3

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

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

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

From sjohanss at openjdk.org  Tue Oct 14 07:40:39 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Tue, 14 Oct 2025 07:40:39 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
Message-ID: <nWfIJ3Y2tHXWSFuvlZtbITEY777oeYkkh4DHMQWKIoE=.ff97a8fd-e26b-4047-a819-ebfdf2ffb498@github.com>

On Tue, 14 Oct 2025 07:37:45 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove more g1freeidset.cpp references from makefiles

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27786#pullrequestreview-3334277538

From gli at openjdk.org  Tue Oct 14 07:43:03 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Oct 2025 07:43:03 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v2]
In-Reply-To: <ol_mN5Xe414wLUpeXbQa-tnammW9EKqaMctwN8lbMhE=.df924866-7089-4e71-87bd-631ee196b618@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
 <XdIf5AMddR6zeFngh7Oqv9hXV1j92utMQobDI5M8Nk4=.d43b2e34-b130-4b2b-9304-2d5d45259ff0@github.com>
 <S3P97wLioToITsQQVwwcqZFJiHs2AO1cGocZV1jtSoY=.8000b283-0848-43a9-ab63-20b01d84544a@github.com>
 <ol_mN5Xe414wLUpeXbQa-tnammW9EKqaMctwN8lbMhE=.df924866-7089-4e71-87bd-631ee196b618@github.com>
Message-ID: <PvGtj4ORS26nj66voxUBeFlBK-j7kaphM6fROUm1qKE=.dd381773-ebcd-4656-a426-d7824dce7a98@github.com>

On Mon, 29 Sep 2025 07:34:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/defNewGeneration.cpp line 478:
>> 
>>> 476: 
>>> 477:   // Keep from/to and expand eden.
>>> 478:   expand_eden_by(_virtual_space.uncommitted_size());
>> 
>> Just expanding eden space may go against the option `SurvivorRatio`.
>
> Indeed; this happens when young-gen is still not empty after full-gc -- this is kind of an extreme scenario. Given there can be live objs inside survivor/eden, the only safe way to expand is to expand eden, as it's the final space in the new layout.
> 
> Consequently, `DefNewGeneration::max_capacity` is updated to ensure `capacity <= max_capacity`.

> It seems not obey the eden/survivor ratio rule.

What about adding a comment (may be tagged as `TODO` or `FIXME`) in the code or filing an issue to state the potential problem?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2428205793

From jsikstro at openjdk.org  Tue Oct 14 08:28:04 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 14 Oct 2025 08:28:04 GMT
Subject: RFR: 8369658: Client emulation mode sets MaxRAM too late [v2]
In-Reply-To: <nwDCR9LkSkTNxEOWXqCDag4Ng7VSxtbYXY1wd9wb_8c=.c84396f9-89c8-478a-9e89-04f7d11b882e@github.com>
References: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
 <nwDCR9LkSkTNxEOWXqCDag4Ng7VSxtbYXY1wd9wb_8c=.c84396f9-89c8-478a-9e89-04f7d11b882e@github.com>
Message-ID: <ST8P8ONt4wECsnMAp8ray9WCYeU7nN7UPFwe5IJwgJs=.5615277d-e0d1-489e-9fba-79e9d87a5c70@github.com>

On Tue, 14 Oct 2025 06:49:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment
>
> Looks good, I see little risk with taking the patch as is. I had one suggestion for making `should_set_client_emulation_mode_flags` a bit more robust / less scary. 
> 
> Sidenote:
> `NeverActAsServerClassMachine` in the java.md seems to suggest that `MaxRAM` is "The maximum amount of memory that the JVM may use". While its section on `MaxRAM` explicitly says it is only for the java heap.
> 
> Sidenote2:
> `NeverActAsServerClassMachine` and `AlwaysActAsServerClassMachine` seem very scewed. First that we allow them to be contradictory, `NeverActAsServerClassMachine` outweighs `AlwaysActAsServerClassMachine`, and we only care about `AlwaysActAsServerClassMachine` for the GC selection, but not the compiler. I wonder if the compiler also should have used `is_server_class_machine`. But regardless, the best thing is probably just to not change behaviour and hopefully be able to remove the flags in the future. At least consolidate them into one flag. Especially after JEP-523.

Thank you for looking at this @xmas92 and @stefank. I agree that it sounds like a good plan to make an effort to get rid of `Never/AlwaysActAsServerClassMachine`.

With this change we are able to more smoothly move forward with deprecating `MaxRAM` and `Never/AlwaysActAsServerClassMachine` separately, which I feel is a step in the right direction.

> src/hotspot/share/compiler/compilerDefinitions.cpp line 576:
> 
>> 574:   if (should_set_client_emulation_mode_flags()) {
>> 575:     set_client_emulation_mode_flags();
>> 576:   }
> 
> Should there be a comment here which mentions that this decision has already been taken (and acted on) in `GCArguments::set_heap_size`?
> 
>  Someone that is not aware might start ergonomically changing flags between the first and second call to `should_set_client_emulation_mode_flags` which changes its decision. 
> 
> Alternatively `should_set_client_emulation_mode_flags` could be implemented as a set once property.

I've added a comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/27765#issuecomment-3400680663
PR Review Comment: https://git.openjdk.org/jdk/pull/27765#discussion_r2428330915

From jsikstro at openjdk.org  Tue Oct 14 08:28:02 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 14 Oct 2025 08:28:02 GMT
Subject: RFR: 8369658: Client emulation mode sets MaxRAM too late [v2]
In-Reply-To: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
References: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
Message-ID: <tZ345kDmHX2HQTkvDjfQnnh-wRd3KEJ7cdH6tnKRKXU=.4e8157ca-0964-45f8-b6ab-ec0ac7e2216d@github.com>

> Hello,
> 
> While working on the proposal for the potential deprecation of MaxRAM (see [JDK-8369347](https://bugs.openjdk.org/browse/JDK-8369347)) I saw that `CompilerConfig::ergo_initialize()` sets the value for `MaxRAM` after ergonomic heap sizing is already done, which is the only place in the VM that cares about `MaxRAM`. I suggest we move setting the value of `MaxRAM` to `Arguments::set_heap_size()` to fix this.
> 
> Even though the `MaxRAM` flag might be deprecated, the code should still account for the fact that client emulation mode might lower the maximum amount of physical memory that can be used for the Java heap. If the flag is removed, we'd still want to lower the maximum memory, so it makes sense to have the code in `Arguments::set_heap_size()` in both cases.
> 
> Testing:
> * Currently running Oracle's tier1-2
> * Local test with `java -XX:+NeverActAsServerClassMachine -Xlog:gc+init` to see that the lower limit is reflected in ergonomic heap sizing.

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

  Add comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27765/files
  - new: https://git.openjdk.org/jdk/pull/27765/files/33d4f066..d812f850

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

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

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

From ayang at openjdk.org  Tue Oct 14 08:36:27 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 08:36:27 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v2]
In-Reply-To: <PvGtj4ORS26nj66voxUBeFlBK-j7kaphM6fROUm1qKE=.dd381773-ebcd-4656-a426-d7824dce7a98@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
 <XdIf5AMddR6zeFngh7Oqv9hXV1j92utMQobDI5M8Nk4=.d43b2e34-b130-4b2b-9304-2d5d45259ff0@github.com>
 <S3P97wLioToITsQQVwwcqZFJiHs2AO1cGocZV1jtSoY=.8000b283-0848-43a9-ab63-20b01d84544a@github.com>
 <ol_mN5Xe414wLUpeXbQa-tnammW9EKqaMctwN8lbMhE=.df924866-7089-4e71-87bd-631ee196b618@github.com>
 <PvGtj4ORS26nj66voxUBeFlBK-j7kaphM6fROUm1qKE=.dd381773-ebcd-4656-a426-d7824dce7a98@github.com>
Message-ID: <MaTsgk8OSjHxXMVLDgRm_F4BxAhneeHukc0_zbW7EkQ=.fc414bef-bcf1-4d08-9e2d-c958cffd6b6e@github.com>

On Tue, 14 Oct 2025 07:40:07 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Indeed; this happens when young-gen is still not empty after full-gc -- this is kind of an extreme scenario. Given there can be live objs inside survivor/eden, the only safe way to expand is to expand eden, as it's the final space in the new layout.
>> 
>> Consequently, `DefNewGeneration::max_capacity` is updated to ensure `capacity <= max_capacity`.
>
>> It seems not obey the eden/survivor ratio rule.
> 
> What about adding a comment (may be tagged as `TODO` or `FIXME`) in the code or filing an issue to state the potential problem?

End users can notice a change-of-behavior, so maybe we can have a release-note stating `SurvivorRatio` might not hold in the heap-almost-full situation. WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2428357357

From kbarrett at openjdk.org  Tue Oct 14 08:40:18 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 14 Oct 2025 08:40:18 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
Message-ID: <yFkSezw4eYYuPzuFF6b7S7ulsIn0zPcIrPSGvhz_09w=.2745e0eb-a2e0-49a0-9abf-d56190434d8e@github.com>

On Tue, 14 Oct 2025 07:40:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove more g1freeidset.cpp references from makefiles

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27786#pullrequestreview-3334513091

From gli at openjdk.org  Tue Oct 14 08:50:06 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 14 Oct 2025 08:50:06 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v2]
In-Reply-To: <MaTsgk8OSjHxXMVLDgRm_F4BxAhneeHukc0_zbW7EkQ=.fc414bef-bcf1-4d08-9e2d-c958cffd6b6e@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
 <XdIf5AMddR6zeFngh7Oqv9hXV1j92utMQobDI5M8Nk4=.d43b2e34-b130-4b2b-9304-2d5d45259ff0@github.com>
 <S3P97wLioToITsQQVwwcqZFJiHs2AO1cGocZV1jtSoY=.8000b283-0848-43a9-ab63-20b01d84544a@github.com>
 <ol_mN5Xe414wLUpeXbQa-tnammW9EKqaMctwN8lbMhE=.df924866-7089-4e71-87bd-631ee196b618@github.com>
 <PvGtj4ORS26nj66voxUBeFlBK-j7kaphM6fROUm1qKE=.dd381773-ebcd-4656-a426-d7824dce7a98@github.com>
 <MaTsgk8OSjHxXMVLDgRm_F4BxAhneeHukc0_zbW7EkQ=.fc414bef-bcf1-4d08-9e2d-c958cffd6b6e@github.com>
Message-ID: <350xCglp1ye1aEUaPZcJiNPyaoJwFRRdPA-K4e0ZkJk=.c41b02cf-b056-4d43-b4f4-302d8ea3fcc2@github.com>

On Tue, 14 Oct 2025 08:33:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> End users can notice a change-of-behavior, so maybe we can have a release-note stating SurvivorRatio might not hold in the heap-almost-full situation.

So good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2428394853

From ayang at openjdk.org  Tue Oct 14 09:02:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 09:02:55 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v2]
In-Reply-To: <350xCglp1ye1aEUaPZcJiNPyaoJwFRRdPA-K4e0ZkJk=.c41b02cf-b056-4d43-b4f4-302d8ea3fcc2@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
 <XdIf5AMddR6zeFngh7Oqv9hXV1j92utMQobDI5M8Nk4=.d43b2e34-b130-4b2b-9304-2d5d45259ff0@github.com>
 <S3P97wLioToITsQQVwwcqZFJiHs2AO1cGocZV1jtSoY=.8000b283-0848-43a9-ab63-20b01d84544a@github.com>
 <ol_mN5Xe414wLUpeXbQa-tnammW9EKqaMctwN8lbMhE=.df924866-7089-4e71-87bd-631ee196b618@github.com>
 <PvGtj4ORS26nj66voxUBeFlBK-j7kaphM6fROUm1qKE=.dd381773-ebcd-4656-a426-d7824dce7a98@github.com>
 <MaTsgk8OSjHxXMVLDgRm_F4BxAhneeHukc0_zbW7EkQ=.fc414bef-bcf1-4d08-9e2d-c958cffd6b6e@github.com>
 <350xCglp1ye1aEUaPZcJiNPyaoJwFRRdPA-K4e0ZkJk=.c41b02cf-b056-4d43-b4f4-302d8ea3fcc2@github.com>
Message-ID: <KRqMa9t9t2wxNau_BTf9_Rr-iPGevfTeHxJWmoNbpXk=.ac808c41-4c5e-486c-b719-6d9132b30168@github.com>

On Tue, 14 Oct 2025 08:47:33 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> End users can notice a change-of-behavior, so maybe we can have a release-note stating `SurvivorRatio` might not hold in the heap-almost-full situation. WDYT?
>
>> End users can notice a change-of-behavior, so maybe we can have a release-note stating SurvivorRatio might not hold in the heap-almost-full situation.
> 
> So good.

Release note: https://bugs.openjdk.org/browse/JDK-8369810

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27513#discussion_r2428430723

From aboldtch at openjdk.org  Tue Oct 14 09:09:56 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 14 Oct 2025 09:09:56 GMT
Subject: RFR: 8369658: Client emulation mode sets MaxRAM too late [v2]
In-Reply-To: <tZ345kDmHX2HQTkvDjfQnnh-wRd3KEJ7cdH6tnKRKXU=.4e8157ca-0964-45f8-b6ab-ec0ac7e2216d@github.com>
References: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
 <tZ345kDmHX2HQTkvDjfQnnh-wRd3KEJ7cdH6tnKRKXU=.4e8157ca-0964-45f8-b6ab-ec0ac7e2216d@github.com>
Message-ID: <MBCqBosLJPcwXU9NLXoK7zX8valcyW5X5yyEa5mXjVM=.47d729de-e9b2-4ba5-b955-0e2d286e2ece@github.com>

On Tue, 14 Oct 2025 08:28:02 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> While working on the proposal for the potential deprecation of MaxRAM (see [JDK-8369347](https://bugs.openjdk.org/browse/JDK-8369347)) I saw that `CompilerConfig::ergo_initialize()` sets the value for `MaxRAM` after ergonomic heap sizing is already done, which is the only place in the VM that cares about `MaxRAM`. I suggest we move setting the value of `MaxRAM` to `Arguments::set_heap_size()` to fix this.
>> 
>> Even though the `MaxRAM` flag might be deprecated, the code should still account for the fact that client emulation mode might lower the maximum amount of physical memory that can be used for the Java heap. If the flag is removed, we'd still want to lower the maximum memory, so it makes sense to have the code in `Arguments::set_heap_size()` in both cases.
>> 
>> Testing:
>> * Currently running Oracle's tier1-2
>> * Local test with `java -XX:+NeverActAsServerClassMachine -Xlog:gc+init` to see that the lower limit is reflected in ergonomic heap sizing.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27765#pullrequestreview-3334624012

From tschatzl at openjdk.org  Tue Oct 14 10:36:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 10:36:39 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <VkLENN70uwegelyOrE2wdSsQK_8FQ2RL4XyWfmXNjzo=.f0ff07e7-7638-4ad5-9533-f3807b901696@github.com>

On Tue, 14 Oct 2025 09:46:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

I think this PR should also clean up all the deferred card mark code, i.e. everything related to `DeferInitialCardMark` flag.
Since it is `false` by default, `CardTableBarrierSet::_defer_initial_card_mark` is also always `false` now.

There does not seem to be a reason to keep it and surrounding code just for the sake of the flag. This flag is also diagnostic, and can be removed too.

Great find btw!

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

PR Comment: https://git.openjdk.org/jdk/pull/27794#issuecomment-3401156972
PR Comment: https://git.openjdk.org/jdk/pull/27794#issuecomment-3401162268

From tschatzl at openjdk.org  Tue Oct 14 10:40:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 10:40:53 GMT
Subject: RFR: 8369809: G1: Merge
 G1CollectedHeap::do_collection_pause_at_safepoint[_helper]
Message-ID: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>

Hi all,

  please review this trivial fix to merge `G1CollectedHeap::do_collection_pause_helper` with `do_collection_pause`. The helper method is only called there in this single place and does not add anything but two asserts.

Testing: gha, local compilation

Thanks,
  Thomas

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

Commit messages:
 - 8369809

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

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

From ayang at openjdk.org  Tue Oct 14 10:53:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 10:53:19 GMT
Subject: RFR: 8369809: G1: Merge
 G1CollectedHeap::do_collection_pause_at_safepoint[_helper]
In-Reply-To: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
References: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
Message-ID: <5rYGODsvQcbBCw-7nQ9FFyIPVYuRieMDONCpM7Zb7zw=.c9503f24-60da-4c2a-b709-da27ef643b6d@github.com>

On Tue, 14 Oct 2025 08:59:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial fix to merge `G1CollectedHeap::do_collection_pause_helper` with `do_collection_pause`. The helper method is only called there in this single place and does not add anything but two asserts.
> 
> Testing: gha, local compilation
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

> 2628: void G1CollectedHeap::do_collection_pause_at_safepoint(size_t allocation_word_size) {
> 2629:   assert_at_safepoint_on_vm_thread();
> 2630:   guarantee(!is_stw_gc_active(), "collection is not reentrant");

This can probably be an `assert` instead.

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

PR Review: https://git.openjdk.org/jdk/pull/27790#pullrequestreview-3334984069
PR Review Comment: https://git.openjdk.org/jdk/pull/27790#discussion_r2428719787

From tschatzl at openjdk.org  Tue Oct 14 11:00:04 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 11:00:04 GMT
Subject: RFR: 8369809: G1: Merge
 G1CollectedHeap::do_collection_pause_at_safepoint[_helper] [v2]
In-Reply-To: <roxwp6wqABEsvU1ahrnUklULXcJGr1t-1mmNZipSlcM=.55bfa116-7d44-4ff4-a8bb-7eb05f5b2510@github.com>
References: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
 <roxwp6wqABEsvU1ahrnUklULXcJGr1t-1mmNZipSlcM=.55bfa116-7d44-4ff4-a8bb-7eb05f5b2510@github.com>
Message-ID: <6Kw6haHS3ooRcfKYGfwR6xAhvxMPHMXywGHCsTtpaqc=.afd5dde0-4f4d-4fcc-9c41-68200bdb1e5b@github.com>

On Tue, 14 Oct 2025 10:56:58 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial fix to merge `G1CollectedHeap::do_collection_pause_helper` with `do_collection_pause`. The helper method is only called there in this single place and does not add anything but two asserts.
>> 
>> Testing: gha, local compilation
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>   
>   * ayang review

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

> 2628: void G1CollectedHeap::do_collection_pause_at_safepoint(size_t allocation_word_size) {
> 2629:   assert_at_safepoint_on_vm_thread();
> 2630:   guarantee(!is_stw_gc_active(), "collection is not reentrant");

Suggestion:

  assert(!is_stw_gc_active(), "collection is not reentrant");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27790#discussion_r2428730025

From tschatzl at openjdk.org  Tue Oct 14 11:00:01 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 11:00:01 GMT
Subject: RFR: 8369809: G1: Merge
 G1CollectedHeap::do_collection_pause_at_safepoint[_helper] [v2]
In-Reply-To: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
References: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
Message-ID: <roxwp6wqABEsvU1ahrnUklULXcJGr1t-1mmNZipSlcM=.55bfa116-7d44-4ff4-a8bb-7eb05f5b2510@github.com>

> Hi all,
> 
>   please review this trivial fix to merge `G1CollectedHeap::do_collection_pause_helper` with `do_collection_pause`. The helper method is only called there in this single place and does not add anything but two asserts.
> 
> Testing: gha, local compilation
> 
> Thanks,
>   Thomas

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

  Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
  
  * ayang review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27790/files
  - new: https://git.openjdk.org/jdk/pull/27790/files/65172ae5..85739069

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

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

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

From ayang at openjdk.org  Tue Oct 14 11:04:31 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 11:04:31 GMT
Subject: RFR: 8369809: G1: Merge
 G1CollectedHeap::do_collection_pause_at_safepoint[_helper] [v2]
In-Reply-To: <roxwp6wqABEsvU1ahrnUklULXcJGr1t-1mmNZipSlcM=.55bfa116-7d44-4ff4-a8bb-7eb05f5b2510@github.com>
References: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
 <roxwp6wqABEsvU1ahrnUklULXcJGr1t-1mmNZipSlcM=.55bfa116-7d44-4ff4-a8bb-7eb05f5b2510@github.com>
Message-ID: <6JXkyBapJG11njyWV-SKLy7YqFzJqKRDyhA-Jgcit3M=.bf3eaeea-f224-4ee4-b624-ac325e682bfa@github.com>

On Tue, 14 Oct 2025 11:00:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial fix to merge `G1CollectedHeap::do_collection_pause_helper` with `do_collection_pause`. The helper method is only called there in this single place and does not add anything but two asserts.
>> 
>> Testing: gha, local compilation
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>   
>   * ayang review

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27790#pullrequestreview-3335025613

From ayang at openjdk.org  Tue Oct 14 11:27:20 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 11:27:20 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v2]
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <RrXbAnMZMBuMxPb8W_C4KOnx67Lpj6KNjQxx8cSV7R8=.826f5314-8cf4-4c49-83d1-f3f92cd56e6e@github.com>

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27794/files
  - new: https://git.openjdk.org/jdk/pull/27794/files/e424e898..1eed131b

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

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

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

From iwalulya at openjdk.org  Tue Oct 14 11:41:15 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 14 Oct 2025 11:41:15 GMT
Subject: RFR: 8369809: G1: Merge
 G1CollectedHeap::do_collection_pause_at_safepoint[_helper] [v2]
In-Reply-To: <roxwp6wqABEsvU1ahrnUklULXcJGr1t-1mmNZipSlcM=.55bfa116-7d44-4ff4-a8bb-7eb05f5b2510@github.com>
References: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
 <roxwp6wqABEsvU1ahrnUklULXcJGr1t-1mmNZipSlcM=.55bfa116-7d44-4ff4-a8bb-7eb05f5b2510@github.com>
Message-ID: <kKlzPl4OZ0ZESR2-2tsF5TEuyRFUhq5kVTOiX6GZKf8=.f3fabfc4-7137-4ba2-b8b5-5e60440b6aff@github.com>

On Tue, 14 Oct 2025 11:00:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial fix to merge `G1CollectedHeap::do_collection_pause_helper` with `do_collection_pause`. The helper method is only called there in this single place and does not add anything but two asserts.
>> 
>> Testing: gha, local compilation
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>   
>   * ayang review

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27790#pullrequestreview-3335145182

From aboldtch at openjdk.org  Tue Oct 14 11:44:07 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 14 Oct 2025 11:44:07 GMT
Subject: RFR: 8369811: ZGC: Robust NUMA configuration detection
In-Reply-To: <pH6e0bshfOmdZULA7ptGBLeCKtW7NxDmc1zEuS8_jqo=.be5a1b6f-2d7c-4c08-a900-67f9c8442bb8@github.com>
References: <pH6e0bshfOmdZULA7ptGBLeCKtW7NxDmc1zEuS8_jqo=.be5a1b6f-2d7c-4c08-a900-67f9c8442bb8@github.com>
Message-ID: <ZKYtk3GKPrM25-m5sgXxwgP-rHDqXGYaAmcDeIMPv4g=.d6da946e-9306-4aca-a808-391b8a877ae9@github.com>

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

> Hello,
> 
> When page allocation was overhauled in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), NUMA support in ZGC was also significantly overhauled. The concept of a partition was introduced as a one-to-one mapping between NUMA nodes and a subset of the Java heap. The number of partitions is ideally the same number of NUMA nodes the Java process is bound to use.
> 
> Using ZGC and binding the Java process to only use a subset of the available NUMA nodes on a system with more than 2 NUMA nodes, there will be a mismatch between the internal representation and the configured one. The internal representation ends up having as many partitions as there are NUMA nodes on the system, not how many NUMA nodes the Java process will actually use.
> 
> To solve this, we create a mapping between what we refer to as "NUMA id" and "NUMA node", where NUMA id is the internal representation, i.e., the id of a partition, and the NUMA node is the actual NUMA node memory is allocated on. The mapping is used to translate between the two when syscalls are made, so that the internal representation always works with NUMA ids and syscalls work with the actual, or desired, NUMA node.
> 
> Before:
> 
> $ numactl --cpunodebind=0,2 --membind=0,2 ./jdk-25/bin/java -Xms200M -Xmx200M -XX:+AlwaysPretouch -XX:+UseZGC -Xlog:gc+init Forever.java
> [0.236s][info][gc,init] NUMA Support: Enabled
> [0.237s][info][gc,init] NUMA Nodes: 4
> 
> $ cat /proc/$(pidof java)/numa_maps | grep java_heap
> 40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N0=12800 kernelpagesize_kB=4
> 401f1000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N1=12800 kernelpagesize_kB=4
> 403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N2=12800 kernelpagesize_kB=4
> 405d3000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N3=12800 kernelpagesize_kB=4
> 
> 
> After:
> 
> $ numactl --cpunodebind=0,2 --membind=0,2 ./jdk/bin/java -Xms200M -Xmx200M -XX:+AlwaysPreTouch -XX:+UseZGC -Xlog:gc+init Forever.java
> [0.236s][info][gc,init] NUMA Support: Enabled
> [0.237s][info][gc,init] NUMA Nodes: 2
> 
> $ cat /proc/$(pidof java)/numa_maps | grep java_heap
> 40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N0=25600 kernelpagesize_kB=4
> 403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N2=25600 kernelpagesize_kB=4
> 
> 
> Testing:
> * Functional testing on a QEMU VM with 4 NUMA nodes
> * Oracle's tier1-2 on a NUMA system with 2 NUMA nodes ...

lgtm. 

Unfortunate that `numa_get_leaf_groups` has the signature it does requiring this `int -> uint -> int` type juggling. 

Maybe we can improve that in the future. And even create a more explicit type system in our os numa layer so we are less likely to introduce similar bugs in the future.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27792#pullrequestreview-3335152745

From tschatzl at openjdk.org  Tue Oct 14 11:48:05 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 11:48:05 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v2]
In-Reply-To: <RrXbAnMZMBuMxPb8W_C4KOnx67Lpj6KNjQxx8cSV7R8=.826f5314-8cf4-4c49-83d1-f3f92cd56e6e@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <RrXbAnMZMBuMxPb8W_C4KOnx67Lpj6KNjQxx8cSV7R8=.826f5314-8cf4-4c49-83d1-f3f92cd56e6e@github.com>
Message-ID: <sjt4lEwhm0PUX40IzkFSjdvV-s164MKq7C_Ks8iRBwM=.7dbf00e2-3a7c-4620-b55e-7222518d3e65@github.com>

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

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/shared/cardTableBarrierSet.cpp line 116:

> 114:   }
> 115:   if (new_obj->is_typeArray() || _card_table->is_in_young(new_obj)) {
> 116:     // Arrays of non-references don't need a post-barrier.

Pre-existing: Maybe `CardTable::is_in_young()` can be made `protected` instead of `public`.

src/hotspot/share/gc/shared/cardTableBarrierSet.cpp line 117:

> 115:   if (new_obj->is_typeArray() || _card_table->is_in_young(new_obj)) {
> 116:     // Arrays of non-references don't need a post-barrier.
> 117:     // The deferred_card_mark region should be empty

The `Thread::_deferred_card_mark` member and related can also be removed, because nobody writes to it afaict.

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

PR Review: https://git.openjdk.org/jdk/pull/27794#pullrequestreview-3335148410
PR Review Comment: https://git.openjdk.org/jdk/pull/27794#discussion_r2428845167
PR Review Comment: https://git.openjdk.org/jdk/pull/27794#discussion_r2428847124

From ayang at openjdk.org  Tue Oct 14 12:01:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 12:01:28 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v3]
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <Tnop7AqNmjBkOXYL0G0xqL9BQd0P9T4-P1z0n0zxyf0=.35d2834d-87dc-467d-ba86-15d2350d1255@github.com>

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27794/files
  - new: https://git.openjdk.org/jdk/pull/27794/files/1eed131b..a54bc3b6

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

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

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

From ayang at openjdk.org  Tue Oct 14 12:01:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 12:01:30 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v2]
In-Reply-To: <sjt4lEwhm0PUX40IzkFSjdvV-s164MKq7C_Ks8iRBwM=.7dbf00e2-3a7c-4620-b55e-7222518d3e65@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <RrXbAnMZMBuMxPb8W_C4KOnx67Lpj6KNjQxx8cSV7R8=.826f5314-8cf4-4c49-83d1-f3f92cd56e6e@github.com>
 <sjt4lEwhm0PUX40IzkFSjdvV-s164MKq7C_Ks8iRBwM=.7dbf00e2-3a7c-4620-b55e-7222518d3e65@github.com>
Message-ID: <6-qg1bpwB642J9vT37Hbp5joiCrkOMlEMXREhzeKwJw=.36e10b36-be06-4433-91fe-fef1c77336f7@github.com>

On Tue, 14 Oct 2025 11:43:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/gc/shared/cardTableBarrierSet.cpp line 116:
> 
>> 114:   }
>> 115:   if (new_obj->is_typeArray() || _card_table->is_in_young(new_obj)) {
>> 116:     // Arrays of non-references don't need a post-barrier.
> 
> Pre-existing: Maybe `CardTable::is_in_young()` can be made `protected` instead of `public`.

Need to be public; otherwise, build error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27794#discussion_r2428885012

From ayang at openjdk.org  Tue Oct 14 12:09:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 12:09:41 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v4]
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <fWtWkPM_9QANpjSofu380ItPh8PNtGWpAp3w7x8pO8g=.fe7ff824-c5ca-4dfb-a1d1-27a1913fa0ad@github.com>

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27794/files
  - new: https://git.openjdk.org/jdk/pull/27794/files/a54bc3b6..d79b1577

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

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

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

From tschatzl at openjdk.org  Tue Oct 14 12:37:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 12:37:40 GMT
Subject: RFR: 8369818: G1: Add missing region types in gc+heap=debug heap
 output
Message-ID: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>

Hi all,

  please review this update to the `gc+heap=debug` output to contain all region types (I do not know why it only showed eden and survivor).

This is also printed in other places (like `hs_err` files) and it is sometimes very interesting to know that e.g. there are humongous regions around.

It also makes the unit MB because KB is too unwieldy, and the minimum region size is 1 MB anyway.

Testing: local compilation, checking the log output

Thanks,
  Thomas

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

Commit messages:
 - 8369818

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

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

From tschatzl at openjdk.org  Tue Oct 14 12:43:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 12:43:03 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v4]
In-Reply-To: <fWtWkPM_9QANpjSofu380ItPh8PNtGWpAp3w7x8pO8g=.fe7ff824-c5ca-4dfb-a1d1-27a1913fa0ad@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <fWtWkPM_9QANpjSofu380ItPh8PNtGWpAp3w7x8pO8g=.fe7ff824-c5ca-4dfb-a1d1-27a1913fa0ad@github.com>
Message-ID: <P0SezRifAElovW5Mdi40eSdUbRqNps7eIUY7bGrLHLc=.da68fe8e-af49-49d1-8671-333293104736@github.com>

On Tue, 14 Oct 2025 12:09:41 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

I think there is an assert using the deferred card mark stuff in Shenandoah too (ShenandoahBarrierSet::on_slowpath_allocation_exit())

That will make the gha build fail.

Otherwise lgtm - thanks for cleaning this up!

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27794#pullrequestreview-3335404193

From ayang at openjdk.org  Tue Oct 14 12:49:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 12:49:05 GMT
Subject: RFR: 8369818: G1: Add missing region types in gc+heap=debug heap
 output
In-Reply-To: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
References: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
Message-ID: <4iiZLjjhkdZD9Y8fBTNsmJzQwI7onUsQMlj6PMc4P8M=.74d57ad9-d007-4b4a-bbbb-c35685022ad4@github.com>

On Tue, 14 Oct 2025 11:07:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this update to the `gc+heap=debug` output to contain all region types (I do not know why it only showed eden and survivor).
> 
> This is also printed in other places (like `hs_err` files) and it is sometimes very interesting to know that e.g. there are humongous regions around.
> 
> It also makes the unit MB because KB is too unwieldy, and the minimum region size is 1 MB anyway.
> 
> Testing: local compilation, checking the log output
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

> 2285: 
> 2286:   StreamIndentor si(st, 1);
> 2287:   st->print("region size %zuK, ", G1HeapRegion::GrainBytes / K);

Maybe this line can also use `/ M`?

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

PR Review: https://git.openjdk.org/jdk/pull/27798#pullrequestreview-3335429977
PR Review Comment: https://git.openjdk.org/jdk/pull/27798#discussion_r2429034299

From ayang at openjdk.org  Tue Oct 14 12:49:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 12:49:22 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v5]
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27794/files
  - new: https://git.openjdk.org/jdk/pull/27794/files/d79b1577..cf3ea34b

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

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

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

From tschatzl at openjdk.org  Tue Oct 14 12:49:23 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 12:49:23 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v5]
In-Reply-To: <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
Message-ID: <fqdCJ-AuRkn8rQ3wrD9msnrnGLOPYfNAKwOpBmkmvb8=.0187139e-36a0-4277-acd3-36fbd234615a@github.com>

On Tue, 14 Oct 2025 12:46:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

lgtm!

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27794#pullrequestreview-3335427722

From ayang at openjdk.org  Tue Oct 14 13:35:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 14 Oct 2025 13:35:12 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v13]
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@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 17 additional commits since the last revision:

 - Merge branch 'master' into pgc-largepage
 - review
 - Merge branch 'master' into pgc-largepage
 - Merge branch 'master' into pgc-largepage
 - review
 - Merge branch 'master' into pgc-largepage
 - review
 - review
 - review
 - Merge branch 'master' into pgc-largepage
 - ... and 7 more: https://git.openjdk.org/jdk/compare/40320d03...273c2003

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26700/files
  - new: https://git.openjdk.org/jdk/pull/26700/files/a6bafe71..273c2003

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

  Stats: 10072 lines in 144 files changed: 6226 ins; 3462 del; 384 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  Tue Oct 14 16:35:48 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 14 Oct 2025 16:35:48 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure
In-Reply-To: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
Message-ID: <D1YVNTpB5Bdxt3ViOnUvWxsC8QFMg2acmzEhG88SKP4=.9b765687-506d-4a93-bdc8-c85881097eca@github.com>

On Wed, 8 Oct 2025 19:26:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There are certain code paths in Shenandoah's generational mode that need to _know_ which generation is being collected, but it is not possible to pass this information on the stack (barriers, for example). To address this, we introduced an `_active_generation` member in `ShenandoahHeap`. Over time, the usage of this field grew beyond its intended purpose and we began to have issues where not all threads would see a consistent value for this field. To address _this_ issue, we added another field `_gc_generation` which was only meant to be used by GC threads. At this point, we have three different ways to determine which generation is being collected: the _active_ generation, the _gc_ generation, and the usual function parameters and member fields of the gc components. This PR removes `_gc_generation` and reduces the use of `_active_generation` to only those places where it is not possible to get this information from other means (barriers, mostly). All GC components that can have th
 is information passed through function calls, now do so.

Thanks.  Lots of intricate work here.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27703#pullrequestreview-3336550852

From kdnilsen at openjdk.org  Tue Oct 14 16:53:12 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 14 Oct 2025 16:53:12 GMT
Subject: RFR: 8369447: GenShen: Regulator thread may observe inconsistent
 states
In-Reply-To: <5Qa66lljxDIXH8mOo9oyCZTDjZ2OyhgHsurqkfKKhGY=.a784a918-bb7b-4a86-bad6-195ee1800650@github.com>
References: <5Qa66lljxDIXH8mOo9oyCZTDjZ2OyhgHsurqkfKKhGY=.a784a918-bb7b-4a86-bad6-195ee1800650@github.com>
Message-ID: <MYSeBACd3s-HRrUG_tC8DcGZT17ov5YmYMT8g6HfhCk=.cc731a60-6045-4f73-8d7e-6faa1f65ac14@github.com>

On Wed, 8 Oct 2025 18:46:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah's generational mode runs a separate thread to monitor the heap during old collections. This thread is responsible for deciding to start collections. When the thread which actually runs collections (the control thread) changes the state of various gc components _on a safepoint_, it has the expectation that these changes will become visible to mutator threads atomically, and consistently. However, the regulator thread does not participate in safepoints and may observe gc components in inconsistent states and so make incorrect choices about trying to start GC cycles.
> 
> For example:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp:625), pid=3796044, tid=3796163
> # assert(_old_generation->state() == ShenandoahOldGeneration::MARKING) failed: Unexpected old gen state: Waiting for Bootstrap
> #
> 
> The solution here is to make the regulator thread participate in safepoints. There is no need for it to run during a safepoint.

Thanks for this improvement.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27702#pullrequestreview-3336621148

From kdnilsen at openjdk.org  Tue Oct 14 16:57:55 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 14 Oct 2025 16:57:55 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v3]
In-Reply-To: <II_OA6j-VMjwnk1XB5688OK5seMomdZGD7B7WT8uXeY=.744caa48-cc03-4e39-b22a-1711f16d9720@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>
 <Z5RQ4VmAs4E3MnqKk5waMvvXN022mE2cmvp8-g0Khps=.08ad3d03-08f8-4479-ae3f-91c7cecd68e0@github.com>
 <mBD0mE_1BcCRgJR137CEPOZPSRby8JNsFJJK3F_35Co=.5026848f-dc37-4897-b5c4-66d75309e4f6@github.com>
 <II_OA6j-VMjwnk1XB5688OK5seMomdZGD7B7WT8uXeY=.744caa48-cc03-4e39-b22a-1711f16d9720@github.com>
Message-ID: <NnYerTPLmMThksI4tDe4NTZb-B7S8wZP5-FaVqgillY=.e41248a2-1b44-40bd-b443-a6d76fe11671@github.com>

On Wed, 8 Oct 2025 18:01:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I'm still maybe a bit confused.  Is it get_untenurable_live_bytes_in_young_regions()?  Are we distinguishing?
>> 
>> So we have a total of N live bytes within young regions that have been placed into the collection set.  We expect that P bytes (P < N) will be promoted, and the remaining S bytes (S + P == N) will be evacuated to "survivor space" within young.
>> 
>> Does get_live_bytes_in_untenurable_regions() equal P + S?
>
> The _tenure_ here refers to the regions the objects reside in, not the objects themselves. `get_live_bytes_in_tenurable_regions` is the sum of live bytes in all regions with an age above the tenuring threshold (we expect to promote _all_ of these, though some promotions may fail). It's complement `get_live_bytes_in_untenurable_regions` is the sum of live bytes in all regions with an age less than the tenuring threshold (we expect to promote _some_ of these, but we don't really know how many). This was part of the reason I wanted to rename these methods. They  represent the provenance of the objects in the collection set, not necessarily the regions they will be evacuated to.

> get_live_bytes_in_untenurable_regions is the sum of live bytes in all regions with an age less than the tenuring 
> threshold (we expect to promote some of these, but we don't really know how many)

Given that the promotion potential is determined by mark-time age census, I was thinking we do know how many of the bytes in untenurable_regions we "expect to promote".  Isn't this just total_promotable_bytes - get_live_bytes_in_tenurable_regions()?

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

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

From tschatzl at openjdk.org  Tue Oct 14 17:09:33 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 14 Oct 2025 17:09:33 GMT
Subject: RFR: 8369111: G1: Determining concurrent start uses inconsistent
 predicates
Message-ID: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>

Hi all,

  please review this change that fixes an inconsistency between requesting a concurrent start garbage collection during humongous object allocation and then actually starting it.

I.e. in `G1CollectedHeap::attempt_allocation_humongous` we check whether the allocation would cross the IHOP threshold taking the current allocation into account, and if so, see if G1 should start a concurrent marking, eventually starting a GC pause.

That GC pause did not take the prospective allocation into account, so we could do that GC for nothing (i.e. not start a concurrent marking although we already knew that the allocation would cause one).

This, in conjunction with JDK-8368959 can cause hundreds of extra GCs for the test in the CR (without eager reclaim of humongous arrays with references); otherwise it could cause the marking starting too late.

There is a second bug in the calculation whether G1 crossed the threshold: for humongous objects it only takes the actual size into account, not the size that is needed for allocating it. The same issue existed for determining to start a concurrent mark after any other collection too.

The change also tries to unify naming of the parameter to pass the allocation size (`alloc_word_size` -> `allocation_word_size`) and the parameter order where this size is passed along in multiple related methods.

Testing: mentioned test case now behaving correctly, tier1-5

Thanks,
  Thomas

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

Commit messages:
 - 8369111

Changes: https://git.openjdk.org/jdk/pull/27789/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27789&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369111
  Stats: 111 lines in 9 files changed: 35 ins; 8 del; 68 mod
  Patch: https://git.openjdk.org/jdk/pull/27789.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27789/head:pull/27789

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

From kdnilsen at openjdk.org  Tue Oct 14 17:53:18 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 14 Oct 2025 17:53:18 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v5]
In-Reply-To: <nEc_iM749PTRefylVx2mqZDq1tPPRkk2wEh932BKT6k=.d5dbbd87-6c65-4a38-a769-e83ba5501829@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>
 <c0deYfp9H2MYnX0BdsFulINUNVf5gknuI1YWDjtYZ5M=.fc3d8376-d381-43fd-896d-c0fefa5ab607@github.com>
 <7xGe1GZZMDQlU380bkZlAGkgMsI-Q_jRD6qSVJrM664=.640873a9-2c9d-4297-b64b-ec74c7819442@github.com>
 <nEc_iM749PTRefylVx2mqZDq1tPPRkk2wEh932BKT6k=.d5dbbd87-6c65-4a38-a769-e83ba5501829@github.com>
Message-ID: <XD612eROmMhLNrIcDyhZ1rAqUIYYWfRBDPYRLbZTB70=.9a4eb9e1-b34c-4317-9bc7-6cb45d368e80@github.com>

On Wed, 8 Oct 2025 18:13:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> So in the new design, we have full awareness of all promotable objects, and we've already done our best to budget for those.  So there's no such thing as "unanticipated promotions".
>> 
>> Separate question is whether we scale promotion reserve by ShenandoahPromoEvacWaste.  So if old is larger than necessary to handle the anticipated mixed evacuations and promotions, the new code is essentially saying "use this extra space for mixed evacuations rather than for promotions".   Since we're not expanding the promoted_reserve, promotions will not be allowed to touch it.
>> 
>> Am I understanding the intent correctly?
>
> In `compute_evacuation_budgets`, if there are mixed collection candidates we set the initial promotion reserve to zero and the old evacuation reserve to the maximum. However, we then restrict old evacuation reserve to only empty regions. The difference between `old available` and `old unaffiliated` is given to the promotion reserve. Here again, I didn't want to scale the promotion reserve because it's basically the scraps of the old generation and I worry about over committing the old reserve. When there are no mixed collections, we use the entirety of old for promotions. Any old regions not needed for old evacuations or promotions are transferred to the young generation as they were before this change.

Thanks for reminding me how this code works.  So removal of these lines of code has the effect of the following small change in behavior:

1. In the original code, if there was excess memory in old after computing the old (mixed) evacuation reserves (based on ShenandoahOldEvacWaste), we would dedicate this memory to the promotion budget to allow a few more objects to be promoted.  This excess memory is always less than a full region size.  Any excess larger than a region size is transferred to the mutator to reduce allocation pressure.

2. In the new code, any excess memory left in the old evacuation budget is simply left in the old evacuation budget.  By assigning this surplus memory to the old evacuation budget, we reduce the likelihood of experiencing an OOM during evacuation of old objects. This is because the reserve for old evacuation is even larger than what is specified by ShenandoahOldEvacWaste.

Where we place this excess memory is probably of little consequence since the amount of memory is always less than one region size.

However, I believe this will slow promotions during mixed evacuation cycles, which may partially explain why we're not seeing as many benefits from this PR as we had hoped for when we measure the impact on real workloads.

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

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

From wkemper at openjdk.org  Tue Oct 14 23:03:16 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 14 Oct 2025 23:03:16 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
Message-ID: <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>

> There are certain code paths in Shenandoah's generational mode that need to _know_ which generation is being collected, but it is not possible to pass this information on the stack (barriers, for example). To address this, we introduced an `_active_generation` member in `ShenandoahHeap`. Over time, the usage of this field grew beyond its intended purpose and we began to have issues where not all threads would see a consistent value for this field. To address _this_ issue, we added another field `_gc_generation` which was only meant to be used by GC threads. At this point, we have three different ways to determine which generation is being collected: the _active_ generation, the _gc_ generation, and the usual function parameters and member fields of the gc components. This PR removes `_gc_generation` and reduces the use of `_active_generation` to only those places where it is not possible to get this information from other means (barriers, mostly). All GC components that can have th
 is information passed through function calls, now do so.

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

 - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
 - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
 - Remove _gc_generation from ShenandoahHeap
 - Little cleanup, remove one active generation usage
 - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
 - Finish removing usages of gc_generation, start on reducing usages of active_generation
 - Fix build
 - Use existing _generation field instead of Heap::_gc_generation where possible
 - Only shenandoah vm operations participate in active/gc generation scheme

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

Changes: https://git.openjdk.org/jdk/pull/27703/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27703&range=01
  Stats: 494 lines in 32 files changed: 119 ins; 149 del; 226 mod
  Patch: https://git.openjdk.org/jdk/pull/27703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27703/head:pull/27703

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

From stefank at openjdk.org  Wed Oct 15 05:41:02 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 15 Oct 2025 05:41:02 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
Message-ID: <s_WfJqK62lIWu5l4llBjOwuDAzkb60MKzZQbMqIeVE0=.6a9b329e-5063-4396-9625-2587dc5ebd95@github.com>

On Tue, 14 Oct 2025 07:40:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
>> 
>> Testing: local compilation, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * remove more g1freeidset.cpp references from makefiles

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27786#pullrequestreview-3338432500

From tschatzl at openjdk.org  Wed Oct 15 05:52:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 05:52:35 GMT
Subject: RFR: 8369818: G1: Add missing region types in gc+heap=debug heap
 output [v2]
In-Reply-To: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
References: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
Message-ID: <4xV7haZ0gE3M37r2N_r0YKZfCBQ0Pk5E3cyj0LPY98g=.cc68b79b-1e3a-4bd5-a094-06ac4ea9f6e1@github.com>

> Hi all,
> 
>   please review this update to the `gc+heap=debug` output to contain all region types (I do not know why it only showed eden and survivor).
> 
> This is also printed in other places (like `hs_err` files) and it is sometimes very interesting to know that e.g. there are humongous regions around.
> 
> It also makes the unit MB because KB is too unwieldy, and the minimum region size is 1 MB anyway.
> 
> Testing: local compilation, checking the log output
> 
> Thanks,
>   Thomas

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

  Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27798/files
  - new: https://git.openjdk.org/jdk/pull/27798/files/5040a5bb..775f7e8f

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

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

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

From tschatzl at openjdk.org  Wed Oct 15 05:52:37 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 05:52:37 GMT
Subject: RFR: 8369818: G1: Add missing region types in gc+heap=debug heap
 output [v2]
In-Reply-To: <4iiZLjjhkdZD9Y8fBTNsmJzQwI7onUsQMlj6PMc4P8M=.74d57ad9-d007-4b4a-bbbb-c35685022ad4@github.com>
References: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
 <4iiZLjjhkdZD9Y8fBTNsmJzQwI7onUsQMlj6PMc4P8M=.74d57ad9-d007-4b4a-bbbb-c35685022ad4@github.com>
Message-ID: <A76TMaUA7TQwL8_dbXm1okoAacEarb9H2c9kdMabMQs=.6d6773bf-cf56-4320-b04e-80e8e3a22033@github.com>

On Tue, 14 Oct 2025 12:45:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>
> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2287:
> 
>> 2285: 
>> 2286:   StreamIndentor si(st, 1);
>> 2287:   st->print("region size %zuK, ", G1HeapRegion::GrainBytes / K);
> 
> Maybe this line can also use `/ M`?

No preference from me, I changed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27798#discussion_r2431192223

From tschatzl at openjdk.org  Wed Oct 15 05:52:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 05:52:35 GMT
Subject: RFR: 8369818: G1: Add missing region types in gc+heap=debug heap
 output [v2]
In-Reply-To: <4xV7haZ0gE3M37r2N_r0YKZfCBQ0Pk5E3cyj0LPY98g=.cc68b79b-1e3a-4bd5-a094-06ac4ea9f6e1@github.com>
References: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
 <4xV7haZ0gE3M37r2N_r0YKZfCBQ0Pk5E3cyj0LPY98g=.cc68b79b-1e3a-4bd5-a094-06ac4ea9f6e1@github.com>
Message-ID: <6OQtZIV7vU5GyqVZHOZECDc2uYjG3gAhYnMxlDOeAOc=.cc1fa709-6054-44a2-8b09-f8c08a6750aa@github.com>

On Wed, 15 Oct 2025 05:49:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this update to the `gc+heap=debug` output to contain all region types (I do not know why it only showed eden and survivor).
>> 
>> This is also printed in other places (like `hs_err` files) and it is sometimes very interesting to know that e.g. there are humongous regions around.
>> 
>> It also makes the unit MB because KB is too unwieldy, and the minimum region size is 1 MB anyway.
>> 
>> Testing: local compilation, checking the log output
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp

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

> 2285: 
> 2286:   StreamIndentor si(st, 1);
> 2287:   st->print("region size %zuK, ", G1HeapRegion::GrainBytes / K);

Suggestion:

  st->print("region size %zuM, ", G1HeapRegion::GrainBytes / M);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27798#discussion_r2431191197

From tschatzl at openjdk.org  Wed Oct 15 06:15:02 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 06:15:02 GMT
Subject: RFR: 8369681: Parallel: Remove conditional check in
 ParallelScavengeHeap::verify
In-Reply-To: <sD0Y26mh3gwh47yJYkYsoxRUTy1zlJCaHVJKVUIDB4I=.c8e1216b-d7a9-4e31-a807-fcbf8a3022c7@github.com>
References: <sD0Y26mh3gwh47yJYkYsoxRUTy1zlJCaHVJKVUIDB4I=.c8e1216b-d7a9-4e31-a807-fcbf8a3022c7@github.com>
Message-ID: <8hph8fLKMRB1zIKqLnnAc5r7vqY36KzM8wfcSgi-LUs=.aa638410-d32d-4896-9fa0-b7bc02694ab8@github.com>

On Mon, 13 Oct 2025 12:41:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Remove unnecessary `total_collections` checking before verification.
> 
> Test: tier1-5

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27769#pullrequestreview-3338524682

From tschatzl at openjdk.org  Wed Oct 15 06:19:21 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 06:19:21 GMT
Subject: RFR: 8368940: Missing ResourceMark when stalling for shutdown
Message-ID: <xi6D2HS5BlM7MdwZRXSGIz70fCoz85EvstJRhuk40TI=.fafdd27e-dc3e-4255-953f-6579cd46033e@github.com>

Hi all,

  please review this simple fix to add a `ResourceMark` when printing the thread's name when waiting for shutdown.

Thanks,
  Thomas

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

Commit messages:
 - 8368940

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

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

From shade at openjdk.org  Wed Oct 15 06:48:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 15 Oct 2025 06:48:03 GMT
Subject: RFR: 8368940: Missing ResourceMark when stalling for shutdown
In-Reply-To: <xi6D2HS5BlM7MdwZRXSGIz70fCoz85EvstJRhuk40TI=.fafdd27e-dc3e-4255-953f-6579cd46033e@github.com>
References: <xi6D2HS5BlM7MdwZRXSGIz70fCoz85EvstJRhuk40TI=.fafdd27e-dc3e-4255-953f-6579cd46033e@github.com>
Message-ID: <gFviDRGHqq2_gyd0lY7UEhA13sYZh_3-mP1C2H3MJek=.9b8bb491-e534-42f4-bf10-2f930cf5b42d@github.com>

On Wed, 15 Oct 2025 06:10:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this simple fix to add a `ResourceMark` when printing the thread's name when waiting for shutdown.
> 
> Thanks,
>   Thomas

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27814#pullrequestreview-3338628849

From syan at openjdk.org  Wed Oct 15 07:02:05 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 15 Oct 2025 07:02:05 GMT
Subject: RFR: 8368940: Missing ResourceMark when stalling for shutdown
In-Reply-To: <xi6D2HS5BlM7MdwZRXSGIz70fCoz85EvstJRhuk40TI=.fafdd27e-dc3e-4255-953f-6579cd46033e@github.com>
References: <xi6D2HS5BlM7MdwZRXSGIz70fCoz85EvstJRhuk40TI=.fafdd27e-dc3e-4255-953f-6579cd46033e@github.com>
Message-ID: <tsI3yZ8wbyidJXKKayRrSNWHw4ey30zEmGibaZAw4bA=.f65a0856-6133-4707-b356-c0526b7783aa@github.com>

On Wed, 15 Oct 2025 06:10:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this simple fix to add a `ResourceMark` when printing the thread's name when waiting for shutdown.
> 
> Thanks,
>   Thomas

Marked as reviewed by syan (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27814#pullrequestreview-3338699152

From ayang at openjdk.org  Wed Oct 15 09:12:56 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 15 Oct 2025 09:12:56 GMT
Subject: RFR: 8369818: G1: Add missing region types in gc+heap=debug heap
 output [v2]
In-Reply-To: <4xV7haZ0gE3M37r2N_r0YKZfCBQ0Pk5E3cyj0LPY98g=.cc68b79b-1e3a-4bd5-a094-06ac4ea9f6e1@github.com>
References: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
 <4xV7haZ0gE3M37r2N_r0YKZfCBQ0Pk5E3cyj0LPY98g=.cc68b79b-1e3a-4bd5-a094-06ac4ea9f6e1@github.com>
Message-ID: <DecIsKQhvo3Zbp-tmsIL0-YjNNlbwncDsy1WaAZQCiY=.73768794-c505-4435-815c-54aeca5bb759@github.com>

On Wed, 15 Oct 2025 05:52:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this update to the `gc+heap=debug` output to contain all region types (I do not know why it only showed eden and survivor).
>> 
>> This is also printed in other places (like `hs_err` files) and it is sometimes very interesting to know that e.g. there are humongous regions around.
>> 
>> It also makes the unit MB because KB is too unwieldy, and the minimum region size is 1 MB anyway.
>> 
>> Testing: local compilation, checking the log output
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27798#pullrequestreview-3339262031

From ayang at openjdk.org  Wed Oct 15 09:16:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 15 Oct 2025 09:16:58 GMT
Subject: RFR: 8369681: Parallel: Remove conditional check in
 ParallelScavengeHeap::verify
In-Reply-To: <sD0Y26mh3gwh47yJYkYsoxRUTy1zlJCaHVJKVUIDB4I=.c8e1216b-d7a9-4e31-a807-fcbf8a3022c7@github.com>
References: <sD0Y26mh3gwh47yJYkYsoxRUTy1zlJCaHVJKVUIDB4I=.c8e1216b-d7a9-4e31-a807-fcbf8a3022c7@github.com>
Message-ID: <emJwMNZ7R1aDy3mpiFO15Fc3-lcjxlr6L6jldbxVc80=.fcf83cdb-9af1-4c84-b600-dbf250cc0e10@github.com>

On Mon, 13 Oct 2025 12:41:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Remove unnecessary `total_collections` checking before verification.
> 
> Test: tier1-5

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27769#issuecomment-3405385949

From ayang at openjdk.org  Wed Oct 15 09:22:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 15 Oct 2025 09:22:46 GMT
Subject: Integrated: 8369681: Parallel: Remove conditional check in
 ParallelScavengeHeap::verify
In-Reply-To: <sD0Y26mh3gwh47yJYkYsoxRUTy1zlJCaHVJKVUIDB4I=.c8e1216b-d7a9-4e31-a807-fcbf8a3022c7@github.com>
References: <sD0Y26mh3gwh47yJYkYsoxRUTy1zlJCaHVJKVUIDB4I=.c8e1216b-d7a9-4e31-a807-fcbf8a3022c7@github.com>
Message-ID: <t02xlOp5VfZlBedeD7W3u9C2R3hMMvixPdPysQZdZ50=.182560f7-766a-4b0f-af72-eaf146de72c7@github.com>

On Mon, 13 Oct 2025 12:41:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Remove unnecessary `total_collections` checking before verification.
> 
> Test: tier1-5

This pull request has now been integrated.

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

8369681: Parallel: Remove conditional check in ParallelScavengeHeap::verify

Reviewed-by: fandreuzzi, tschatzl

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

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

From iwalulya at openjdk.org  Wed Oct 15 09:28:43 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 15 Oct 2025 09:28:43 GMT
Subject: RFR: 8369818: G1: Add missing region types in gc+heap=debug heap
 output [v2]
In-Reply-To: <4xV7haZ0gE3M37r2N_r0YKZfCBQ0Pk5E3cyj0LPY98g=.cc68b79b-1e3a-4bd5-a094-06ac4ea9f6e1@github.com>
References: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
 <4xV7haZ0gE3M37r2N_r0YKZfCBQ0Pk5E3cyj0LPY98g=.cc68b79b-1e3a-4bd5-a094-06ac4ea9f6e1@github.com>
Message-ID: <uiCYfRgpw7ffedGUq4di-_vkrcwj2nTdCVU_RBgUUL0=.acd354ad-e07a-4122-a64f-a3330269f91a@github.com>

On Wed, 15 Oct 2025 05:52:35 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this update to the `gc+heap=debug` output to contain all region types (I do not know why it only showed eden and survivor).
>> 
>> This is also printed in other places (like `hs_err` files) and it is sometimes very interesting to know that e.g. there are humongous regions around.
>> 
>> It also makes the unit MB because KB is too unwieldy, and the minimum region size is 1 MB anyway.
>> 
>> Testing: local compilation, checking the log output
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27798#pullrequestreview-3339343811

From tschatzl at openjdk.org  Wed Oct 15 11:27:56 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 11:27:56 GMT
Subject: RFR: 8369818: G1: Add missing region types in gc+heap=debug heap
 output [v2]
In-Reply-To: <DecIsKQhvo3Zbp-tmsIL0-YjNNlbwncDsy1WaAZQCiY=.73768794-c505-4435-815c-54aeca5bb759@github.com>
References: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
 <4xV7haZ0gE3M37r2N_r0YKZfCBQ0Pk5E3cyj0LPY98g=.cc68b79b-1e3a-4bd5-a094-06ac4ea9f6e1@github.com>
 <DecIsKQhvo3Zbp-tmsIL0-YjNNlbwncDsy1WaAZQCiY=.73768794-c505-4435-815c-54aeca5bb759@github.com>
Message-ID: <w3cGLJVEHUIXsGDLjR6xioVv7wlK0PKklqJC1b8C0g8=.5191ec4e-f09f-40ed-b2d7-64f8b78aa278@github.com>

On Wed, 15 Oct 2025 09:10:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

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

Thanks @albertnetymk @walulyai for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/27798#issuecomment-3405935471

From tschatzl at openjdk.org  Wed Oct 15 11:27:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 11:27:58 GMT
Subject: Integrated: 8369809: G1: Merge
 G1CollectedHeap::do_collection_pause_at_safepoint[_helper]
In-Reply-To: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
References: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
Message-ID: <NXRD2tNeI5saRC3zDWy7FMeqCsdBUhmzW37dq64iMXc=.c3f3eae0-10a4-4d9b-8a16-3c6a1ebaea76@github.com>

On Tue, 14 Oct 2025 08:59:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial fix to merge `G1CollectedHeap::do_collection_pause_helper` with `do_collection_pause`. The helper method is only called there in this single place and does not add anything but two asserts.
> 
> Testing: gha, local compilation
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 159452e8
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/159452e85a55745fecc58b68ead03a8d330d14dd
Stats:     15 lines in 2 files changed: 3 ins; 11 del; 1 mod

8369809: G1: Merge G1CollectedHeap::do_collection_pause_at_safepoint[_helper]

Reviewed-by: ayang, iwalulya

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

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

From tschatzl at openjdk.org  Wed Oct 15 11:27:58 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 11:27:58 GMT
Subject: Integrated: 8369818: G1: Add missing region types in gc+heap=debug
 heap output
In-Reply-To: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
References: <SIfoBRxpEloQVfoBf5-17EBJJJlbDDVNpqXcvuhUm7w=.5d41185c-759b-43a6-bc7a-15fd8634dc52@github.com>
Message-ID: <NAEe5Zi7oCLvFJ0gYCk1ZWs2jml5csSsrQfcoG_QS-4=.374a94bc-c1fb-4cf1-b1b0-d53a7650bcc2@github.com>

On Tue, 14 Oct 2025 11:07:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this update to the `gc+heap=debug` output to contain all region types (I do not know why it only showed eden and survivor).
> 
> This is also printed in other places (like `hs_err` files) and it is sometimes very interesting to know that e.g. there are humongous regions around.
> 
> It also makes the unit MB because KB is too unwieldy, and the minimum region size is 1 MB anyway.
> 
> Testing: local compilation, checking the log output
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: c53ab10d
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c53ab10daedb5acd3fc7b17e8431b30dff88e3c7
Stats:     12 lines in 1 file changed: 4 ins; 1 del; 7 mod

8369818: G1: Add missing region types in gc+heap=debug heap output

Reviewed-by: ayang, iwalulya

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

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

From tschatzl at openjdk.org  Wed Oct 15 11:27:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 11:27:57 GMT
Subject: RFR: 8369809: G1: Merge
 G1CollectedHeap::do_collection_pause_at_safepoint[_helper] [v2]
In-Reply-To: <kKlzPl4OZ0ZESR2-2tsF5TEuyRFUhq5kVTOiX6GZKf8=.f3fabfc4-7137-4ba2-b8b5-5e60440b6aff@github.com>
References: <r3K7nhnecesTZKDX86pT7h9zio26kWdedKX2_AR7Cx8=.5a19965a-ba09-47a4-9138-db895f8a428d@github.com>
 <roxwp6wqABEsvU1ahrnUklULXcJGr1t-1mmNZipSlcM=.55bfa116-7d44-4ff4-a8bb-7eb05f5b2510@github.com>
 <kKlzPl4OZ0ZESR2-2tsF5TEuyRFUhq5kVTOiX6GZKf8=.f3fabfc4-7137-4ba2-b8b5-5e60440b6aff@github.com>
Message-ID: <yS9Wb0d9JHseQo_DwPoHIMKsLAI-mBBr_GuEz6l3YEY=.cc79fb5b-8008-4081-b9e7-3f8ef8ddf6dc@github.com>

On Tue, 14 Oct 2025 11:38:46 GMT, Ivan Walulya <iwalulya 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/g1CollectedHeap.cpp
>>   
>>   * ayang review
>
> Marked as reviewed by iwalulya (Reviewer).

Thanks @walulyai @albertnetymk for your reviews :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27790#issuecomment-3405937368

From tschatzl at openjdk.org  Wed Oct 15 11:29:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 11:29:52 GMT
Subject: RFR: 8369793: G1: Remove unused G1FreeIdSet [v3]
In-Reply-To: <s_WfJqK62lIWu5l4llBjOwuDAzkb60MKzZQbMqIeVE0=.6a9b329e-5063-4396-9625-2587dc5ebd95@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
 <Fkc0HacB_M3Ziq4nUwx2OFRj0eGYX2pwPCAUYx9q5JQ=.b433c423-3130-41c7-be81-cc17a32989fc@github.com>
 <s_WfJqK62lIWu5l4llBjOwuDAzkb60MKzZQbMqIeVE0=.6a9b329e-5063-4396-9625-2587dc5ebd95@github.com>
Message-ID: <c4kOPa1OvUVBIqz4GLuhiosb76uLncq7J4XuaRQ-mFQ=.6306fb41-7ade-4bc7-9aaa-6276928d192c@github.com>

On Wed, 15 Oct 2025 05:38:22 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * remove more g1freeidset.cpp references from makefiles
>
> Marked as reviewed by stefank (Reviewer).

Thanks @stefank @kimbarrett @kstefanj for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/27786#issuecomment-3405939890

From tschatzl at openjdk.org  Wed Oct 15 11:29:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 15 Oct 2025 11:29:53 GMT
Subject: Integrated: 8369793: G1: Remove unused G1FreeIdSet
In-Reply-To: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
References: <2TlwEoX4J15lVovNLDBcxJ6gF5vlMwNzDITgAU5speI=.8da6c897-ff80-48cb-a160-439647350fa8@github.com>
Message-ID: <Pke5BZm0vW3-N30atcZNVSz1rxbhj9TaKeuxSoJjAxU=.197fb223-a9ed-4636-a839-002680f0509e@github.com>

On Tue, 14 Oct 2025 06:59:33 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this trivial removal of the unused `G1FreeIdSet` code. JEP 522 made it obsolete.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 1af37e5c
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1af37e5c3f7ca46561ef4431ac9b779524888e61
Stats:     331 lines in 4 files changed: 0 ins; 331 del; 0 mod

8369793: G1: Remove unused G1FreeIdSet

Reviewed-by: stefank, sjohanss, kbarrett

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

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

From ayang at openjdk.org  Wed Oct 15 13:39:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 15 Oct 2025 13:39:30 GMT
Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask
Message-ID: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>

Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context.

Test: tier1-5

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

Commit messages:
 - pgc-adjust-root

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

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

From fandreuzzi at openjdk.org  Wed Oct 15 13:55:40 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 15 Oct 2025 13:55:40 GMT
Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask
In-Reply-To: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
References: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
Message-ID: <3so9EioPVcPfAljVDqmIuGZaJ767OzMCcsv80J2YGNM=.184325e1-92e7-4adc-bac1-bdc1f173e98f@github.com>

On Wed, 15 Oct 2025 13:31:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context.
> 
> Test: tier1-5

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1408:

> 1406:       ResourceMark rm;
> 1407:       Threads::possibly_parallel_oops_do(_nworkers > 1, &pc_adjust_pointer_closure, nullptr);
> 1408:       if (try_claim_code_cache_task()) {

Can `worker_id = 0` always do it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27822#discussion_r2432659580

From ayang at openjdk.org  Wed Oct 15 14:04:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 15 Oct 2025 14:04:04 GMT
Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask
In-Reply-To: <3so9EioPVcPfAljVDqmIuGZaJ767OzMCcsv80J2YGNM=.184325e1-92e7-4adc-bac1-bdc1f173e98f@github.com>
References: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
 <3so9EioPVcPfAljVDqmIuGZaJ767OzMCcsv80J2YGNM=.184325e1-92e7-4adc-bac1-bdc1f173e98f@github.com>
Message-ID: <lsJcjiGpVthcL70HO1sNuFUmdZlcycTgfUCGRy3GQsk=.e348d7df-c0a1-4e36-8386-dfb44120f1bb@github.com>

On Wed, 15 Oct 2025 13:53:14 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context.
>> 
>> Test: tier1-5
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1408:
> 
>> 1406:       ResourceMark rm;
>> 1407:       Threads::possibly_parallel_oops_do(_nworkers > 1, &pc_adjust_pointer_closure, nullptr);
>> 1408:       if (try_claim_code_cache_task()) {
> 
> Can `worker_id = 0` always do it?

I did consider use the same technique in `PSParallelCleaningTask` here, but I wanna keep this semantic grouping instead of placing serial-task at the beginning of this method. Therefore, I chose this way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27822#discussion_r2432689750

From wkemper at openjdk.org  Wed Oct 15 18:42:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Oct 2025 18:42:35 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v3]
In-Reply-To: <NnYerTPLmMThksI4tDe4NTZb-B7S8wZP5-FaVqgillY=.e41248a2-1b44-40bd-b443-a6d76fe11671@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>
 <Z5RQ4VmAs4E3MnqKk5waMvvXN022mE2cmvp8-g0Khps=.08ad3d03-08f8-4479-ae3f-91c7cecd68e0@github.com>
 <mBD0mE_1BcCRgJR137CEPOZPSRby8JNsFJJK3F_35Co=.5026848f-dc37-4897-b5c4-66d75309e4f6@github.com>
 <II_OA6j-VMjwnk1XB5688OK5seMomdZGD7B7WT8uXeY=.744caa48-cc03-4e39-b22a-1711f16d9720@github.com>
 <NnYerTPLmMThksI4tDe4NTZb-B7S8wZP5-FaVqgillY=.e41248a2-1b44-40bd-b443-a6d76fe11671@github.com>
Message-ID: <1RrkUiDtpqSYgsOI-_2b7WDqj0aYZSSWC57qf5HsT9I=.0c59d198-c0de-4bea-80fa-efd0f0493e82@github.com>

On Tue, 14 Oct 2025 16:55:33 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The _tenure_ here refers to the regions the objects reside in, not the objects themselves. `get_live_bytes_in_tenurable_regions` is the sum of live bytes in all regions with an age above the tenuring threshold (we expect to promote _all_ of these, though some promotions may fail). It's complement `get_live_bytes_in_untenurable_regions` is the sum of live bytes in all regions with an age less than the tenuring threshold (we expect to promote _some_ of these, but we don't really know how many). This was part of the reason I wanted to rename these methods. They  represent the provenance of the objects in the collection set, not necessarily the regions they will be evacuated to.
>
>> get_live_bytes_in_untenurable_regions is the sum of live bytes in all regions with an age less than the tenuring 
>> threshold (we expect to promote some of these, but we don't really know how many)
> 
> Given that the promotion potential is determined by mark-time age census, I was thinking we do know how many of the bytes in untenurable_regions we "expect to promote".  Isn't this just total_promotable_bytes - get_live_bytes_in_tenurable_regions()?

The age census doesn't give us the level of detail to break down promotable bytes per region. The collection set has a subset of the tenurable and untenurable regions. Of those, we still don't really _know_ how much of the live data in the tenurable regions will be promoted. The changes here try to plan for the worst case by reserving as much of old as possible for promotions.

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

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

From wkemper at openjdk.org  Wed Oct 15 22:27:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Oct 2025 22:27:35 GMT
Subject: RFR: 8367709: GenShen: Dirty cards for objects that get promoted by
 safepoint that intervenes between allocation and stores
Message-ID: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>

I believe this sequence of events can lead to the original assertion failing:
1. Shenandoah lowers the tenuring threshold to 1.
2. An object gets allocated on the slow path.
3. We come to a safepoint and run a degenerated cycle.
4. The object is evacuated during the degenerated cycle and has its age raised to 1.
5. The degenerated cycle is "upgraded" to a full GC.
6. The object is at the tenuring age and gets promoted by the full GC into an old region.
7. We leave the safepoint and the assertion fails because this "new" object is an old region.

However, there is still a risk that the card marking barriers have been elided for this object. Now that the object is in the old generation we must be sure that if it ends up storing any pointers to young, then these cards must be dirtied. The solution here is conservative in that it just dirties _all_ the cards for this object. We expect this condition to be rare and the card table will refine itself on subsequent GC cycles. Also, note that we will not scan the remembered set without coming to the `init-mark` safepoint, so it will see these dirty cards.

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

Commit messages:
 - Slip of the mouse
 - Remove instrumentation
 - Merge remote-tracking branch 'jdk/master' into not-allocated-young
 - Dirty cards for newly allocated objects that are promoted during a safepoint
 - Instrumentation to track where objects are being evacuated
 - More instrumentation
 - Instrumentation for array allocs too
 - Fix instrumentation
 - Instrument slowpath allocation

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

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

From ysr at openjdk.org  Wed Oct 15 22:54:17 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 15 Oct 2025 22:54:17 GMT
Subject: RFR: 8367709: GenShen: Dirty cards for objects that get promoted
 by safepoint that intervenes between allocation and stores
In-Reply-To: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
References: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
Message-ID: <TQ6dh21oQi8K_JHO8zxvYzI2eEVhOEwHrU6fJ1mzo3E=.11341c9b-5bad-4a60-95ce-aaede263318f@github.com>

On Wed, 15 Oct 2025 20:53:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I believe this sequence of events can lead to the original assertion failing:
> 1. Shenandoah lowers the tenuring threshold to 1.
> 2. An object gets allocated on the slow path.
> 3. We come to a safepoint and run a degenerated cycle.
> 4. The object is evacuated during the degenerated cycle and has its age raised to 1.
> 5. The degenerated cycle is "upgraded" to a full GC.
> 6. The object is at the tenuring age and gets promoted by the full GC into an old region.
> 7. We leave the safepoint and the assertion fails because this "new" object is an old region.
> 
> However, there is still a risk that the card marking barriers have been elided for this object. Now that the object is in the old generation we must be sure that if it ends up storing any pointers to young, then these cards must be dirtied. The solution here is conservative in that it just dirties _all_ the cards for this object. We expect this condition to be rare and the card table will refine itself on subsequent GC cycles. Also, note that we will not scan the remembered set without coming to the `init-mark` safepoint, so it will see these dirty cards.

Good catch of this slippery, if rare, condition. This looks good, but is it possible that we can use a debug `*ALot` type of flag to manually enlarge the post-allocation window so as to induce this condition (promotion) to happen more frequently in fastdebug runs with the flag enabled? That would exercise this code some.

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

> 104:   }
> 105: #endif // COMPILER2_OR_JVMCI
> 106:   assert(thread->deferred_card_mark().is_empty(), "We don't use this");

This is rare, so probably not worth the extra work, but there is an existing mechanism to defer this until the safepoint (or until another such deferment arises). Not sure if it's worth using it.

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

PR Review: https://git.openjdk.org/jdk/pull/27832#pullrequestreview-3342585610
PR Review Comment: https://git.openjdk.org/jdk/pull/27832#discussion_r2434156837

From ysr at openjdk.org  Wed Oct 15 22:58:03 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 15 Oct 2025 22:58:03 GMT
Subject: RFR: 8367709: GenShen: Dirty cards for objects that get promoted
 by safepoint that intervenes between allocation and stores
In-Reply-To: <TQ6dh21oQi8K_JHO8zxvYzI2eEVhOEwHrU6fJ1mzo3E=.11341c9b-5bad-4a60-95ce-aaede263318f@github.com>
References: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
 <TQ6dh21oQi8K_JHO8zxvYzI2eEVhOEwHrU6fJ1mzo3E=.11341c9b-5bad-4a60-95ce-aaede263318f@github.com>
Message-ID: <bd66VD8BkKvG4zfb5e3BbZxe_FTJ7IOF7VAVjiCXTzc=.853c3c08-789d-4503-8df3-03aa402734c4@github.com>

On Wed, 15 Oct 2025 22:51:23 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> I believe this sequence of events can lead to the original assertion failing:
>> 1. Shenandoah lowers the tenuring threshold to 1.
>> 2. An object gets allocated on the slow path.
>> 3. We come to a safepoint and run a degenerated cycle.
>> 4. The object is evacuated during the degenerated cycle and has its age raised to 1.
>> 5. The degenerated cycle is "upgraded" to a full GC.
>> 6. The object is at the tenuring age and gets promoted by the full GC into an old region.
>> 7. We leave the safepoint and the assertion fails because this "new" object is an old region.
>> 
>> However, there is still a risk that the card marking barriers have been elided for this object. Now that the object is in the old generation we must be sure that if it ends up storing any pointers to young, then these cards must be dirtied. The solution here is conservative in that it just dirties _all_ the cards for this object. We expect this condition to be rare and the card table will refine itself on subsequent GC cycles. Also, note that we will not scan the remembered set without coming to the `init-mark` safepoint, so it will see these dirty cards.
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp line 106:
> 
>> 104:   }
>> 105: #endif // COMPILER2_OR_JVMCI
>> 106:   assert(thread->deferred_card_mark().is_empty(), "We don't use this");
> 
> This is rare, so probably not worth the extra work, but there is an existing mechanism to defer this until the safepoint (or until another such deferment arises). Not sure if it's worth using it.

Probably not worth the trouble, because that mechanism might require wiring in some other stuff which may not be wired in for GenShen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27832#discussion_r2434162161

From ysr at openjdk.org  Wed Oct 15 23:00:55 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 15 Oct 2025 23:00:55 GMT
Subject: RFR: 8367709: GenShen: Dirty cards for objects that get promoted
 by safepoint that intervenes between allocation and stores
In-Reply-To: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
References: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
Message-ID: <p8SUqzMZm81QOrBJ395TtaIklqxDf7eN3bhK9GUVrx4=.32ffe8ed-ed3f-4f5b-8458-4c664206a19a@github.com>

On Wed, 15 Oct 2025 20:53:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I believe this sequence of events can lead to the original assertion failing:
> 1. Shenandoah lowers the tenuring threshold to 1.
> 2. An object gets allocated on the slow path.
> 3. We come to a safepoint and run a degenerated cycle.
> 4. The object is evacuated during the degenerated cycle and has its age raised to 1.
> 5. The degenerated cycle is "upgraded" to a full GC.
> 6. The object is at the tenuring age and gets promoted by the full GC into an old region.
> 7. We leave the safepoint and the assertion fails because this "new" object is an old region.
> 
> However, there is still a risk that the card marking barriers have been elided for this object. Now that the object is in the old generation we must be sure that if it ends up storing any pointers to young, then these cards must be dirtied. The solution here is conservative in that it just dirties _all_ the cards for this object. We expect this condition to be rare and the card table will refine itself on subsequent GC cycles. Also, note that we will not scan the remembered set without coming to the `init-mark` safepoint, so it will see these dirty cards.

(Left a comment about possibly exercising this code, if easy to do so.) Not a blocking suggestion, though. Approved.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27832#pullrequestreview-3342594514

From wkemper at openjdk.org  Wed Oct 15 23:08:14 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Oct 2025 23:08:14 GMT
Subject: RFR: 8367709: GenShen: Dirty cards for objects that get promoted
 by safepoint that intervenes between allocation and stores
In-Reply-To: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
References: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
Message-ID: <tQkYzi5W7THeIdm7rokFo51QYUahMeMz4N4UHU6qmYg=.3f4fede5-2c02-4e81-ab1f-718ae6f4cc16@github.com>

On Wed, 15 Oct 2025 20:53:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I believe this sequence of events can lead to the original assertion failing:
> 1. Shenandoah lowers the tenuring threshold to 1.
> 2. An object gets allocated on the slow path.
> 3. We come to a safepoint and run a degenerated cycle.
> 4. The object is evacuated during the degenerated cycle and has its age raised to 1.
> 5. The degenerated cycle is "upgraded" to a full GC.
> 6. The object is at the tenuring age and gets promoted by the full GC into an old region.
> 7. We leave the safepoint and the assertion fails because this "new" object is an old region.
> 
> However, there is still a risk that the card marking barriers have been elided for this object. Now that the object is in the old generation we must be sure that if it ends up storing any pointers to young, then these cards must be dirtied. The solution here is conservative in that it just dirties _all_ the cards for this object. We expect this condition to be rare and the card table will refine itself on subsequent GC cycles. Also, note that we will not scan the remembered set without coming to the `init-mark` safepoint, so it will see these dirty cards.

This condition does happen pretty reliably in the `vmTestbase/vm/gc/concurrent/` family of tests mentioned in the ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/27832#issuecomment-3408586943

From wkemper at openjdk.org  Wed Oct 15 23:08:16 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 15 Oct 2025 23:08:16 GMT
Subject: RFR: 8367709: GenShen: Dirty cards for objects that get promoted
 by safepoint that intervenes between allocation and stores
In-Reply-To: <bd66VD8BkKvG4zfb5e3BbZxe_FTJ7IOF7VAVjiCXTzc=.853c3c08-789d-4503-8df3-03aa402734c4@github.com>
References: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
 <TQ6dh21oQi8K_JHO8zxvYzI2eEVhOEwHrU6fJ1mzo3E=.11341c9b-5bad-4a60-95ce-aaede263318f@github.com>
 <bd66VD8BkKvG4zfb5e3BbZxe_FTJ7IOF7VAVjiCXTzc=.853c3c08-789d-4503-8df3-03aa402734c4@github.com>
Message-ID: <aw8AKOHYmq_3TvGHF-fh3OdG03p5IrtKdiA3r1MHTy0=.85d3aa75-51d7-42e3-a0ec-14fc913704a7@github.com>

On Wed, 15 Oct 2025 22:55:47 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp line 106:
>> 
>>> 104:   }
>>> 105: #endif // COMPILER2_OR_JVMCI
>>> 106:   assert(thread->deferred_card_mark().is_empty(), "We don't use this");
>> 
>> This is rare, so probably not worth the extra work, but there is an existing mechanism to defer this until the safepoint (or until another such deferment arises). Not sure if it's worth using it.
>
> Probably not worth the trouble, because that mechanism might require wiring in some other stuff which may not be wired in for GenShen.

Yeah, I thought it looked like a lot of complexity to bring in.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27832#discussion_r2434169557

From ysr at openjdk.org  Wed Oct 15 23:08:16 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 15 Oct 2025 23:08:16 GMT
Subject: RFR: 8367709: GenShen: Dirty cards for objects that get promoted
 by safepoint that intervenes between allocation and stores
In-Reply-To: <aw8AKOHYmq_3TvGHF-fh3OdG03p5IrtKdiA3r1MHTy0=.85d3aa75-51d7-42e3-a0ec-14fc913704a7@github.com>
References: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
 <TQ6dh21oQi8K_JHO8zxvYzI2eEVhOEwHrU6fJ1mzo3E=.11341c9b-5bad-4a60-95ce-aaede263318f@github.com>
 <bd66VD8BkKvG4zfb5e3BbZxe_FTJ7IOF7VAVjiCXTzc=.853c3c08-789d-4503-8df3-03aa402734c4@github.com>
 <aw8AKOHYmq_3TvGHF-fh3OdG03p5IrtKdiA3r1MHTy0=.85d3aa75-51d7-42e3-a0ec-14fc913704a7@github.com>
Message-ID: <jvKUFjODlRiFgoiAiboKAYkrH8nJfelkslpQvKioyAY=.39883976-1f5f-43b5-ab3e-1af4c4cbc349@github.com>

On Wed, 15 Oct 2025 23:01:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Probably not worth the trouble, because that mechanism might require wiring in some other stuff which may not be wired in for GenShen.
>
> Yeah, I thought it looked like a lot of complexity to bring in.

I agree.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27832#discussion_r2434173720

From tschatzl at openjdk.org  Thu Oct 16 05:35:15 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 16 Oct 2025 05:35:15 GMT
Subject: RFR: 8368940: Missing ResourceMark when stalling for shutdown
In-Reply-To: <tsI3yZ8wbyidJXKKayRrSNWHw4ey30zEmGibaZAw4bA=.f65a0856-6133-4707-b356-c0526b7783aa@github.com>
References: <xi6D2HS5BlM7MdwZRXSGIz70fCoz85EvstJRhuk40TI=.fafdd27e-dc3e-4255-953f-6579cd46033e@github.com>
 <tsI3yZ8wbyidJXKKayRrSNWHw4ey30zEmGibaZAw4bA=.f65a0856-6133-4707-b356-c0526b7783aa@github.com>
Message-ID: <vhjnpU9ZrcaPtp1UecFAbNTeG1APdM1AyNOCUdUNrrs=.e55b9c99-f2cf-4803-965e-96f74dab8bf8@github.com>

On Wed, 15 Oct 2025 06:59:14 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this simple fix to add a `ResourceMark` when printing the thread's name when waiting for shutdown.
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by syan (Committer).

Thanks @sendaoYan @shipilev for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/27814#issuecomment-3409235448

From tschatzl at openjdk.org  Thu Oct 16 05:35:16 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 16 Oct 2025 05:35:16 GMT
Subject: Integrated: 8368940: Missing ResourceMark when stalling for shutdown
In-Reply-To: <xi6D2HS5BlM7MdwZRXSGIz70fCoz85EvstJRhuk40TI=.fafdd27e-dc3e-4255-953f-6579cd46033e@github.com>
References: <xi6D2HS5BlM7MdwZRXSGIz70fCoz85EvstJRhuk40TI=.fafdd27e-dc3e-4255-953f-6579cd46033e@github.com>
Message-ID: <c5AYNbowWcxc8h214fyp2HHqyf0UMDEKcSqPTKmakPo=.f9483d93-efc3-4117-8ba7-48dd3a7f4c2b@github.com>

On Wed, 15 Oct 2025 06:10:11 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this simple fix to add a `ResourceMark` when printing the thread's name when waiting for shutdown.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 0168687f
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0168687fc372e6649f8e9a5a96a3614e7bab8543
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8368940: Missing ResourceMark when stalling for shutdown

Reviewed-by: shade, syan

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

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

From fandreuzzi at openjdk.org  Thu Oct 16 08:20:47 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 08:20:47 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v5]
In-Reply-To: <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
Message-ID: <gYU0cTn8WA4qju9TcHFs0eJZyTotnmp38b1l_-_C_wo=.4b4f6314-4b62-4d6c-b441-39c0528077c5@github.com>

On Tue, 14 Oct 2025 12:49:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27794#pullrequestreview-3343613146

From fandreuzzi at openjdk.org  Thu Oct 16 11:09:23 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 11:09:23 GMT
Subject: RFR: 8369980: Use ThreadsClaimTokenScope in ShenandoahThreadRoots
Message-ID: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>

The explicit usage of `Threads::change_thread_claim_token` and `Threads::assert_all_threads_claimed` in `ShenandoahThreadRoots` can be replaced with `ThreadsClaimTokenScope`.

Passes tier1, tier2, tier[1,2,3]_gc_shenandoah (fastdebug).

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

Commit messages:
 - replace

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

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

From ayang at openjdk.org  Thu Oct 16 11:17:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 16 Oct 2025 11:17:11 GMT
Subject: RFR: 8369980: Use ThreadsClaimTokenScope in ShenandoahThreadRoots
In-Reply-To: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>
References: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>
Message-ID: <cNfVZMtHNm425G20llq-u-RxhCW4r5XZCNHUT_vYwJA=.799860ff-eb5f-429d-8c1d-8ed0e9bc9da9@github.com>

On Thu, 16 Oct 2025 11:02:50 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The explicit usage of `Threads::change_thread_claim_token` and `Threads::assert_all_threads_claimed` in `ShenandoahThreadRoots` can be replaced with `ThreadsClaimTokenScope`.
> 
> Passes tier1, tier2, tier[1,2,3]_gc_shenandoah (fastdebug).

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27845#pullrequestreview-3344295158

From gli at openjdk.org  Thu Oct 16 12:09:18 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Thu, 16 Oct 2025 12:09:18 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v3]
In-Reply-To: <JqITJ_1rjkMp3QENj_5CqLR86J-L5Wj4tL28hDofyFE=.dd9c62ef-7b9a-415b-b387-7b8c9bca1499@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
 <JqITJ_1rjkMp3QENj_5CqLR86J-L5Wj4tL28hDofyFE=.dd9c62ef-7b9a-415b-b387-7b8c9bca1499@github.com>
Message-ID: <M0Za4q1Eo3ogjgDUyw_7HnOXwJmvN8maypiP9cNxM-A=.468ef286-2f9d-4b70-ab85-96c1ac2dda03@github.com>

On Mon, 13 Oct 2025 09:37:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc.
>> 
>> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into sgc-expand-allocate
>  - review
>  - sgc-expand-allocate

Looks good.

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

Marked as reviewed by gli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27513#pullrequestreview-3344486294

From fandreuzzi at openjdk.org  Thu Oct 16 12:46:20 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 16 Oct 2025 12:46:20 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v3]
In-Reply-To: <JqITJ_1rjkMp3QENj_5CqLR86J-L5Wj4tL28hDofyFE=.dd9c62ef-7b9a-415b-b387-7b8c9bca1499@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
 <JqITJ_1rjkMp3QENj_5CqLR86J-L5Wj4tL28hDofyFE=.dd9c62ef-7b9a-415b-b387-7b8c9bca1499@github.com>
Message-ID: <W85ZCvxJXHAStLubq-NvcjER24zOgfX-wUqYbYdpOpE=.ac015f40-0b47-4cd3-a40d-f84d5a1d786f@github.com>

On Mon, 13 Oct 2025 09:37:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc.
>> 
>> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into sgc-expand-allocate
>  - review
>  - sgc-expand-allocate

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27513#pullrequestreview-3344655030

From wkemper at openjdk.org  Thu Oct 16 17:52:06 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Oct 2025 17:52:06 GMT
Subject: Integrated: 8367709: GenShen: Dirty cards for objects that get
 promoted by safepoint that intervenes between allocation and stores
In-Reply-To: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
References: <czwS3KHFSoLPyQVXXii-nLxlAvGvDb1JKIeN9rrAxlY=.0e714ab3-0e1e-469e-b4a1-2ecc312eeef5@github.com>
Message-ID: <YfSNLzCzGaZvOYn7E7BOl2f_dgvD1veDWSU76Awntgs=.dc11e814-6e0c-4ad9-a684-c950cf9bee68@github.com>

On Wed, 15 Oct 2025 20:53:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I believe this sequence of events can lead to the original assertion failing:
> 1. Shenandoah lowers the tenuring threshold to 1.
> 2. An object gets allocated on the slow path.
> 3. We come to a safepoint and run a degenerated cycle.
> 4. The object is evacuated during the degenerated cycle and has its age raised to 1.
> 5. The degenerated cycle is "upgraded" to a full GC.
> 6. The object is at the tenuring age and gets promoted by the full GC into an old region.
> 7. We leave the safepoint and the assertion fails because this "new" object is an old region.
> 
> However, there is still a risk that the card marking barriers have been elided for this object. Now that the object is in the old generation we must be sure that if it ends up storing any pointers to young, then these cards must be dirtied. The solution here is conservative in that it just dirties _all_ the cards for this object. We expect this condition to be rare and the card table will refine itself on subsequent GC cycles. Also, note that we will not scan the remembered set without coming to the `init-mark` safepoint, so it will see these dirty cards.

This pull request has now been integrated.

Changeset: d4472979
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d4472979c43d9825ed2d008dbaed26dbf6d36180
Stats:     25 lines in 5 files changed: 11 ins; 0 del; 14 mod

8367709: GenShen: Dirty cards for objects that get promoted by safepoint that intervenes between allocation and stores

Reviewed-by: ysr

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

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

From wkemper at openjdk.org  Thu Oct 16 18:38:53 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Oct 2025 18:38:53 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v4]
In-Reply-To: <yjkVPu3243hAsJoevFrjsH7v-_1UBiwGFCJEB6MkARI=.21b4b659-85df-4dec-b478-9fc1ae7ada17@github.com>
References: <I5yN-P2pZOGGsr0BovMGkqF7tc39fEkAPpb_07sHmog=.616fd50b-1cf8-4820-8230-284e2433fd7b@github.com>
 <u9GVAOeNkg5TL2dBBEWLDZNrMvxBYlFdUeXdRQl1VIs=.4e1ebef5-8a2c-49f8-974a-15d840ad75eb@github.com>
 <yjkVPu3243hAsJoevFrjsH7v-_1UBiwGFCJEB6MkARI=.21b4b659-85df-4dec-b478-9fc1ae7ada17@github.com>
Message-ID: <oDoz-rLQNB_k4o9-Lf2bT_cwWTdKg8oTW4uJsF9JlLc=.88c75468-b56e-487d-abda-f4f79ff2cc6a@github.com>

On Thu, 9 Oct 2025 23:44:04 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback, bug fixes
>
>> 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.
> 
> @earthling-amzn : Can the comparisons be done in each of the two classes, i.e. x86 and aarch64, separately? Not sure if it'll give more statistically significant differences between test and control.
> 
> Was there any significant difference (on x86 or aarch64 separately) on SPECjbb?

@ysramakrishna , the results between aarch64 and x86 are similar.

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

PR Comment: https://git.openjdk.org/jdk/pull/27632#issuecomment-3412312046

From wkemper at openjdk.org  Thu Oct 16 18:38:54 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Oct 2025 18:38:54 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v5]
In-Reply-To: <XD612eROmMhLNrIcDyhZ1rAqUIYYWfRBDPYRLbZTB70=.9a4eb9e1-b34c-4317-9bc7-6cb45d368e80@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>
 <c0deYfp9H2MYnX0BdsFulINUNVf5gknuI1YWDjtYZ5M=.fc3d8376-d381-43fd-896d-c0fefa5ab607@github.com>
 <7xGe1GZZMDQlU380bkZlAGkgMsI-Q_jRD6qSVJrM664=.640873a9-2c9d-4297-b64b-ec74c7819442@github.com>
 <nEc_iM749PTRefylVx2mqZDq1tPPRkk2wEh932BKT6k=.d5dbbd87-6c65-4a38-a769-e83ba5501829@github.com>
 <XD612eROmMhLNrIcDyhZ1rAqUIYYWfRBDPYRLbZTB70=.9a4eb9e1-b34c-4317-9bc7-6cb45d368e80@github.com>
Message-ID: <PBxFaGrmMnKvJTjdrukeHV-16TvP3q-Zs4x6MxdNuIA=.cd10734e-2ecd-46b7-b259-c8623646c403@github.com>

On Tue, 14 Oct 2025 17:50:16 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> In `compute_evacuation_budgets`, if there are mixed collection candidates we set the initial promotion reserve to zero and the old evacuation reserve to the maximum. However, we then restrict old evacuation reserve to only empty regions. The difference between `old available` and `old unaffiliated` is given to the promotion reserve. Here again, I didn't want to scale the promotion reserve because it's basically the scraps of the old generation and I worry about over committing the old reserve. When there are no mixed collections, we use the entirety of old for promotions. Any old regions not needed for old evacuations or promotions are transferred to the young generation as they were before this change.
>
> Thanks for reminding me how this code works.  So removal of these lines of code has the effect of the following small change in behavior:
> 
> 1. In the original code, if there was excess memory in old after computing the old (mixed) evacuation reserves (based on ShenandoahOldEvacWaste), we would dedicate this memory to the promotion budget to allow a few more objects to be promoted.  This excess memory is always less than a full region size.  Any excess larger than a region size is transferred to the mutator to reduce allocation pressure.
> 
> 2. In the new code, any excess memory left in the old evacuation budget is simply left in the old evacuation budget.  By assigning this surplus memory to the old evacuation budget, we reduce the likelihood of experiencing an OOM during evacuation of old objects. This is because the reserve for old evacuation is even larger than what is specified by ShenandoahOldEvacWaste.
> 
> Where we place this excess memory is probably of little consequence since the amount of memory is always less than one region size.
> 
> However, I believe this will slow promotions during mixed evacuation cycles, which may partially explain why we're not seeing as many benefits from this PR as we had hoped for when we measure the impact on real workloads.

This part of the algorithm didn't really change. During a mixed evacuation, it attempts to restrict old evacuations to _empty_ regions. The difference between the old reserve and the memory available in empty regions is made available for promotions. I believe the sum of the memory available in these non-empty old regions could be more than a single region. Anything not expected to be used by old evacuations or promotions is returned to the mutator's partition. Before this change, the value of _expected promotions_ was computed as `tenurable region count * region size * promo waste`. After this change, the value of _expected promotions_ is computed directly from the census during mark. It is generally the case that expected promotions _before_ this change will be less than expected promotions _after_ this change. Excess old reserve is still transferred to the mutator partition, but it will generally be less now.

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

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

From wkemper at openjdk.org  Thu Oct 16 18:51:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Oct 2025 18:51:56 GMT
Subject: RFR: 8369980: Use ThreadsClaimTokenScope in ShenandoahThreadRoots
In-Reply-To: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>
References: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>
Message-ID: <D4HvhAyqANcqTlaqzL4NKsmoiQc4_9cjwFf46ng4lmI=.a04ea541-e927-49b7-a0f4-d04a345ed49c@github.com>

On Thu, 16 Oct 2025 11:02:50 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The explicit usage of `Threads::change_thread_claim_token` and `Threads::assert_all_threads_claimed` in `ShenandoahThreadRoots` can be replaced with `ThreadsClaimTokenScope`.
> 
> Passes tier1, tier2, tier[1,2,3]_gc_shenandoah (fastdebug).

Looks good to me.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27845#pullrequestreview-3346499018

From wkemper at openjdk.org  Thu Oct 16 19:09:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 16 Oct 2025 19:09:40 GMT
Subject: RFR: 8241066: Shenandoah: fix or cleanup SH::do_full_collection
Message-ID: <IgMaXYV81ctneiSvUVIqFN7ywN8etes_sfKuiPN6XVA=.ec47d4bd-7ef2-4806-8930-15bf60d983c1@github.com>

This `ShenandoahHeap::do_full_collection` will never be called by our implementation of `collect_as_vm_thread`.

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

Commit messages:
 - Clarify comment
 - Fix commented out assertion with actual assertion and explanation.

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

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

From ayang at openjdk.org  Thu Oct 16 19:58:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 16 Oct 2025 19:58:52 GMT
Subject: RFR: 8368740: Serial: Swap eden and survivor spaces position in
 young generation [v3]
In-Reply-To: <JqITJ_1rjkMp3QENj_5CqLR86J-L5Wj4tL28hDofyFE=.dd9c62ef-7b9a-415b-b387-7b8c9bca1499@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
 <JqITJ_1rjkMp3QENj_5CqLR86J-L5Wj4tL28hDofyFE=.dd9c62ef-7b9a-415b-b387-7b8c9bca1499@github.com>
Message-ID: <hVmMK6MSLsk84FsKhyP9Ihxo0cBEt0g-l79oyhEr1ro=.47ebb715-5ff2-42fa-a6a3-56a665d32eda@github.com>

On Mon, 13 Oct 2025 09:37:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc.
>> 
>> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into sgc-expand-allocate
>  - review
>  - sgc-expand-allocate

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27513#issuecomment-3412623475

From ayang at openjdk.org  Thu Oct 16 19:58:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 16 Oct 2025 19:58:53 GMT
Subject: Integrated: 8368740: Serial: Swap eden and survivor spaces position in
 young generation
In-Reply-To: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
References: <B4LE3CdXeoFgM1GG4Jt_m0Q-odnk1UiwvHZL2ygpXNU=.5144f8bc-1763-4566-b5e0-4d9d469b70b1@github.com>
Message-ID: <MeHDPdO2q3ZUT3-vVwc-pbwllrTVgbBa61LnYfPSPhQ=.c1f2e41c-fdb5-41c0-b5fd-a511f414da3b@github.com>

On Fri, 26 Sep 2025 07:33:19 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Change the relative position of eden and survior spaces in young-gen so that eden can be expanded to fulfill allocation request in heap-near-full scenario. What is on master doesn't allow eden expansion if there is live objs inside from/to after full-gc.
> 
> Test: tier1-8

This pull request has now been integrated.

Changeset: 1392a0b4
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1392a0b4608f6196f207fcebbab75b2d79fdc758
Stats:     227 lines in 5 files changed: 72 ins; 59 del; 96 mod

8368740: Serial: Swap eden and survivor spaces position in young generation

Reviewed-by: gli, fandreuzzi

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

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

From ayang at openjdk.org  Fri Oct 17 09:36:18 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 09:36:18 GMT
Subject: RFR: 8369814: G1: Relax card mark and store ordering [v5]
In-Reply-To: <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
 <Gf3JGYhvfljdhBaVr3fvReGkKJL-nELC3SAL5RWMjUY=.e37fce37-cdfd-4ab3-995a-28062322a4e9@github.com>
Message-ID: <xUgJ5Vw_jUDCJEdtuiZc4-K9nRl4oYFCvnBYTnMmPGo=.874c0422-752a-4539-ba5d-11d144cd5207@github.com>

On Tue, 14 Oct 2025 12:49:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
>> 
>> Test: tier1-5
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27794#issuecomment-3414639309

From ayang at openjdk.org  Fri Oct 17 09:36:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 09:36:19 GMT
Subject: Integrated: 8369814: G1: Relax card mark and store ordering
In-Reply-To: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
References: <EDnDORgT-kvtBDkQpkU4yIkrJd_3ppfUDvKk6R6XOfE=.7b759053-651c-472b-87e4-15929db8d3ba@github.com>
Message-ID: <pqhUYGsNVyWhOctMkB619N-kZiI1c_keI-Do4zttaSA=.ed0670e9-1b90-42e0-b9f5-2a77e02f1e77@github.com>

On Tue, 14 Oct 2025 09:46:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> This PR removes the card-mark and store ordering constraint. The first commit changes `card_mark_must_follow_store` to `false` and the second commit removes all uses of `card_mark_must_follow_store`, because both the original method and its override are identical, and no GC have such ordering requirement any more.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: 0a97bef8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0a97bef840f8799313a1a55a65d9334e09cc1cf4
Stats:     123 lines in 11 files changed: 0 ins; 120 del; 3 mod

8369814: G1: Relax card mark and store ordering

Reviewed-by: tschatzl, fandreuzzi

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

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

From fandreuzzi at openjdk.org  Fri Oct 17 09:43:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 09:43:02 GMT
Subject: RFR: 8369980: Use ThreadsClaimTokenScope in ShenandoahThreadRoots
In-Reply-To: <cNfVZMtHNm425G20llq-u-RxhCW4r5XZCNHUT_vYwJA=.799860ff-eb5f-429d-8c1d-8ed0e9bc9da9@github.com>
References: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>
 <cNfVZMtHNm425G20llq-u-RxhCW4r5XZCNHUT_vYwJA=.799860ff-eb5f-429d-8c1d-8ed0e9bc9da9@github.com>
Message-ID: <OYSXQZDx5-m-A_CaX5uUXktJRBIGRUxAGRpjeWwwJWA=.0f0f62d8-6eba-4eee-add8-cb3be77c3e33@github.com>

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

>> The explicit usage of `Threads::change_thread_claim_token` and `Threads::assert_all_threads_claimed` in `ShenandoahThreadRoots` can be replaced with `ThreadsClaimTokenScope`.
>> 
>> Passes tier1, tier2, tier[1,2,3]_gc_shenandoah (fastdebug).
>
> Marked as reviewed by ayang (Reviewer).

Thanks for the review @albertnetymk and @earthling-amzn.

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

PR Comment: https://git.openjdk.org/jdk/pull/27845#issuecomment-3414666821

From duke at openjdk.org  Fri Oct 17 09:43:04 2025
From: duke at openjdk.org (duke)
Date: Fri, 17 Oct 2025 09:43:04 GMT
Subject: RFR: 8369980: Use ThreadsClaimTokenScope in ShenandoahThreadRoots
In-Reply-To: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>
References: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>
Message-ID: <Vbvjc1rnJU1PN5xZmNt-B79q95BlOupXLlI43k2rCFs=.665066f5-65e6-48ea-9db0-b1ba8754e6c7@github.com>

On Thu, 16 Oct 2025 11:02:50 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The explicit usage of `Threads::change_thread_claim_token` and `Threads::assert_all_threads_claimed` in `ShenandoahThreadRoots` can be replaced with `ThreadsClaimTokenScope`.
> 
> Passes tier1, tier2, tier[1,2,3]_gc_shenandoah (fastdebug).

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

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

PR Comment: https://git.openjdk.org/jdk/pull/27845#issuecomment-3414669462

From shade at openjdk.org  Fri Oct 17 09:50:13 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 17 Oct 2025 09:50:13 GMT
Subject: RFR: 8241066: Shenandoah: fix or cleanup SH::do_full_collection
In-Reply-To: <IgMaXYV81ctneiSvUVIqFN7ywN8etes_sfKuiPN6XVA=.ec47d4bd-7ef2-4806-8930-15bf60d983c1@github.com>
References: <IgMaXYV81ctneiSvUVIqFN7ywN8etes_sfKuiPN6XVA=.ec47d4bd-7ef2-4806-8930-15bf60d983c1@github.com>
Message-ID: <HudnPdd61tVr8fydq3iImuyPYxdhbjyMyrqdhlSyyrw=.49f290c7-25c4-4a58-8808-71f688ec30ac@github.com>

On Thu, 16 Oct 2025 19:02:16 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This `ShenandoahHeap::do_full_collection` will never be called by our implementation of `collect_as_vm_thread`.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27853#pullrequestreview-3349159907

From ayang at openjdk.org  Fri Oct 17 12:14:48 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 12:14:48 GMT
Subject: RFR: 8370078: Remove unnecessary argument in
 ContiguousSpace::initialize
Message-ID: <iw8cLbWMsVJxbcm8jkKnRc3Cp6bwrT0-OGZ49qS4Tck=.ccc3dcfe-c2e4-4603-88f2-74dd06c0873e@github.com>

Trivial "inlining" a statically know boolean value to a method.

Test: tier1

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

Commit messages:
 - remove-mangle-arg

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

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

From ayang at openjdk.org  Fri Oct 17 12:21:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 12:21:16 GMT
Subject: RFR: 8370079: Re-enable vmTestbase/gc/vector/CircularListLow and
 LinearListLow with SerialGC
Message-ID: <2SIVXgK0NdXQ1LeLbby-5ha5Kvelxjf53cVyMBeMfec=.fa3a7ec5-aefc-44e0-bae3-cda429bd2985@github.com>

Trivial re-enabling these two tests with SerialGC. I am leaving [JDK-8368191](https://bugs.openjdk.org/browse/JDK-8368191) open for now and plan to close it after monitoring CI for a while.

Test: 2K runs of the previously failing tests

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

Commit messages:
 - sgc-revert-skip

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

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

From fandreuzzi at openjdk.org  Fri Oct 17 13:44:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 13:44:02 GMT
Subject: RFR: 8370078: Remove unnecessary argument in
 ContiguousSpace::initialize
In-Reply-To: <iw8cLbWMsVJxbcm8jkKnRc3Cp6bwrT0-OGZ49qS4Tck=.ccc3dcfe-c2e4-4603-88f2-74dd06c0873e@github.com>
References: <iw8cLbWMsVJxbcm8jkKnRc3Cp6bwrT0-OGZ49qS4Tck=.ccc3dcfe-c2e4-4603-88f2-74dd06c0873e@github.com>
Message-ID: <K4GEG_eu9EovOxsN37kM4OAz5Av9nnR-ihras922ImY=.715362fd-f11a-4213-a1ff-080ee864e5b3@github.com>

On Fri, 17 Oct 2025 12:06:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial "inlining" a statically know boolean value to a method.
> 
> Test: tier1

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27865#pullrequestreview-3350430113

From gli at openjdk.org  Fri Oct 17 14:08:35 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Fri, 17 Oct 2025 14:08:35 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v3]
In-Reply-To: <dGQ6VndiO9WBhOK8dHP8C66QHZ4Iu85NxO5_91iv81g=.37755591-00b8-42e0-9d59-4952f6d0c18f@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
 <dGQ6VndiO9WBhOK8dHP8C66QHZ4Iu85NxO5_91iv81g=.37755591-00b8-42e0-9d59-4952f6d0c18f@github.com>
Message-ID: <dwAUkdQMOYJtVN_RBDT-IQcrQn10e5U3nC8ly4qbsKk=.355e6b91-4b2b-449f-8428-304007ec737e@github.com>

On Wed, 8 Oct 2025 11:56:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full.
>> 
>> This is needed only when `UseAdaptiveSizePolicy` is on, because this is intended to avoid including extra OS-time in gc-pause-time tracking, used for young-gen resizing.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - sizet
>  - Merge branch 'master' into pgc-os-free-mem
>  - Merge branch 'master' into pgc-os-free-mem
>  - review
>  - Merge branch 'master' into pgc-os-free-mem
>  - pgc-os-free-mem

The method `PSScavenge::should_attempt_scavenge` only judges whether it should run young GC. It is not a judgement of the full GC. So I think the literal constants `true` and `false` is better than `SHOULD_RUN_YOUNG_GC` and `SHOULD_RUN_FULL_GC`.

src/hotspot/share/gc/parallel/psScavenge.cpp line 525:

> 523: bool PSScavenge::should_attempt_scavenge() {
> 524:   const static bool SHOULD_RUN_YOUNG_GC = true;
> 525:   const static bool SHOULD_RUN_FULL_GC = false;

These two constants `SHOULD_RUN_YOUNG_GC` and `SHOULD_RUN_FULL_GC` do not seem to be `static`.

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

PR Review: https://git.openjdk.org/jdk/pull/27068#pullrequestreview-3350430158
PR Review Comment: https://git.openjdk.org/jdk/pull/27068#discussion_r2440074208

From fandreuzzi at openjdk.org  Fri Oct 17 14:22:16 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 17 Oct 2025 14:22:16 GMT
Subject: Integrated: 8369980: Use ThreadsClaimTokenScope in
 ShenandoahThreadRoots
In-Reply-To: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>
References: <GSN4sASOwHb2meFvZMz8Q6eErPXtHrYhpOKJwMOcLcs=.fa47f5d5-bf74-4202-9849-2fbe7cc3023e@github.com>
Message-ID: <8lsZJbG1d8-GGZdyXQiwtY4gWAWFreX4StEVakabmeU=.719eaec5-61d8-4a0c-ab68-ced40c990774@github.com>

On Thu, 16 Oct 2025 11:02:50 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> The explicit usage of `Threads::change_thread_claim_token` and `Threads::assert_all_threads_claimed` in `ShenandoahThreadRoots` can be replaced with `ThreadsClaimTokenScope`.
> 
> Passes tier1, tier2, tier[1,2,3]_gc_shenandoah (fastdebug).

This pull request has now been integrated.

Changeset: b159ca09
Author:    Francesco Andreuzzi <fandreuzzi at openjdk.org>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b159ca097a71407d0bc10f6c5d86d5f45c7d7642
Stats:     11 lines in 2 files changed: 2 ins; 5 del; 4 mod

8369980: Use ThreadsClaimTokenScope in ShenandoahThreadRoots

Reviewed-by: ayang, wkemper

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

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

From ayang at openjdk.org  Fri Oct 17 14:30:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 14:30:03 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v3]
In-Reply-To: <dGQ6VndiO9WBhOK8dHP8C66QHZ4Iu85NxO5_91iv81g=.37755591-00b8-42e0-9d59-4952f6d0c18f@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
 <dGQ6VndiO9WBhOK8dHP8C66QHZ4Iu85NxO5_91iv81g=.37755591-00b8-42e0-9d59-4952f6d0c18f@github.com>
Message-ID: <GkBdvOiRssoErisex0X03tMKgMzNlHBrgcQAjqrLf4g=.aede3760-6445-466d-8657-e1c4d8127219@github.com>

On Wed, 8 Oct 2025 11:56:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full.
>> 
>> This is needed only when `UseAdaptiveSizePolicy` is on, because this is intended to avoid including extra OS-time in gc-pause-time tracking, used for young-gen resizing.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - sizet
>  - Merge branch 'master' into pgc-os-free-mem
>  - Merge branch 'master' into pgc-os-free-mem
>  - review
>  - Merge branch 'master' into pgc-os-free-mem
>  - pgc-os-free-mem

> The method PSScavenge::should_attempt_scavenge only judges whether it should run young GC...

True, that's why I find that using a named bool is more explicit, especially now that this method is growing slightly lengthier.


bool PSScavenge::should_attempt_scavenge() {
  const static bool SHOULD_RUN_YOUNG_GC = true;

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

PR Review: https://git.openjdk.org/jdk/pull/27068#pullrequestreview-3350610759

From ayang at openjdk.org  Fri Oct 17 14:30:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 17 Oct 2025 14:30:06 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v3]
In-Reply-To: <dwAUkdQMOYJtVN_RBDT-IQcrQn10e5U3nC8ly4qbsKk=.355e6b91-4b2b-449f-8428-304007ec737e@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
 <dGQ6VndiO9WBhOK8dHP8C66QHZ4Iu85NxO5_91iv81g=.37755591-00b8-42e0-9d59-4952f6d0c18f@github.com>
 <dwAUkdQMOYJtVN_RBDT-IQcrQn10e5U3nC8ly4qbsKk=.355e6b91-4b2b-449f-8428-304007ec737e@github.com>
Message-ID: <s_zT4OPTvYOJ1PwS_sUAfak2LvbR3hYLakzla8tYUM8=.c3f8032a-b5c0-4153-b647-9e7ead257601@github.com>

On Fri, 17 Oct 2025 13:41:13 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - sizet
>>  - Merge branch 'master' into pgc-os-free-mem
>>  - Merge branch 'master' into pgc-os-free-mem
>>  - review
>>  - Merge branch 'master' into pgc-os-free-mem
>>  - pgc-os-free-mem
>
> src/hotspot/share/gc/parallel/psScavenge.cpp line 525:
> 
>> 523: bool PSScavenge::should_attempt_scavenge() {
>> 524:   const static bool SHOULD_RUN_YOUNG_GC = true;
>> 525:   const static bool SHOULD_RUN_FULL_GC = false;
> 
> These two constants `SHOULD_RUN_YOUNG_GC` and `SHOULD_RUN_FULL_GC` do not seem to be `static`.

It probably doesn't make any difference. I can drop `static` if you prefer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27068#discussion_r2440211140

From wkemper at openjdk.org  Fri Oct 17 16:57:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Oct 2025 16:57:13 GMT
Subject: Integrated: 8241066: Shenandoah: fix or cleanup SH::do_full_collection
In-Reply-To: <IgMaXYV81ctneiSvUVIqFN7ywN8etes_sfKuiPN6XVA=.ec47d4bd-7ef2-4806-8930-15bf60d983c1@github.com>
References: <IgMaXYV81ctneiSvUVIqFN7ywN8etes_sfKuiPN6XVA=.ec47d4bd-7ef2-4806-8930-15bf60d983c1@github.com>
Message-ID: <qFC0KmH-IugIemJ9gyLsoPrhJDU59v4vfrhDMacqMJA=.e739420a-6348-45e8-a0df-89f459076a22@github.com>

On Thu, 16 Oct 2025 19:02:16 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This `ShenandoahHeap::do_full_collection` will never be called by our implementation of `collect_as_vm_thread`.

This pull request has now been integrated.

Changeset: f84be36d
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f84be36dd59ae6b00aea334944b8266ecf8f5cbd
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

8241066: Shenandoah: fix or cleanup SH::do_full_collection

Reviewed-by: shade

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

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

From kdnilsen at openjdk.org  Fri Oct 17 17:20:19 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 17 Oct 2025 17:20:19 GMT
Subject: Integrated: 8368681: Shenandoah: Add documentation comments for
 ShenandoahAllocationRate
In-Reply-To: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
References: <X-CvPPN19w1A5KVuv0iSc30y3au9r9wHhuISQr7SeIY=.2fb56236-2070-4585-9cf8-b89b7aec7dc4@github.com>
Message-ID: <l5MMEtYs1wyDc8aS9bdax-B9H7MYlaLPqgf1Gc6gM9w=.5ee2efd3-f96c-4915-a90a-aeef690d3cd3@github.com>

On Thu, 25 Sep 2025 23:33:56 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Add documentation to ShenandoahAllocationRate

This pull request has now been integrated.

Changeset: a3e41ea6
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3e41ea6c60eb278da93dbc2daf940f0dc9abd11
Stats:     44 lines in 2 files changed: 44 ins; 0 del; 0 mod

8368681: Shenandoah: Add documentation comments for ShenandoahAllocationRate

Reviewed-by: wkemper, xpeng

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

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

From wkemper at openjdk.org  Fri Oct 17 17:43:15 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Oct 2025 17:43:15 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: <OPrn60sRirjjqGjXtAtJ2vGqr-SMkqG0siwFaaB19xU=.d8ab0757-af41-429a-b22b-cb86a5ce70bf@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.

If I understand correctly, the general issue is that `available` is not accurate when the freeset is being rebuilt. There are three solutions tested:
1. Existing code, returns a sentinel value (`SIZE_MAX`) during freeset rebuilt
2. Return the last known value of `available` during the rebuild (this appears to cause more aggressive heuristics)
3. Block threads that call `available` during rebuild

As it stands, only the regulator thread (which is evaluating heuristics for genshen) will call `available` during a free set rebuild (though this may change in the future). With the first solution, it seems we would have the heuristics believe there is much more memory available than there actually is. This would risk the heuristic not triggering when it should?

It makes sense that option `2` would trigger more GCs than option `1`, but it seems the risk of triggering too late would be lower here. Option `3` might also delay triggering, but at least the heuristic would base the trigger decision on an accurate accounting of available memory.

If we go with the third option, I think we should move the lock management into the freeset and not have to change existing callers.


void ShenandoahFreeSet::prepare_to_rebuild(...) {
  _lock.lock();
  // do preparation
  // ...
}

void ShenandoahFreeSet::finish_rebuild(...) {
  // finish rebuild
  // ...
  _lock.unlock();
}


Could we also now remove the sentinel value (`FreeSetUnderConstruction`)?

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27612#pullrequestreview-3351287418

From ysr at openjdk.org  Fri Oct 17 22:19:00 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 17 Oct 2025 22:19:00 GMT
Subject: RFR: 8369447: GenShen: Regulator thread may observe inconsistent
 states
In-Reply-To: <5Qa66lljxDIXH8mOo9oyCZTDjZ2OyhgHsurqkfKKhGY=.a784a918-bb7b-4a86-bad6-195ee1800650@github.com>
References: <5Qa66lljxDIXH8mOo9oyCZTDjZ2OyhgHsurqkfKKhGY=.a784a918-bb7b-4a86-bad6-195ee1800650@github.com>
Message-ID: <ggHyNFygnOU9jUUudr4YMYEu1K7IcJzXA654vHZzVj4=.58b66d3e-b569-4900-9dc8-be52b69689c1@github.com>

On Wed, 8 Oct 2025 18:46:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah's generational mode runs a separate thread to monitor the heap during old collections. This thread is responsible for deciding to start collections. When the thread which actually runs collections (the control thread) changes the state of various gc components _on a safepoint_, it has the expectation that these changes will become visible to mutator threads atomically, and consistently. However, the regulator thread does not participate in safepoints and may observe gc components in inconsistent states and so make incorrect choices about trying to start GC cycles.
> 
> For example:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp:625), pid=3796044, tid=3796163
> # assert(_old_generation->state() == ShenandoahOldGeneration::MARKING) failed: Unexpected old gen state: Waiting for Bootstrap
> #
> 
> The solution here is to make the regulator thread participate in safepoints. There is no need for it to run during a safepoint.

Nice! ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27702#pullrequestreview-3352286714

From ysr at openjdk.org  Fri Oct 17 23:01:07 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 17 Oct 2025 23:01:07 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
Message-ID: <vqpRsU0fXWisQQviCpkyGVN_rmbLwo0sBEUVEetEArA=.6d25ab78-2da2-4f83-897c-2258da44626c@github.com>

On Tue, 14 Oct 2025 23:03:16 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are certain code paths in Shenandoah's generational mode that need to _know_ which generation is being collected, but it is not possible to pass this information on the stack (barriers, for example). To address this, we introduced an `_active_generation` member in `ShenandoahHeap`. Over time, the usage of this field grew beyond its intended purpose and we began to have issues where not all threads would see a consistent value for this field. To address _this_ issue, we added another field `_gc_generation` which was only meant to be used by GC threads. At this point, we have three different ways to determine which generation is being collected: the _active_ generation, the _gc_ generation, and the usual function parameters and member fields of the gc components. This PR removes `_gc_generation` and reduces the use of `_active_generation` to only those places where it is not possible to get this information from other means (barriers, mostly). All GC components that can have t
 his information passed through function calls, now do so.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Remove _gc_generation from ShenandoahHeap
>  - Little cleanup, remove one active generation usage
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>  - Fix build
>  - Use existing _generation field instead of Heap::_gc_generation where possible
>  - Only shenandoah vm operations participate in active/gc generation scheme

@earthling-amzn : is it possible to add the stack retrace and the test that elicited the assertion failure to the ticket as an archival forensic trail?

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

PR Comment: https://git.openjdk.org/jdk/pull/27703#issuecomment-3417455849

From wkemper at openjdk.org  Fri Oct 17 23:53:12 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 17 Oct 2025 23:53:12 GMT
Subject: Integrated: 8369447: GenShen: Regulator thread may observe
 inconsistent states
In-Reply-To: <5Qa66lljxDIXH8mOo9oyCZTDjZ2OyhgHsurqkfKKhGY=.a784a918-bb7b-4a86-bad6-195ee1800650@github.com>
References: <5Qa66lljxDIXH8mOo9oyCZTDjZ2OyhgHsurqkfKKhGY=.a784a918-bb7b-4a86-bad6-195ee1800650@github.com>
Message-ID: <LVKmjwFG2jW6qICTrTFjGOtA6X_P00Ox0sI5WfAPALc=.be2b996d-4aca-477e-a6e8-77934de0ffd7@github.com>

On Wed, 8 Oct 2025 18:46:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah's generational mode runs a separate thread to monitor the heap during old collections. This thread is responsible for deciding to start collections. When the thread which actually runs collections (the control thread) changes the state of various gc components _on a safepoint_, it has the expectation that these changes will become visible to mutator threads atomically, and consistently. However, the regulator thread does not participate in safepoints and may observe gc components in inconsistent states and so make incorrect choices about trying to start GC cycles.
> 
> For example:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp:625), pid=3796044, tid=3796163
> # assert(_old_generation->state() == ShenandoahOldGeneration::MARKING) failed: Unexpected old gen state: Waiting for Bootstrap
> #
> 
> The solution here is to make the regulator thread participate in safepoints. There is no need for it to run during a safepoint.

This pull request has now been integrated.

Changeset: 926f61f2
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/926f61f2e358c92cdb7ccdf75c853aa599f4dde3
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8369447: GenShen: Regulator thread may observe inconsistent states

Reviewed-by: kdnilsen, ysr

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

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

From wkemper at openjdk.org  Sat Oct 18 00:22:03 2025
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 18 Oct 2025 00:22:03 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <vqpRsU0fXWisQQviCpkyGVN_rmbLwo0sBEUVEetEArA=.6d25ab78-2da2-4f83-897c-2258da44626c@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
 <vqpRsU0fXWisQQviCpkyGVN_rmbLwo0sBEUVEetEArA=.6d25ab78-2da2-4f83-897c-2258da44626c@github.com>
Message-ID: <qo3YsyvgxancO9qmGVLmEHASh8MaVD0FBVwbdRmtKKI=.2b6cbef9-ba6e-4491-9363-41f4576d96bf@github.com>

On Fri, 17 Oct 2025 22:58:20 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Remove _gc_generation from ShenandoahHeap
>>  - Little cleanup, remove one active generation usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>>  - Fix build
>>  - Use existing _generation field instead of Heap::_gc_generation where possible
>>  - Only shenandoah vm operations participate in active/gc generation scheme
>
> @earthling-amzn : is it possible to add the stack retrace and the test that elicited the assertion failure to the ticket as an archival forensic trail?

@ysramakrishna - Aye, the original, linked ticket has the stack traces and logs: https://bugs.openjdk.org/browse/JDK-8365792. Also a description of our original understanding of the problem in this PR: https://github.com/openjdk/jdk/pull/27373. That understanding is still valid, it's just that `ShenandoahSafepoint::is_at_shenandoah_safepoint` lies when it is called from a concurrent worker thread.

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

PR Comment: https://git.openjdk.org/jdk/pull/27703#issuecomment-3417557209

From gli at openjdk.org  Sat Oct 18 08:03:01 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 18 Oct 2025 08:03:01 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v3]
In-Reply-To: <s_zT4OPTvYOJ1PwS_sUAfak2LvbR3hYLakzla8tYUM8=.c3f8032a-b5c0-4153-b647-9e7ead257601@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
 <dGQ6VndiO9WBhOK8dHP8C66QHZ4Iu85NxO5_91iv81g=.37755591-00b8-42e0-9d59-4952f6d0c18f@github.com>
 <dwAUkdQMOYJtVN_RBDT-IQcrQn10e5U3nC8ly4qbsKk=.355e6b91-4b2b-449f-8428-304007ec737e@github.com>
 <s_zT4OPTvYOJ1PwS_sUAfak2LvbR3hYLakzla8tYUM8=.c3f8032a-b5c0-4153-b647-9e7ead257601@github.com>
Message-ID: <_J0RmxZ5DFZpbY5kt1sc86IKKWNQh2iNl8oXQLh_Xjc=.7c9e2df2-afc2-492f-af12-b497c35a9b71@github.com>

On Fri, 17 Oct 2025 14:24:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/psScavenge.cpp line 525:
>> 
>>> 523: bool PSScavenge::should_attempt_scavenge() {
>>> 524:   const static bool SHOULD_RUN_YOUNG_GC = true;
>>> 525:   const static bool SHOULD_RUN_FULL_GC = false;
>> 
>> These two constants `SHOULD_RUN_YOUNG_GC` and `SHOULD_RUN_FULL_GC` do not seem to be `static`.
>
> It probably doesn't make any difference. I can drop `static` if you prefer.

Generally, the `static` variables in a method are used to save the state of the previous invocation and then used by the following invocations. But we only need a named constant here. So I think it is better to remove the keyword `static`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27068#discussion_r2441759268

From gli at openjdk.org  Sat Oct 18 08:34:00 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 18 Oct 2025 08:34:00 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v3]
In-Reply-To: <GkBdvOiRssoErisex0X03tMKgMzNlHBrgcQAjqrLf4g=.aede3760-6445-466d-8657-e1c4d8127219@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
 <dGQ6VndiO9WBhOK8dHP8C66QHZ4Iu85NxO5_91iv81g=.37755591-00b8-42e0-9d59-4952f6d0c18f@github.com>
 <GkBdvOiRssoErisex0X03tMKgMzNlHBrgcQAjqrLf4g=.aede3760-6445-466d-8657-e1c4d8127219@github.com>
Message-ID: <uR7mE8pu_S5OpqtM8w8Phrb1T8y9YDN-kQkSpTC8Mgs=.48ac756f-5a82-4e6f-bb65-623069422789@github.com>

On Fri, 17 Oct 2025 14:27:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > The method PSScavenge::should_attempt_scavenge only judges whether it should run young GC...
> 
> True, that's why I find that using a named bool is more explicit, especially now that this method is growing slightly lengthier.

It seems more like a code style problem. So I am not strict with this problem now.

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

PR Comment: https://git.openjdk.org/jdk/pull/27068#issuecomment-3417995061

From ayang at openjdk.org  Sat Oct 18 10:13:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 18 Oct 2025 10:13:42 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v4]
In-Reply-To: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
Message-ID: <V5ulPuZRXgs4uuwlaNE98o91zRpHekWYovIWBj05RPY=.6937bf54-8777-4b55-8422-8d6d8a8e79cc@github.com>

> Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full.
> 
> This is needed only when `UseAdaptiveSizePolicy` is on, because this is intended to avoid including extra OS-time in gc-pause-time tracking, used for young-gen resizing.
> 
> Test: tier1-3

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

 - Merge branch 'master' into pgc-os-free-mem
 - review
 - sizet
 - Merge branch 'master' into pgc-os-free-mem
 - Merge branch 'master' into pgc-os-free-mem
 - review
 - Merge branch 'master' into pgc-os-free-mem
 - pgc-os-free-mem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27068/files
  - new: https://git.openjdk.org/jdk/pull/27068/files/2267e5c0..affa0435

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

  Stats: 26018 lines in 655 files changed: 15588 ins; 7978 del; 2452 mod
  Patch: https://git.openjdk.org/jdk/pull/27068.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27068/head:pull/27068

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

From kdnilsen at openjdk.org  Sat Oct 18 22:23:30 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 18 Oct 2025 22:23:30 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v26]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <QbzCAAhUDNK-CEQXBFx6ZZt9C5LEvatjMdwdCsCN4Rg=.0f7f2c4d-7acf-4d03-b1c8-725ffa214877@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:

  After initialization, check for SoftMaxHeapSize changed by constraints enforcement

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/9b36ee38..891e96b8

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 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 azafari at openjdk.org  Mon Oct 20 07:37:07 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 20 Oct 2025 07:37:07 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: <ULP4C2zdfAlLsafjiTtVynzIGrlsWCaZPl5ZHfmmyPE=.02b40dc3-8b20-4ad6-a6df-30a4d37860c9@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

It seems that this PR is diverging in some (un)related changes. I suggest to define separate new RFEs per issues found here.

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

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3420919024

From azafari at openjdk.org  Mon Oct 20 07:37:10 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 20 Oct 2025 07:37:10 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <o7O0MNu6ATtffPBmT7ITE4GhNCvmu0YCxl-exqxBj1I=.8aebc999-430f-468a-a9e4-93e20caca650@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
 <o7O0MNu6ATtffPBmT7ITE4GhNCvmu0YCxl-exqxBj1I=.8aebc999-430f-468a-a9e4-93e20caca650@github.com>
Message-ID: <1p0PZb6EijjJFhDHDraj1Xh522GehuN9XifO-rReyMw=.ab35fbf1-a00f-4218-9780-1b38f83a0291@github.com>

On Thu, 9 Oct 2025 01:55:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed MAX2 template parameter
>
> src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288:
> 
>> 286:   // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value.
>> 287:   // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx.
>> 288:   if (value + MaxHeapSize < MaxHeapSize) { // overflow
> 
> Sorry I am struggling to see how this check differs in practice to the existing check:
> 
> (value > (max_uintx - MaxHeapSize))
> 
> Further, the comment before the new check seems to relate to the existing check.

Sorry it's my mistake in reading `max - a < b` as `a - b < b` .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2444032200

From azafari at openjdk.org  Mon Oct 20 07:54:40 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Mon, 20 Oct 2025 07:54:40 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v8]
In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
Message-ID: <cqcQvTn_HuW6vnkLDhzL7NOzJD9n6VrnFf2ylbIrhlo=.4646b21f-0195-4884-8c7f-c1dd4d6b2526@github.com>

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

  subtraction for checking overflow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26955/files
  - new: https://git.openjdk.org/jdk/pull/26955/files/3dfa9765..d0300291

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

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

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

From sjohanss at openjdk.org  Mon Oct 20 08:38:07 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Mon, 20 Oct 2025 08:38:07 GMT
Subject: RFR: 8369811: ZGC: Robust NUMA configuration detection
In-Reply-To: <pH6e0bshfOmdZULA7ptGBLeCKtW7NxDmc1zEuS8_jqo=.be5a1b6f-2d7c-4c08-a900-67f9c8442bb8@github.com>
References: <pH6e0bshfOmdZULA7ptGBLeCKtW7NxDmc1zEuS8_jqo=.be5a1b6f-2d7c-4c08-a900-67f9c8442bb8@github.com>
Message-ID: <tO1RnyLKZzhKVuQetHzYUD2Squtf0Z3NE2EEhIl8V7k=.b334524f-f6b9-4390-a5bb-c481f3eead7e@github.com>

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

> Hello,
> 
> When page allocation was overhauled in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), NUMA support in ZGC was also significantly overhauled. The concept of a partition was introduced as a one-to-one mapping between NUMA nodes and a subset of the Java heap. The number of partitions is ideally the same number of NUMA nodes the Java process is bound to use.
> 
> Using ZGC and binding the Java process to only use a subset of the available NUMA nodes on a system with more than 2 NUMA nodes, there will be a mismatch between the internal representation and the configured one. The internal representation ends up having as many partitions as there are NUMA nodes on the system, not how many NUMA nodes the Java process will actually use.
> 
> To solve this, we create a mapping between what we refer to as "NUMA id" and "NUMA node", where NUMA id is the internal representation, i.e., the id of a partition, and the NUMA node is the actual NUMA node memory is allocated on. The mapping is used to translate between the two when syscalls are made, so that the internal representation always works with NUMA ids and syscalls work with the actual, or desired, NUMA node.
> 
> Before:
> 
> $ numactl --cpunodebind=0,2 --membind=0,2 ./jdk-25/bin/java -Xms200M -Xmx200M -XX:+AlwaysPretouch -XX:+UseZGC -Xlog:gc+init Forever.java
> [0.236s][info][gc,init] NUMA Support: Enabled
> [0.237s][info][gc,init] NUMA Nodes: 4
> 
> $ cat /proc/$(pidof java)/numa_maps | grep java_heap
> 40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N0=12800 kernelpagesize_kB=4
> 401f1000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N1=12800 kernelpagesize_kB=4
> 403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N2=12800 kernelpagesize_kB=4
> 405d3000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N3=12800 kernelpagesize_kB=4
> 
> 
> After:
> 
> $ numactl --cpunodebind=0,2 --membind=0,2 ./jdk/bin/java -Xms200M -Xmx200M -XX:+AlwaysPreTouch -XX:+UseZGC -Xlog:gc+init Forever.java
> [0.236s][info][gc,init] NUMA Support: Enabled
> [0.237s][info][gc,init] NUMA Nodes: 2
> 
> $ cat /proc/$(pidof java)/numa_maps | grep java_heap
> 40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N0=25600 kernelpagesize_kB=4
> 403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N2=25600 kernelpagesize_kB=4
> 
> 
> Testing:
> * Functional testing on a QEMU VM with 4 NUMA nodes
> * Oracle's tier1-2 on a NUMA system with 2 NUMA nodes ...

Looks good!

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

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27792#pullrequestreview-3355489269

From iwalulya at openjdk.org  Mon Oct 20 10:29:04 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 20 Oct 2025 10:29:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>
Message-ID: <69b0xF_paR2o1C9IPIVZv144v47w2SE3KD8epKGQ1wE=.d4a35d76-4145-47ee-b0e9-581a0acdb70d@github.com>

On Sun, 19 Oct 2025 18:41:56 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> There may be two issues with the patch as is:
> 
> Calling `GetTotalGCCpuTime` in `Agent_OnLoad` can cause crash (since `CollectedHeap::gc_threads_do` do not protect against races on VM startup/shutdown).
> 
> If `GetTotalGCCpuTime` is invoked in a callback for GC start/end, this will cause a deadlock as the `Heap_lock` is already held. The `MutexLocker hl(Heap_lock)` pattern was introduced to avoid races that could happen from internal usage in G1 of `CPUTimeUsage::GC::total()` during shutdown. I could recall this wrong but I think the usage `Heap_lock` (which evidently has uses in other places) is an optimization to avoid having to create a new mutex shutdown variable. I could be wrong but it is maybe possible that this deadlock would be resolved by introducing a new mutex only used for syncing on the state of `Universe::_is_shutting_down`. I will ask @walulyai for his thoughts.

Right, there will be a deadlock if `GetTotalGCCpuTime` is called in the callbacks for events `GarbageCollectionStart`, `GarbageCollectionFinish`

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3421476400

From jsikstro at openjdk.org  Mon Oct 20 10:32:20 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 20 Oct 2025 10:32:20 GMT
Subject: RFR: 8369811: ZGC: Robust NUMA configuration detection
In-Reply-To: <ZKYtk3GKPrM25-m5sgXxwgP-rHDqXGYaAmcDeIMPv4g=.d6da946e-9306-4aca-a808-391b8a877ae9@github.com>
References: <pH6e0bshfOmdZULA7ptGBLeCKtW7NxDmc1zEuS8_jqo=.be5a1b6f-2d7c-4c08-a900-67f9c8442bb8@github.com>
 <ZKYtk3GKPrM25-m5sgXxwgP-rHDqXGYaAmcDeIMPv4g=.d6da946e-9306-4aca-a808-391b8a877ae9@github.com>
Message-ID: <3a_xOWRTSgbrMmBMpMYf9MTwLxHd0Ng0Tti-UOha_sk=.3abadfdb-f20d-468a-99c6-d1418d7997d2@github.com>

On Tue, 14 Oct 2025 11:41:18 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Hello,
>> 
>> When page allocation was overhauled in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), NUMA support in ZGC was also significantly overhauled. The concept of a partition was introduced as a one-to-one mapping between NUMA nodes and a subset of the Java heap. The number of partitions is ideally the same number of NUMA nodes the Java process is bound to use.
>> 
>> Using ZGC and binding the Java process to only use a subset of the available NUMA nodes on a system with more than 2 NUMA nodes, there will be a mismatch between the internal representation and the configured one. The internal representation ends up having as many partitions as there are NUMA nodes on the system, not how many NUMA nodes the Java process will actually use.
>> 
>> To solve this, we create a mapping between what we refer to as "NUMA id" and "NUMA node", where NUMA id is the internal representation, i.e., the id of a partition, and the NUMA node is the actual NUMA node memory is allocated on. The mapping is used to translate between the two when syscalls are made, so that the internal representation always works with NUMA ids and syscalls work with the actual, or desired, NUMA node.
>> 
>> Before:
>> 
>> $ numactl --cpunodebind=0,2 --membind=0,2 ./jdk-25/bin/java -Xms200M -Xmx200M -XX:+AlwaysPretouch -XX:+UseZGC -Xlog:gc+init Forever.java
>> [0.236s][info][gc,init] NUMA Support: Enabled
>> [0.237s][info][gc,init] NUMA Nodes: 4
>> 
>> $ cat /proc/$(pidof java)/numa_maps | grep java_heap
>> 40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N0=12800 kernelpagesize_kB=4
>> 401f1000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N1=12800 kernelpagesize_kB=4
>> 403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N2=12800 kernelpagesize_kB=4
>> 405d3000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N3=12800 kernelpagesize_kB=4
>> 
>> 
>> After:
>> 
>> $ numactl --cpunodebind=0,2 --membind=0,2 ./jdk/bin/java -Xms200M -Xmx200M -XX:+AlwaysPreTouch -XX:+UseZGC -Xlog:gc+init Forever.java
>> [0.236s][info][gc,init] NUMA Support: Enabled
>> [0.237s][info][gc,init] NUMA Nodes: 2
>> 
>> $ cat /proc/$(pidof java)/numa_maps | grep java_heap
>> 40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N0=25600 kernelpagesize_kB=4
>> 403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N2=25600 kernelpagesize_kB=4
>> 
>> 
>> Testing:
>> * Functional testing on a QEMU VM with...
>
> lgtm. 
> 
> Unfortunate that `numa_get_leaf_groups` has the signature it does requiring this `int -> uint -> int` type juggling. 
> 
> Maybe we can improve that in the future. And even create a more explicit type system in our os numa layer so we are less likely to introduce similar bugs in the future.

Thank you for the reviews! @xmas92 @kstefanj

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

PR Comment: https://git.openjdk.org/jdk/pull/27792#issuecomment-3421483087

From jsikstro at openjdk.org  Mon Oct 20 10:32:21 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 20 Oct 2025 10:32:21 GMT
Subject: Integrated: 8369811: ZGC: Robust NUMA configuration detection
In-Reply-To: <pH6e0bshfOmdZULA7ptGBLeCKtW7NxDmc1zEuS8_jqo=.be5a1b6f-2d7c-4c08-a900-67f9c8442bb8@github.com>
References: <pH6e0bshfOmdZULA7ptGBLeCKtW7NxDmc1zEuS8_jqo=.be5a1b6f-2d7c-4c08-a900-67f9c8442bb8@github.com>
Message-ID: <_93QL4-zfn49cIe16VSTDG2rzQIZ7PvBUl5XC9j_3Cc=.77b38e39-83e8-4b64-9ee3-245184a8fb60@github.com>

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

> Hello,
> 
> When page allocation was overhauled in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441), NUMA support in ZGC was also significantly overhauled. The concept of a partition was introduced as a one-to-one mapping between NUMA nodes and a subset of the Java heap. The number of partitions is ideally the same number of NUMA nodes the Java process is bound to use.
> 
> Using ZGC and binding the Java process to only use a subset of the available NUMA nodes on a system with more than 2 NUMA nodes, there will be a mismatch between the internal representation and the configured one. The internal representation ends up having as many partitions as there are NUMA nodes on the system, not how many NUMA nodes the Java process will actually use.
> 
> To solve this, we create a mapping between what we refer to as "NUMA id" and "NUMA node", where NUMA id is the internal representation, i.e., the id of a partition, and the NUMA node is the actual NUMA node memory is allocated on. The mapping is used to translate between the two when syscalls are made, so that the internal representation always works with NUMA ids and syscalls work with the actual, or desired, NUMA node.
> 
> Before:
> 
> $ numactl --cpunodebind=0,2 --membind=0,2 ./jdk-25/bin/java -Xms200M -Xmx200M -XX:+AlwaysPretouch -XX:+UseZGC -Xlog:gc+init Forever.java
> [0.236s][info][gc,init] NUMA Support: Enabled
> [0.237s][info][gc,init] NUMA Nodes: 4
> 
> $ cat /proc/$(pidof java)/numa_maps | grep java_heap
> 40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N0=12800 kernelpagesize_kB=4
> 401f1000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N1=12800 kernelpagesize_kB=4
> 403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N2=12800 kernelpagesize_kB=4
> 405d3000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=12800 active=0 N3=12800 kernelpagesize_kB=4
> 
> 
> After:
> 
> $ numactl --cpunodebind=0,2 --membind=0,2 ./jdk/bin/java -Xms200M -Xmx200M -XX:+AlwaysPreTouch -XX:+UseZGC -Xlog:gc+init Forever.java
> [0.236s][info][gc,init] NUMA Support: Enabled
> [0.237s][info][gc,init] NUMA Nodes: 2
> 
> $ cat /proc/$(pidof java)/numa_maps | grep java_heap
> 40000000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N0=25600 kernelpagesize_kB=4
> 403e2000000 bind:0,2 file=/memfd:java_heap\040(deleted) dirty=25600 active=0 N2=25600 kernelpagesize_kB=4
> 
> 
> Testing:
> * Functional testing on a QEMU VM with 4 NUMA nodes
> * Oracle's tier1-2 on a NUMA system with 2 NUMA nodes ...

This pull request has now been integrated.

Changeset: 73923601
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73923601d8db9032b904cabb18b16a8cb9dd76c1
Stats:     49 lines in 6 files changed: 40 ins; 0 del; 9 mod

8369811: ZGC: Robust NUMA configuration detection

Co-authored-by: Axel Boldt-Christmas <aboldtch at openjdk.org>
Reviewed-by: aboldtch, sjohanss

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

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

From tschatzl at openjdk.org  Mon Oct 20 12:37:25 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 20 Oct 2025 12:37:25 GMT
Subject: RFR: 8370079: Re-enable vmTestbase/gc/vector/CircularListLow and
 LinearListLow with SerialGC
In-Reply-To: <2SIVXgK0NdXQ1LeLbby-5ha5Kvelxjf53cVyMBeMfec=.fa3a7ec5-aefc-44e0-bae3-cda429bd2985@github.com>
References: <2SIVXgK0NdXQ1LeLbby-5ha5Kvelxjf53cVyMBeMfec=.fa3a7ec5-aefc-44e0-bae3-cda429bd2985@github.com>
Message-ID: <LgZcIwfn90bIucgpqDQFJePH2axaax4LJJ-rEngzZbA=.2ae53bf5-e28d-4d09-969a-eb9fc6978847@github.com>

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

> Trivial re-enabling these two tests with SerialGC. I am leaving [JDK-8368191](https://bugs.openjdk.org/browse/JDK-8368191) open for now and plan to close it after monitoring CI for a while.
> 
> Test: 2K runs of the previously failing tests

Trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27866#pullrequestreview-3356301501

From ayang at openjdk.org  Mon Oct 20 12:54:03 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Oct 2025 12:54:03 GMT
Subject: RFR: 8370234: Remove CardTableBarrierSet::write_region
Message-ID: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>

Trivial removing effectively dead code.

Test: tier1

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

Commit messages:
 - g1-barrier-set-remove

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

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

From fandreuzzi at openjdk.org  Mon Oct 20 13:49:30 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 20 Oct 2025 13:49:30 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v13]
In-Reply-To: <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@github.com>
Message-ID: <D_Ah6omZiPARUgiYuDI-o5zqM_itAQeTx5HlsgECI4I=.f67660d4-b017-49d6-a7b2-74ff0b951a69@github.com>

On Tue, 14 Oct 2025 13:35:12 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 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - review
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/11529ad9...273c2003

Marked as reviewed by fandreuzzi (Author).

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

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

From tschatzl at openjdk.org  Mon Oct 20 14:45:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 20 Oct 2025 14:45:38 GMT
Subject: RFR: 8370234: Remove CardTableBarrierSet::write_region
In-Reply-To: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
References: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
Message-ID: <4Mo8I0J2KxQfnytZoe8uXRlkeIQBes1V2gRtdqjIoPs=.b6b52655-45fa-48a8-a0ed-a0706a4f08ba@github.com>

On Mon, 20 Oct 2025 12:41:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing effectively dead code.
> 
> Test: tier1

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27898#pullrequestreview-3356754224

From fandreuzzi at openjdk.org  Mon Oct 20 15:12:11 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Mon, 20 Oct 2025 15:12:11 GMT
Subject: RFR: 8370234: Remove CardTableBarrierSet::write_region
In-Reply-To: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
References: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
Message-ID: <e5hQT6OWedxZdJaCr955V5uI-JctpMSbXcZR9UaOL1Q=.dfc15ac0-7e63-4d07-986a-425a4e4fd2e6@github.com>

On Mon, 20 Oct 2025 12:41:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing effectively dead code.
> 
> Test: tier1

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27898#pullrequestreview-3356854629

From ayang at openjdk.org  Mon Oct 20 15:24:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Oct 2025 15:24:14 GMT
Subject: RFR: 8370079: Re-enable vmTestbase/gc/vector/CircularListLow and
 LinearListLow with SerialGC
In-Reply-To: <2SIVXgK0NdXQ1LeLbby-5ha5Kvelxjf53cVyMBeMfec=.fa3a7ec5-aefc-44e0-bae3-cda429bd2985@github.com>
References: <2SIVXgK0NdXQ1LeLbby-5ha5Kvelxjf53cVyMBeMfec=.fa3a7ec5-aefc-44e0-bae3-cda429bd2985@github.com>
Message-ID: <elLbhNM7S9ojciYZf6Gik4-7iR5QqhpnIf9eSNfV0XU=.cf3a09fe-f4f3-42e2-abc8-f7218e22a8dc@github.com>

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

> Trivial re-enabling these two tests with SerialGC. I am leaving [JDK-8368191](https://bugs.openjdk.org/browse/JDK-8368191) open for now and plan to close it after monitoring CI for a while.
> 
> Test: 2K runs of the previously failing tests

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27866#issuecomment-3422556901

From ayang at openjdk.org  Mon Oct 20 15:24:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 20 Oct 2025 15:24:15 GMT
Subject: Integrated: 8370079: Re-enable vmTestbase/gc/vector/CircularListLow
 and LinearListLow with SerialGC
In-Reply-To: <2SIVXgK0NdXQ1LeLbby-5ha5Kvelxjf53cVyMBeMfec=.fa3a7ec5-aefc-44e0-bae3-cda429bd2985@github.com>
References: <2SIVXgK0NdXQ1LeLbby-5ha5Kvelxjf53cVyMBeMfec=.fa3a7ec5-aefc-44e0-bae3-cda429bd2985@github.com>
Message-ID: <hzTFf4IK3Mjj8hx-UGo76llHlgpHT6N1-cuF2Blddl4=.9626a6de-d13a-47e6-9b5a-68eaa874d163@github.com>

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

> Trivial re-enabling these two tests with SerialGC. I am leaving [JDK-8368191](https://bugs.openjdk.org/browse/JDK-8368191) open for now and plan to close it after monitoring CI for a while.
> 
> Test: 2K runs of the previously failing tests

This pull request has now been integrated.

Changeset: 257bb2b2
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/257bb2b279771c80c4847d4cb2fa7e3518192585
Stats:     2 lines in 2 files changed: 0 ins; 2 del; 0 mod

8370079: Re-enable vmTestbase/gc/vector/CircularListLow and LinearListLow with SerialGC

Reviewed-by: tschatzl

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

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

From sspitsyn at openjdk.org  Mon Oct 20 18:29:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 18:29:05 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <Kjr97B0c7Zct7rbCyDEGOu4qJjEhqMWgwZqojDVMY1Q=.62182532-f9be-4968-829a-a48d8f9282f7@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

> I'm not sure this functionality is really JVMTI worthy but if Jonas thinks this is useful for GC profiling then I will take his word for it.

Yes. I asked Jonas about it when we started our conversation and I rely on his justification which is in the enhancement description.

> This seems to contradict the description that it could be relative to a value in the future and hence negative - thus it can't be "unsigned". But then I don't see how it can be as described - for this timer to be useful it must be tracking nanoseconds of CPU time consumed by GC since CPU time tracking commenced, sometime after VM startup. This has to be similar to how thread CPU time is defined.

Good catch, thanks. Fixed now.

> Also the hex value represents JDK 23 not 25.

Good catch, thanks. Fixed now.

> If it isn't supported then you can't have the capability and so won't reach here.

Good comment. In fact, I've already made a decision to move this to the capability check. But it seems, it also needs to be fixed this way for `GetCurrentThreadCpuTime()` and `GetThreadCpuTime()`.

>> +       Universe::heap()->is_shutting_down()) {
>> +       *nanos_ptr = -1;
> 
> This seems wrong to me and violates the timer-info spec of this timer not jumping backwards. I think you have to cache the last returned value for this function and if you cannot calculate an updated value because of VM shutdown, then that previous value should be returned.

I agree. I've already noticed this issue and was thinking where and how to fix it. Thank you for the suggestion. It can be fixed this way but I feel it is better to fix on the GC side. Will discuss it with Jonas.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423268108

From sspitsyn at openjdk.org  Mon Oct 20 19:04:04 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 19:04:04 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
 <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
Message-ID: <_dyneYvZ5cJjriz-Mt1woRWD4LfgppeF2dJybclDo2I=.3049be57-dccd-4378-876c-b7780bf8c1f7@github.com>

On Sun, 19 Oct 2025 15:37:22 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Would it be possible to expand a bit on this, specifically how it might be used, and whether it might be used with other JVMTI functions (there aren't functions to get the process CPU time for example).

Alan, thank you for looking at this, the comments and good questions. I agree, we need to look at some level of completeness here. It includes the process CPU time and potentially more functionality to support modern GC's (I hope to get more insight from the GC team here). One question I've got is about all these timers and a possibility to reuse some of them. Is it right to have new timer for each CPU metric? We need some kind of overall design for all this. As I've posted earlier in reply to David for this enhancement, I rely on Jonas's justification which is in the enhancement description.

> As a general point, the JVMTI spec doesn't have much support for monitoring GC. It has GC start/end events that date from the original spec when collectors were all STW and it hasn't evolved since to model more modern collectors.

Yes, support for modern collectors is on the table for some time.  Now seems to be a good time to make some steps in this direction.

> I'm sure CPU time spend on GC is important to many profilers but I'm also wondering if JVMTI is the right API for modern profilers to be using. JVMTI is suited to debuggers and other tooling but it's less clear that it is relevant for profiling now.

I hope, Jonas has answered this.

> (in passing, I see GetAvailableProcessors is in the Timers section of the spec, is that the right place for this?)

Yes, it seems this function is a little bit out of this section scope. But I do not see a better section for this, and it does not deserve its own section yet. :)

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423360087

From sspitsyn at openjdk.org  Mon Oct 20 19:17:05 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 19:17:05 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
Message-ID: <-xJ-7eFcpzLYfOtrQlhE9ejmcwz1WM7FplEQtmTCADc=.2ec0d270-3e7f-4862-8967-1aa245bf5c5a@github.com>

On Sat, 18 Oct 2025 00:56:25 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
>> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
>> The following API's are being added with this enhancement:
>> 
>> Introduce:
>>  - new capability: `can_get_gc_cpu_time`
>>  - new JVMTI functions:
>>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
>> 
>> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
>> 
>> Testing:
>>  - TBD: Mach5 tiers 1-6
>
> Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix a typo in GetGCCpuTimerInfo: long => jlong

> I'm wondering, would a user trying to call GetTotalGCCpuTime if can_get_gc_cpu_time is not successfully set to 1 be undefined behavior? The specs say "To possess a capability, the agent must add the capability (https://docs.oracle.com/en/java/javase/25/docs/specs/jvmti.html#capability). If yes maybe we can discard the extra call to os::is_thread_cpu_time_supported in JvmtiEnv::GetTotalGCCpuTime? That seems to align with the pattern to not have that check in the other methods as you pointed out.

Right thinking, thanks. In fact, I had a plan to move this check to the capability side after the week ends. :)

> Should this be called GetTotalGCCpuTimerInfo?

I was already thinking on this for some time. I wanted to generalize this timer a little bit for a case if we ever decide to add more GC related functions. I'm not sure that all timers have to be strictly bound to the `CpuTime` function` and can be potentially reused for some other cases.

> There may be two issues with the patch as is:
> Calling GetTotalGCCpuTime in Agent_OnLoad can cause crash (since CollectedHeap::gc_threads_do do not protect against races on VM startup/shutdown).
>
> If GetTotalGCCpuTime is invoked in a callback for GC start/end, this will cause a deadlock as the Heap_lock is already held. The MutexLocker hl(Heap_lock) pattern was introduced to avoid races that could happen from internal usage in G1 of CPUTimeUsage::GC::total() during shutdown. I could recall this wrong but I think the usage Heap_lock (which evidently has uses in other places) is an optimization to avoid having to create a new mutex shutdown variable. I could be wrong but it is maybe possible that this deadlock would be resolved by introducing a new mutex only used for syncing on the state of Universe::_is_shutting_down. I will ask @walulyai for his thoughts.

It is nice you have caught this early. It would be nice to sort out this issue, and it is better to fix it on the GC side. I'd suggest to file a bug to separate this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3423402965

From sspitsyn at openjdk.org  Mon Oct 20 21:05:25 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 20 Oct 2025 21:05:25 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v4]
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <5ZWuvRfM6nTcjIkNRpjYYHTlhNwuBEN0SK4lchzxVNw=.b655df31-9696-45ff-94cc-70c53b459d76@github.com>

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

Serguei Spitsyn has updated the pull request incrementally with one additional commit since the last revision:

  Review: address some review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27879/files
  - new: https://git.openjdk.org/jdk/pull/27879/files/d816a56d..6ac238eb

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

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

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

From kdnilsen at openjdk.org  Mon Oct 20 22:24:38 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 20 Oct 2025 22:24:38 GMT
Subject: RFR: 8358735: GenShen: bug in #undef'd code in block_start() [v3]
In-Reply-To: <JTwkqXthnFpzrfVsFosxLf2uDWRBXWguvioNPr-XqWA=.41881654-4539-4920-9d65-e93b210913f6@github.com>
References: <JTwkqXthnFpzrfVsFosxLf2uDWRBXWguvioNPr-XqWA=.41881654-4539-4920-9d65-e93b210913f6@github.com>
Message-ID: <6c-bIgvNvrGeDztqyi43wvvWMS4soCOHZ8Hnch2pq0c=.f7159ec5-ad89-4b76-9e24-bdddb05c0461@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:

  Fixup handling of weakly marked objects in remembered set

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

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

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

  Stats: 32 lines in 1 file changed: 20 ins; 1 del; 11 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 wkemper at openjdk.org  Mon Oct 20 23:51:53 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 20 Oct 2025 23:51:53 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v6]
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: <uxf5FEXcTwPsSrfnaAecBQ3yr7XtP4XT_suPsR2yy1c=.d394cb90-14e2-4a51-9094-039e4b7885bf@github.com>

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

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

 - Merge tag 'jdk-26+20' into promotion-budget-improvements
   
   Added tag jdk-26+20 for changeset b5b83247
 - Proper format bytes in logs for better readability
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Review feedback, bug fixes
 - Fix windows build more
 - Fix windows build
 - 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
 - ... and 48 more: https://git.openjdk.org/jdk/compare/b5b83247...c9af7069

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

Changes: https://git.openjdk.org/jdk/pull/27632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=05
  Stats: 346 lines in 16 files changed: 177 ins; 89 del; 80 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 jsikstro at openjdk.org  Tue Oct 21 08:05:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 21 Oct 2025 08:05:03 GMT
Subject: RFR: 8370078: Remove unnecessary argument in
 ContiguousSpace::initialize
In-Reply-To: <iw8cLbWMsVJxbcm8jkKnRc3Cp6bwrT0-OGZ49qS4Tck=.ccc3dcfe-c2e4-4603-88f2-74dd06c0873e@github.com>
References: <iw8cLbWMsVJxbcm8jkKnRc3Cp6bwrT0-OGZ49qS4Tck=.ccc3dcfe-c2e4-4603-88f2-74dd06c0873e@github.com>
Message-ID: <wyFdlA_KW_CFIt-FGeYMgiCTWw0_TY5DhUrXmtvFk6I=.09581d0b-7561-4bee-8136-c9d1483eb4da@github.com>

On Fri, 17 Oct 2025 12:06:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial "inlining" a statically know boolean value to a method.
> 
> Test: tier1

Looks good.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27865#pullrequestreview-3359272111

From ayang at openjdk.org  Tue Oct 21 08:17:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 08:17:33 GMT
Subject: RFR: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages [v13]
In-Reply-To: <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
 <euxZN64DUu0lUeJC87AO0z3A2oPYVB8svvBHaao-E0U=.ec4cbacc-8689-4496-85d0-e2ce7ef32a36@github.com>
Message-ID: <7czjnRkioTvwfdr0hxlBvTXkbw-4lP4yld-6Nint2lw=.d2b85ba9-f2cd-4e52-bca8-d85817726938@github.com>

On Tue, 14 Oct 2025 13:35:12 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 17 additional commits since the last revision:
> 
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - review
>  - review
>  - review
>  - Merge branch 'master' into pgc-largepage
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/8924d866...273c2003

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/26700#issuecomment-3425335159

From ayang at openjdk.org  Tue Oct 21 08:17:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 08:17:34 GMT
Subject: Integrated: 8346005: Parallel: Incorrect page size calculation with
 UseLargePages
In-Reply-To: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
References: <jXNhPC1SMapIncPp96kTZsA3a804lNX5VoyOFT60bas=.7134891c-25a0-4f70-a74a-b086a4e1138b@github.com>
Message-ID: <7LJx42wgyM6gU-5iJ5qvvPyzAuXY_x-FUrnWDUUUqhE=.017426b8-46ba-4326-bc14-26badae457fe@github.com>

On Fri, 8 Aug 2025 14:50:06 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

This pull request has now been integrated.

Changeset: 2be273f2
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2be273f20f839980f22a74b88b74fc5754fa0c11
Stats:     238 lines in 15 files changed: 77 ins; 93 del; 68 mod

8346005: Parallel: Incorrect page size calculation with UseLargePages

Co-authored-by: Joel Sikstr?m <jsikstro at openjdk.org>
Reviewed-by: jsikstro, fandreuzzi

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

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

From ayang at openjdk.org  Tue Oct 21 09:04:19 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 09:04:19 GMT
Subject: RFR: 8370078: Remove unnecessary argument in
 ContiguousSpace::initialize
In-Reply-To: <iw8cLbWMsVJxbcm8jkKnRc3Cp6bwrT0-OGZ49qS4Tck=.ccc3dcfe-c2e4-4603-88f2-74dd06c0873e@github.com>
References: <iw8cLbWMsVJxbcm8jkKnRc3Cp6bwrT0-OGZ49qS4Tck=.ccc3dcfe-c2e4-4603-88f2-74dd06c0873e@github.com>
Message-ID: <61V7nGBH--gfHHJYx7NYLY8cazska8EP8Leb-oiTctg=.a8fb3da0-971a-45fb-866b-7232a14d02b5@github.com>

On Fri, 17 Oct 2025 12:06:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial "inlining" a statically know boolean value to a method.
> 
> Test: tier1

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27865#issuecomment-3425514533

From ayang at openjdk.org  Tue Oct 21 09:04:20 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 09:04:20 GMT
Subject: Integrated: 8370078: Remove unnecessary argument in
 ContiguousSpace::initialize
In-Reply-To: <iw8cLbWMsVJxbcm8jkKnRc3Cp6bwrT0-OGZ49qS4Tck=.ccc3dcfe-c2e4-4603-88f2-74dd06c0873e@github.com>
References: <iw8cLbWMsVJxbcm8jkKnRc3Cp6bwrT0-OGZ49qS4Tck=.ccc3dcfe-c2e4-4603-88f2-74dd06c0873e@github.com>
Message-ID: <g2PJWa3B_5zU_NyyIzs09Jw8X6oJK3NKIx8vcZcUG70=.fb87bb77-fcd6-418e-95a5-ef10ca6b54a9@github.com>

On Fri, 17 Oct 2025 12:06:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial "inlining" a statically know boolean value to a method.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: a0c41244
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0c41244325c3d14873e494e79f6c4e38c8e541a
Stats:     10 lines in 5 files changed: 0 ins; 1 del; 9 mod

8370078: Remove unnecessary argument in ContiguousSpace::initialize

Reviewed-by: fandreuzzi, jsikstro

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

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

From ayang at openjdk.org  Tue Oct 21 09:31:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 09:31:32 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v5]
In-Reply-To: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
Message-ID: <u1U80Vr5E9ceWrUbfjCNP6tq62bCWNmX-tkOIf9d270=.5b0f6cb4-f80e-45fe-a803-87506c1bcc87@github.com>

> Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full.
> 
> This is needed only when `UseAdaptiveSizePolicy` is on, because this is intended to avoid including extra OS-time in gc-pause-time tracking, used for young-gen resizing.
> 
> Test: tier1-3

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

 - review
 - Merge branch 'master' into pgc-os-free-mem
 - Merge branch 'master' into pgc-os-free-mem
 - review
 - sizet
 - Merge branch 'master' into pgc-os-free-mem
 - Merge branch 'master' into pgc-os-free-mem
 - review
 - Merge branch 'master' into pgc-os-free-mem
 - pgc-os-free-mem

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27068/files
  - new: https://git.openjdk.org/jdk/pull/27068/files/affa0435..47bf31ad

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

  Stats: 5184 lines in 151 files changed: 3020 ins; 1057 del; 1107 mod
  Patch: https://git.openjdk.org/jdk/pull/27068.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27068/head:pull/27068

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

From duke at openjdk.org  Tue Oct 21 10:15:34 2025
From: duke at openjdk.org (duke)
Date: Tue, 21 Oct 2025 10:15:34 GMT
Subject: Withdrawn: 8350860: Max GC memory overhead tests
In-Reply-To: <Y6KqlygSLGET9-o960ocNqePVgY3wtJnB_0kNPpMCTI=.48e2a913-3b00-47e5-96a5-491d21313df1@github.com>
References: <Y6KqlygSLGET9-o960ocNqePVgY3wtJnB_0kNPpMCTI=.48e2a913-3b00-47e5-96a5-491d21313df1@github.com>
Message-ID: <i0vJ-Il0P_CvarC1n8iKRd333MElcKIieXlTeTh7MLw=.7c1ef839-a77c-4dad-96c3-d10f76f31802@github.com>

On Thu, 1 May 2025 05:23:50 GMT, Rui Li <duke at openjdk.org> wrote:

> The G1 GC metadata has increased from JDK8 to the current tip. When upgrading JDK for an application from JDK8, applications might observe native memory increases. GC is one of the top contributors. Small applications tend to get impacted more significantly. See sample test in description in https://bugs.openjdk.org/browse/JDK-8350860, when heap is 128m, the native memory used by gc can be over 80m.
> 
> In order to make sure we don't bring dramatic native memory increase while developing G1, adding this metadata guardrail test. The test calculates the native memory based on existing GC usages and provides some headroom. When there are significant increase, the test would fail and we should look back to see if the added native memory make sense.

This pull request has been closed without being integrated.

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

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

From ayang at openjdk.org  Tue Oct 21 11:46:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 11:46:40 GMT
Subject: RFR: 8370326: Parallel: Remove unused ParCompactionManager::push
Message-ID: <wNVz7rXVLcAeAV41i2zsWZ1zg_k6t5M7kpqKL8a5R9E=.ef5b5889-8334-4dc7-8a3a-5fe5b3335637@github.com>

Trivial removing dead code.

Test: tier1

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

Commit messages:
 - pgc-trivial-unused

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

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

From fandreuzzi at openjdk.org  Tue Oct 21 11:51:02 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 21 Oct 2025 11:51:02 GMT
Subject: RFR: 8370326: Parallel: Remove unused ParCompactionManager::push
In-Reply-To: <wNVz7rXVLcAeAV41i2zsWZ1zg_k6t5M7kpqKL8a5R9E=.ef5b5889-8334-4dc7-8a3a-5fe5b3335637@github.com>
References: <wNVz7rXVLcAeAV41i2zsWZ1zg_k6t5M7kpqKL8a5R9E=.ef5b5889-8334-4dc7-8a3a-5fe5b3335637@github.com>
Message-ID: <KlOJ3Kz3TQrmSabMb5cL7NgvGoWhQGSZelmFA6T9E0k=.e0285d00-72b9-420f-9e13-e37e6a3861fd@github.com>

On Tue, 21 Oct 2025 11:40:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27914#pullrequestreview-3360182902

From tschatzl at openjdk.org  Tue Oct 21 13:02:11 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 21 Oct 2025 13:02:11 GMT
Subject: RFR: 8370326: Parallel: Remove unused ParCompactionManager::push
In-Reply-To: <wNVz7rXVLcAeAV41i2zsWZ1zg_k6t5M7kpqKL8a5R9E=.ef5b5889-8334-4dc7-8a3a-5fe5b3335637@github.com>
References: <wNVz7rXVLcAeAV41i2zsWZ1zg_k6t5M7kpqKL8a5R9E=.ef5b5889-8334-4dc7-8a3a-5fe5b3335637@github.com>
Message-ID: <kXDvPTxcP0y675QLN9Am4N0h2xdu8TvTg0sDzXASxK8=.32c2f49d-f1ae-4e49-982c-af20f3672ebf@github.com>

On Tue, 21 Oct 2025 11:40:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

Trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27914#pullrequestreview-3360553817

From ayang at openjdk.org  Tue Oct 21 13:06:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 13:06:11 GMT
Subject: RFR: 8370234: Remove CardTableBarrierSet::write_region
In-Reply-To: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
References: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
Message-ID: <rwoCbZT2B2ILiQ-sF75Up3o55cKjnWF0WCOZyduHFBY=.aca5cea4-f646-42fe-80eb-28085b7cfe33@github.com>

On Mon, 20 Oct 2025 12:41:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing effectively dead code.
> 
> Test: tier1

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27898#issuecomment-3426507694

From ayang at openjdk.org  Tue Oct 21 13:06:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 13:06:12 GMT
Subject: Integrated: 8370234: Remove CardTableBarrierSet::write_region
In-Reply-To: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
References: <e-V0KWR30kJqQFyr2YKUj7O3xypxxNiSvmdPbC9Dzm8=.0762a1cd-d042-4724-b122-9d6d1b9f0270@github.com>
Message-ID: <2qAezk5K68YOqi1HOuFAao_8Q1oAMjR2LGQx9GQs8rE=.79786d9e-9446-42d1-a762-d137f0c44a93@github.com>

On Mon, 20 Oct 2025 12:41:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing effectively dead code.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 517d5437
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/517d54373fcabf4ef2c1d189b0c703a21be8eaf6
Stats:     13 lines in 5 files changed: 0 ins; 11 del; 2 mod

8370234: Remove CardTableBarrierSet::write_region

Reviewed-by: tschatzl, fandreuzzi

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

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

From alanb at openjdk.org  Tue Oct 21 13:12:57 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Oct 2025 13:12:57 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <69b0xF_paR2o1C9IPIVZv144v47w2SE3KD8epKGQ1wE=.d4a35d76-4145-47ee-b0e9-581a0acdb70d@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <BK3M3IFfhNgtwtKR6DycUtNPZHz1hDZxwxMTubaMToo=.b659859c-fd03-4657-8b01-d5fb48f202c6@github.com>
 <69b0xF_paR2o1C9IPIVZv144v47w2SE3KD8epKGQ1wE=.d4a35d76-4145-47ee-b0e9-581a0acdb70d@github.com>
Message-ID: <DSVgFKaNd2rNZ9tMNzCo2eGP3nz1YEJRV__1IuPSiGc=.8b7a6da1-cb55-4f73-80a0-320c9bdfc935@github.com>

On Mon, 20 Oct 2025 10:26:44 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Right, there will be a deadlock if `GetTotalGCCpuTime` is called in the callbacks for events `GarbageCollectionStart`, `GarbageCollectionFinish`

The GarbageCollectionStart and GarbageCollectionFinish events are specified to sent when the VM is "stopped" (VM agnostic wording). The only JVMTI functions specified to be allowed are the raw monitor and the env local storage functions.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3426554971

From alanb at openjdk.org  Tue Oct 21 13:26:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Oct 2025 13:26:34 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
 <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
Message-ID: <39-PzTz8olnzgkbmm_qAAcZEEN-GXcVhrkxOKuS9sUQ=.3b07b1c9-5add-425f-ab48-eb29281ecbfc@github.com>

On Sun, 19 Oct 2025 15:37:22 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Certainly, thanks for asking. Researchers in GC are using the GC start/end events (https://dl.acm.org/doi/10.1145/3669940.3707217, https://ieeexplore.ieee.org/document/9804613, https://dl.acm.org/doi/10.1145/3764118, https://dl.acm.org/doi/10.1145/3652024.3665510 etc.) to understand various costs pertaining to GC. I believe one USP of using a JVMTI agent is that it does not require modification of the benchmarking code and allows usage of powerful features made available by framework such as libpfm.
> 
> So these JVMTI hooks are used to read CPU performance counters to get some estimations of various metrics, be it CPU time, cache-misses etc. However this imposes severe limitations especially when it comes GCs with concurrent parts. This patch will expand the capabilities for these users using JVMTI agents to profile applications.

I've no doubt that it is useful but it also reasonable to ask if JVMTI is the right API for monitoring GC in 2025. This is a neglected area, the existing events date from 20 years ago, and pre-date concurrent collectors and other advancements. Is this the start of a revival of JVMTI for profiling tools?  If we could start again what features would a GC monitor interface have to help troubleshooting, performance monitoring, and research? Would we confident modelling a VM and GC agnostic interface or would there be aspects that are very GC specific?

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3426635449

From ayang at openjdk.org  Tue Oct 21 13:47:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 13:47:34 GMT
Subject: RFR: 8370326: Parallel: Remove unused ParCompactionManager::push
In-Reply-To: <wNVz7rXVLcAeAV41i2zsWZ1zg_k6t5M7kpqKL8a5R9E=.ef5b5889-8334-4dc7-8a3a-5fe5b3335637@github.com>
References: <wNVz7rXVLcAeAV41i2zsWZ1zg_k6t5M7kpqKL8a5R9E=.ef5b5889-8334-4dc7-8a3a-5fe5b3335637@github.com>
Message-ID: <1L2DUUSmBoeZnsIVXHX9-_vP7TjSSPIsoQpCrDQG7AU=.4b4c6c4e-7b02-401c-9904-ace53678c636@github.com>

On Tue, 21 Oct 2025 11:40:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27914#issuecomment-3426747541

From ayang at openjdk.org  Tue Oct 21 13:47:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 21 Oct 2025 13:47:35 GMT
Subject: Integrated: 8370326: Parallel: Remove unused
 ParCompactionManager::push
In-Reply-To: <wNVz7rXVLcAeAV41i2zsWZ1zg_k6t5M7kpqKL8a5R9E=.ef5b5889-8334-4dc7-8a3a-5fe5b3335637@github.com>
References: <wNVz7rXVLcAeAV41i2zsWZ1zg_k6t5M7kpqKL8a5R9E=.ef5b5889-8334-4dc7-8a3a-5fe5b3335637@github.com>
Message-ID: <d3fCQa6LyKxmYB9GU6jmzsfuB7lBIqzdbkTFkiC5j4k=.1312cf2e-f710-4ebd-8390-16fe0bc6d428@github.com>

On Tue, 21 Oct 2025 11:40:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 0529a58a
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0529a58a73a532d06899e145ed284b222fe3f07c
Stats:     5 lines in 2 files changed: 0 ins; 5 del; 0 mod

8370326: Parallel: Remove unused ParCompactionManager::push

Reviewed-by: fandreuzzi, tschatzl

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

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

From sspitsyn at openjdk.org  Tue Oct 21 19:08:48 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 19:08:48 GMT
Subject: RFR: 8369449: Spec: introduce new JVMTI function GetTotalGCCpuTime
 [v3]
In-Reply-To: <39-PzTz8olnzgkbmm_qAAcZEEN-GXcVhrkxOKuS9sUQ=.3b07b1c9-5add-425f-ab48-eb29281ecbfc@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
 <BzZzpolqX59A9JOOUb-PiWrbHnixs1v0aMmR3i39oag=.ca349643-729a-4b79-9d63-805d048bc2f3@github.com>
 <ExrLOpolAN-Ppb4UrvJfVLpvYret1_koJrSKzYNxXOU=.f6b65f46-b021-4ee8-b629-068d7b447027@github.com>
 <0nz-dONOJ4S1YeZ6UidUEqWZJrFeS8CT0TnyJ2dWUJU=.f0439488-2831-4afa-ba52-4369330aa14d@github.com>
 <39-PzTz8olnzgkbmm_qAAcZEEN-GXcVhrkxOKuS9sUQ=.3b07b1c9-5add-425f-ab48-eb29281ecbfc@github.com>
Message-ID: <y9wgNd7XViOW43bMP3CEAR5EVv7DVCoABHhvgXXul2o=.d5fbd3cc-5a28-4322-b808-759974d5c1e1@github.com>

On Tue, 21 Oct 2025 13:24:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I've no doubt that it is useful but it also reasonable to ask if JVMTI is the right API for monitoring GC in 2025. This is a neglected area, the existing events date from 20 years ago, and pre-date concurrent collectors and other advancements. Is this the start of a revival of JVMTI for profiling tools? If we could start again what features would a GC monitor interface have to help troubleshooting, performance monitoring, and research? Would we confident modelling a VM and GC agnostic interface or would there be aspects that are very GC specific?

Thank you, Alan. There was some offline Slack conversation with Ron and Jonas. Conclusion is the JMX support should be enough for this. So, I've closed the enhancement as WNF and this PR as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/27879#issuecomment-3428949447

From sspitsyn at openjdk.org  Tue Oct 21 19:08:49 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 21 Oct 2025 19:08:49 GMT
Subject: Withdrawn: 8369449: Spec: introduce new JVMTI function
 GetTotalGCCpuTime
In-Reply-To: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
References: <Qd_c10uBeehPDeBetiEiyQ3DvToRZVmt8D5mNYh4mRk=.84da43d4-1afd-4889-8bc7-ca85582e4b87@github.com>
Message-ID: <_ipWevP4P2gHRrOmOncxXrrOXkwa1kn9rvLtKUHKK_Q=.87a85881-c8ea-4321-87f1-67240d06883a@github.com>

On Fri, 17 Oct 2025 21:02:08 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> With [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) a framework to measure GC CPU time was introduced.
> It will be exposed in JMX as `MemoryMXBean.getTotalGcCpuTime()`. There is also interest to get the same performance data from JVMTI.
> The following API's are being added with this enhancement:
> 
> Introduce:
>  - new capability: `can_get_gc_cpu_time`
>  - new JVMTI functions:
>     - `jvmtiError GetGCCpuTimerInfo(jvmtiEnv* env, jvmtiTimerInfo* info_ptr)`
>     - `jvmtiError GetTotalGCCpuTime(jvmtiEnv* env, jlong* nanos_ptr)`
> 
> **CSR**: [8370159](https://bugs.openjdk.org/browse/JDK-8370159): Spec: introduce new JVMTI function GetTotalGCCpuTime
> 
> Testing:
>  - TBD: Mach5 tiers 1-6

This pull request has been closed without being integrated.

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

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

From kdnilsen at openjdk.org  Tue Oct 21 23:42:49 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 21 Oct 2025 23:42:49 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v27]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <4qrP0qDQkfL-ogpd0AQ2gJMMlnvo80IQJ36aQHYbTDo=.790fee9b-1720-4aab-bde2-e4ff205426d0@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:

  Fix up vmstructs and other infrastructure for jmap heap dump

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/891e96b8..ee617c30

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

  Stats: 130 lines in 5 files changed: 63 ins; 59 del; 8 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 ysr at openjdk.org  Wed Oct 22 01:53:16 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 22 Oct 2025 01:53:16 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
Message-ID: <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>

On Tue, 14 Oct 2025 23:03:16 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are certain code paths in Shenandoah's generational mode that need to _know_ which generation is being collected, but it is not possible to pass this information on the stack (barriers, for example). To address this, we introduced an `_active_generation` member in `ShenandoahHeap`. Over time, the usage of this field grew beyond its intended purpose and we began to have issues where not all threads would see a consistent value for this field. To address _this_ issue, we added another field `_gc_generation` which was only meant to be used by GC threads. At this point, we have three different ways to determine which generation is being collected: the _active_ generation, the _gc_ generation, and the usual function parameters and member fields of the gc components. This PR removes `_gc_generation` and reduces the use of `_active_generation` to only those places where it is not possible to get this information from other means (barriers, mostly). All GC components that can have t
 his information passed through function calls, now do so.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Remove _gc_generation from ShenandoahHeap
>  - Little cleanup, remove one active generation usage
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>  - Fix build
>  - Use existing _generation field instead of Heap::_gc_generation where possible
>  - Only shenandoah vm operations participate in active/gc generation scheme

Left a few minor suggestions. This is a very nice clean-up, thank you!

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

> 356:     assert(_from_region != nullptr, "must set before work");
> 357:     assert(_heap->marking_context()->is_marked(p), "must be marked");
> 358:     assert(!_heap->marking_context()->allocated_after_mark_start(p), "must be truly marked");

Why not `_generation->complete_marking_context()...` with the help of a `_generation` field kept in the object? It would make the idiom uniform and consistent across all these closures.

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

> 800:   }
> 801:   void do_object(oop p) {
> 802:     assert(_heap->marking_context()->is_marked(p), "must be marked");

Just use `_ctx` from line 784?

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

> 884: 
> 885:   void do_object(oop p) {
> 886:     assert(_heap->marking_context()->is_marked(p), "must be marked");

ditto (comment at line 802).

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

> 172: // contained herein.
> 173: void ShenandoahGenerationalEvacuationTask::promote_in_place(ShenandoahHeapRegion* region) {
> 174:   assert(!_generation->is_old(), "Sanity check");

Would `assert(_generation->is_young()...` be too strong at line 174 for some reason? e.g. could `_generation` be `is_global()` here?

You could then confidently replace the `_heap->young_generation()` indirection at line 175 below with just `_generation`, also simplifying comprehension complexity & code maintainability.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalFullGC.cpp line 56:

> 54:   auto heap = ShenandoahGenerationalHeap::heap();
> 55:   // Since we may arrive here from degenerated GC failure of either young or old, establish generation as GLOBAL.
> 56:   heap->set_active_generation(heap->global_generation());

While this is good practice for consistency, is `_active_generation`  ever used by the worker threads when doing a full gc? Not asking to remove this line, just wondering if it's ever used now, following your changes in this PR.

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

> 849:     }
> 850: 
> 851:     if (!_generation->is_global()) {

Is this ever `_generation->is_old()` ? I am guessing this is either global or young? I am guessing for the case of update_refs for a mixed collection we still pass in the `young` gen here?

It might be a good idea wherever we have a `_generation` field member in a class to indicate what it represents. In most cases, it's probably clear that it represents the generation subject to collection in that cycle. But for mixed collection sets, what does the `_generation` field represent?

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp line 92:

> 90:   oop try_evacuate_object(oop p, Thread* thread, ShenandoahHeapRegion* from_region, ShenandoahAffiliation target_gen);
> 91:   void evacuate_collection_set(ShenandoahGeneration* generation, bool concurrent) override;
> 92:   void promote_regions_in_place(ShenandoahGeneration* generation, bool concurrent);

Document what the parameters to the call represent, in particular `generation`.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp line 102:

> 100:   // ---------- Update References
> 101:   //
> 102:   void update_heap_references(ShenandoahGeneration* generation, bool concurrent) override;

Ditto (to comment at line 92).

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

> 147: 
> 148:   // This is set and cleared by only the VMThread
> 149:   // at each STW pause (safepoint) to the value given to the VM operation.

Very nice simplification which cleans up a lot of the old messiness. Thanks!

src/hotspot/share/gc/shenandoah/shenandoahMark.cpp line 82:

> 80: template<bool CANCELLABLE, StringDedupMode STRING_DEDUP>
> 81: void ShenandoahMark::mark_loop(uint worker_id, TaskTerminator* terminator,
> 82:                                ShenandoahGenerationType generation, StringDedup::Requests* const req) {

Since `ShenandoahMark` has a `_generation` data member with a `generation()` accessor, I'd rename the formal parameters of type `ShenandoahGenerationType` for all these methods from `generation` to `gen_type` or something like that to reduce confusion while reading the code.

src/hotspot/share/gc/shenandoah/shenandoahMark.cpp line 104:

> 102: }
> 103: 
> 104: void ShenandoahMark::mark_loop(uint worker_id, TaskTerminator* terminator, ShenandoahGenerationType generation,

parm name comment at line 82, applies below as well.

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 1:

> 1: /*

Some of the spots here on where we need a completed marking context and where we are permitted to use a possibly in flight marking context isn't terribly clear. At some point, we should probably go through and clarify.

src/hotspot/share/gc/shenandoah/shenandoahRootVerifier.hpp line 47:

> 45:   // Used to seed ShenandoahVerifier, do not honor root type filter
> 46:   static void roots_do(OopIterateClosure* cl, ShenandoahGeneration* generation);
> 47:   static void strong_roots_do(OopIterateClosure* cl, ShenandoahGeneration* generation);

Document what the parameter `generation` represents here.

src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 152:

> 150:   StringDedup::Requests requests;
> 151: 
> 152:   // TODO: Why are we passing our own fields to our own method?

It's a method on our parent class which doesn't have a Terminator object handy.

src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp line 55:

> 53:   explicit VM_ShenandoahOperation(ShenandoahGeneration* generation)
> 54:   : _gc_id(GCId::current())
> 55:   , _generation(generation) {

style question: shouldn't the comma go at the end of the previous line?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27703#pullrequestreview-3352384744
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450040309
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450050185
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450050669
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2441449826
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450058990
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450082830
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450086356
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450086707
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2441455419
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450129501
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450130541
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450145164
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450147249
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450159840
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2441471022

From ysr at openjdk.org  Wed Oct 22 01:53:17 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 22 Oct 2025 01:53:17 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
 <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
Message-ID: <Q8CsOHvb275UhtHxgGSq0jH_qIkDqmAlZcDeRrb2NiA=.93d20df1-7893-43f8-bbb2-ea5ac34b957a@github.com>

On Wed, 22 Oct 2025 00:29:29 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Remove _gc_generation from ShenandoahHeap
>>  - Little cleanup, remove one active generation usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>>  - Fix build
>>  - Use existing _generation field instead of Heap::_gc_generation where possible
>>  - Only shenandoah vm operations participate in active/gc generation scheme
>
> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 358:
> 
>> 356:     assert(_from_region != nullptr, "must set before work");
>> 357:     assert(_heap->marking_context()->is_marked(p), "must be marked");
>> 358:     assert(!_heap->marking_context()->allocated_after_mark_start(p), "must be truly marked");
> 
> Why not `_generation->complete_marking_context()...` with the help of a `_generation` field kept in the object? It would make the idiom uniform and consistent across all these closures.

Or like you did below at line 784, perhaps `_heap->global_generation()->complete_marking_context()...` stashed in local `_ctx` field ?

> src/hotspot/share/gc/shenandoah/shenandoahGenerationalFullGC.cpp line 56:
> 
>> 54:   auto heap = ShenandoahGenerationalHeap::heap();
>> 55:   // Since we may arrive here from degenerated GC failure of either young or old, establish generation as GLOBAL.
>> 56:   heap->set_active_generation(heap->global_generation());
> 
> While this is good practice for consistency, is `_active_generation`  ever used by the worker threads when doing a full gc? Not asking to remove this line, just wondering if it's ever used now, following your changes in this PR.

PS: My reasoning is that we are doing this at a safepoint, presumably, and the full gc will be done by the time we get out of the safepoint. Thus, mutators will never see this value. Further, worker threads seem now to use a `generation` member field passed in with the relevant work closure/method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450047381
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2450061214

From tschatzl at openjdk.org  Wed Oct 22 08:07:21 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 22 Oct 2025 08:07:21 GMT
Subject: RFR: 8370325: G1: Only one source of GC operations during object
 allocation
Message-ID: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>

Hi all,

  please review this change to the object allocation path to only allow direct allocation after failing TLAB allocation doing GCs.

Currently, when allocating an object, G1 (or actually any collector) first allocates from TLABs, then allocates from outside TLABs.

When G1 can't find space for a TLAB in the current region, it passes on control to `G1CollectedHeap::attempt_allocation[_slow]` that first tries to allocate that memory using a new region, or if that fails, do a GC. Potential allocation outside TLABs that would follow TLAB-allocation does the same.

G1's behavior to do a GC during failed TLAB allocation is problematic for the `UseGCOverheadLimit` functionality (https://bugs.openjdk.org/browse/JDK-8212084): if the GC overhead limit triggers in a TLAB allocation, it returns `null` for that TLAB allocation.
Control will be passed to outside-tlab allocation as described above. Since the garbage collections for TLAB allocations did free some memory (but because of exceeded gc overhead we returned null for the TLAB allocation), that allocation/collection for this outside-tlab allocation will succeed and return non-`null` to the mutator, effectively swallowing the information that GC overhead has been exceeded.

I split this out from the `UseGCOverheadLimit` change because I thought it is somewhat standalone, but I can merge it.

Testing: tier1-5, performance neutral after some tests

Hth,
  Thomas

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

Commit messages:
 - 8370325

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

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

From ayang at openjdk.org  Wed Oct 22 08:32:56 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 22 Oct 2025 08:32:56 GMT
Subject: RFR: 8370406: Parallel: Refactor ParCompactionManager::mark_and_push
Message-ID: <yNFxkkvXgK9V6m5p0HVzR9juUwukhdlxIsydKH2wG84=.276c6bfa-ec95-422c-853c-f66cccc728b5@github.com>

Simple refactoring to reduce indentation level and inlining a single-caller method.

Test: tier1-3

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

Commit messages:
 - pgc-refactor-mark-closure

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

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

From fandreuzzi at openjdk.org  Wed Oct 22 08:36:39 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 22 Oct 2025 08:36:39 GMT
Subject: RFR: 8370406: Parallel: Refactor
 ParCompactionManager::mark_and_push
In-Reply-To: <yNFxkkvXgK9V6m5p0HVzR9juUwukhdlxIsydKH2wG84=.276c6bfa-ec95-422c-853c-f66cccc728b5@github.com>
References: <yNFxkkvXgK9V6m5p0HVzR9juUwukhdlxIsydKH2wG84=.276c6bfa-ec95-422c-853c-f66cccc728b5@github.com>
Message-ID: <jhAFjMrMkJktWhuwivmeaseKLof59szk3phjsOo5obU=.7a75bacd-6a59-4197-b6d8-2a892bda819e@github.com>

On Wed, 22 Oct 2025 08:26:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to reduce indentation level and inlining a single-caller method.
> 
> Test: tier1-3

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27933#pullrequestreview-3364313653

From gli at openjdk.org  Wed Oct 22 08:47:26 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Wed, 22 Oct 2025 08:47:26 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v5]
In-Reply-To: <u1U80Vr5E9ceWrUbfjCNP6tq62bCWNmX-tkOIf9d270=.5b0f6cb4-f80e-45fe-a803-87506c1bcc87@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
 <u1U80Vr5E9ceWrUbfjCNP6tq62bCWNmX-tkOIf9d270=.5b0f6cb4-f80e-45fe-a803-87506c1bcc87@github.com>
Message-ID: <-GJOYDzuqOjoCHuqzYwwBgo1F06WzvSPV5uuv0uH7Fw=.e50f103d-f618-4a1e-97fe-36abbfdddd7b@github.com>

On Tue, 21 Oct 2025 09:31:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full.
>> 
>> This is needed only when `UseAdaptiveSizePolicy` is on, because this is intended to avoid including extra OS-time in gc-pause-time tracking, used for young-gen resizing.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-os-free-mem
>  - Merge branch 'master' into pgc-os-free-mem
>  - review
>  - sizet
>  - Merge branch 'master' into pgc-os-free-mem
>  - Merge branch 'master' into pgc-os-free-mem
>  - review
>  - Merge branch 'master' into pgc-os-free-mem
>  - pgc-os-free-mem

Looks good.

src/hotspot/share/gc/parallel/psScavenge.cpp line 525:

> 523: bool PSScavenge::should_attempt_scavenge() {
> 524:   const bool ShouldRunYoungGC = true;
> 525:   const bool ShouldRunFullGC = false;

According to the code style document `Constant names may be upper-case or mixed-case`, the previous and current names are good.

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

Marked as reviewed by gli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27068#pullrequestreview-3364352552
PR Review Comment: https://git.openjdk.org/jdk/pull/27068#discussion_r2450950425

From iwalulya at openjdk.org  Wed Oct 22 09:39:11 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 22 Oct 2025 09:39:11 GMT
Subject: RFR: 8370406: Parallel: Refactor
 ParCompactionManager::mark_and_push
In-Reply-To: <yNFxkkvXgK9V6m5p0HVzR9juUwukhdlxIsydKH2wG84=.276c6bfa-ec95-422c-853c-f66cccc728b5@github.com>
References: <yNFxkkvXgK9V6m5p0HVzR9juUwukhdlxIsydKH2wG84=.276c6bfa-ec95-422c-853c-f66cccc728b5@github.com>
Message-ID: <ZeQg8PO0FBXzOpsgsy9wobPLCae-DSEYjiTwpaSj3TY=.098c2910-e8fe-4148-9f02-88be25c7c9f6@github.com>

On Wed, 22 Oct 2025 08:26:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to reduce indentation level and inlining a single-caller method.
> 
> Test: tier1-3

Nit:
I suppose the asserts were considered redundant and left out of the refactoring

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27933#pullrequestreview-3364697812

From tschatzl at openjdk.org  Wed Oct 22 10:14:37 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 22 Oct 2025 10:14:37 GMT
Subject: RFR: 8370325: G1: Only one source of GC operations during object
 allocation [v2]
In-Reply-To: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
References: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
Message-ID: <sjn_mwM_ITHol03vmUzGQs51522H13fuT4KzJ5X_vNs=.4b3f1164-5814-4964-8a74-fccaebeb6fd2@github.com>

> Hi all,
> 
>   please review this change to the object allocation path to only allow direct allocation after failing TLAB allocation doing GCs.
> 
> Currently, when allocating an object, G1 (or actually any collector) first allocates from TLABs, then allocates from outside TLABs.
> 
> When G1 can't find space for a TLAB in the current region, it passes on control to `G1CollectedHeap::attempt_allocation[_slow]` that first tries to allocate that memory using a new region, or if that fails, do a GC. Potential allocation outside TLABs that would follow TLAB-allocation does the same.
> 
> G1's behavior to do a GC during failed TLAB allocation is problematic for the `UseGCOverheadLimit` functionality (https://bugs.openjdk.org/browse/JDK-8212084): if the GC overhead limit triggers in a TLAB allocation, it returns `null` for that TLAB allocation.
> Control will be passed to outside-tlab allocation as described above. Since the garbage collections for TLAB allocations did free some memory (but because of exceeded gc overhead we returned null for the TLAB allocation), that allocation/collection for this outside-tlab allocation will succeed and return non-`null` to the mutator, effectively swallowing the information that GC overhead has been exceeded.
> 
> I split this out from the `UseGCOverheadLimit` change because I thought it is somewhat standalone, but I can merge it.
> 
> Testing: tier1-5, performance neutral after some tests
> 
> Hth,
>   Thomas

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

  * fix comments, walulyai review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27932/files
  - new: https://git.openjdk.org/jdk/pull/27932/files/d75147e3..83de6f25

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

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

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

From tschatzl at openjdk.org  Wed Oct 22 10:42:17 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 22 Oct 2025 10:42:17 GMT
Subject: RFR: 8370325: G1: Only one source of GC operations during object
 allocation [v3]
In-Reply-To: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
References: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
Message-ID: <DkTWxmoD6v3ztHYmrA8to_9io62ZbjeWZph3g8bdaps=.27699623-05bd-4893-bbcb-aa4cc44ad382@github.com>

> Hi all,
> 
>   please review this change to the object allocation path to only allow direct allocation after failing TLAB allocation doing GCs.
> 
> Currently, when allocating an object, G1 (or actually any collector) first allocates from TLABs, then allocates from outside TLABs.
> 
> When G1 can't find space for a TLAB in the current region, it passes on control to `G1CollectedHeap::attempt_allocation[_slow]` that first tries to allocate that memory using a new region, or if that fails, do a GC. Potential allocation outside TLABs that would follow TLAB-allocation does the same.
> 
> G1's behavior to do a GC during failed TLAB allocation is problematic for the `UseGCOverheadLimit` functionality (https://bugs.openjdk.org/browse/JDK-8212084): if the GC overhead limit triggers in a TLAB allocation, it returns `null` for that TLAB allocation.
> Control will be passed to outside-tlab allocation as described above. Since the garbage collections for TLAB allocations did free some memory (but because of exceeded gc overhead we returned null for the TLAB allocation), that allocation/collection for this outside-tlab allocation will succeed and return non-`null` to the mutator, effectively swallowing the information that GC overhead has been exceeded.
> 
> I split this out from the `UseGCOverheadLimit` change because I thought it is somewhat standalone, but I can merge it.
> 
> Testing: tier1-5, performance neutral after some tests
> 
> Hth,
>   Thomas

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

  * more parameter name changes, walulyai review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27932/files
  - new: https://git.openjdk.org/jdk/pull/27932/files/83de6f25..23057abe

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

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

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

From iwalulya at openjdk.org  Wed Oct 22 10:42:18 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 22 Oct 2025 10:42:18 GMT
Subject: RFR: 8370325: G1: Only one source of GC operations during object
 allocation [v3]
In-Reply-To: <DkTWxmoD6v3ztHYmrA8to_9io62ZbjeWZph3g8bdaps=.27699623-05bd-4893-bbcb-aa4cc44ad382@github.com>
References: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
 <DkTWxmoD6v3ztHYmrA8to_9io62ZbjeWZph3g8bdaps=.27699623-05bd-4893-bbcb-aa4cc44ad382@github.com>
Message-ID: <Lg24aKjERqSEvqDXxiIrOVipGow30xmUDYrEhz0yk-o=.6ba065fb-2f62-4112-98ff-94589b5cd5b3@github.com>

On Wed, 22 Oct 2025 10:39:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to the object allocation path to only allow direct allocation after failing TLAB allocation doing GCs.
>> 
>> Currently, when allocating an object, G1 (or actually any collector) first allocates from TLABs, then allocates from outside TLABs.
>> 
>> When G1 can't find space for a TLAB in the current region, it passes on control to `G1CollectedHeap::attempt_allocation[_slow]` that first tries to allocate that memory using a new region, or if that fails, do a GC. Potential allocation outside TLABs that would follow TLAB-allocation does the same.
>> 
>> G1's behavior to do a GC during failed TLAB allocation is problematic for the `UseGCOverheadLimit` functionality (https://bugs.openjdk.org/browse/JDK-8212084): if the GC overhead limit triggers in a TLAB allocation, it returns `null` for that TLAB allocation.
>> Control will be passed to outside-tlab allocation as described above. Since the garbage collections for TLAB allocations did free some memory (but because of exceeded gc overhead we returned null for the TLAB allocation), that allocation/collection for this outside-tlab allocation will succeed and return non-`null` to the mutator, effectively swallowing the information that GC overhead has been exceeded.
>> 
>> I split this out from the `UseGCOverheadLimit` change because I thought it is somewhat standalone, but I can merge it.
>> 
>> Testing: tier1-5, performance neutral after some tests
>> 
>> Hth,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * more parameter name changes, walulyai review

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27932#pullrequestreview-3365119550

From ayang at openjdk.org  Wed Oct 22 13:00:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 22 Oct 2025 13:00:04 GMT
Subject: RFR: 8370325: G1: Only one source of GC operations during object
 allocation [v3]
In-Reply-To: <DkTWxmoD6v3ztHYmrA8to_9io62ZbjeWZph3g8bdaps=.27699623-05bd-4893-bbcb-aa4cc44ad382@github.com>
References: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
 <DkTWxmoD6v3ztHYmrA8to_9io62ZbjeWZph3g8bdaps=.27699623-05bd-4893-bbcb-aa4cc44ad382@github.com>
Message-ID: <2AYem1IPNgntTFzYJksJMwqeL6GyD9rWU_KiIeLUyKg=.1235976a-1394-4323-accf-cbc9ab54d626@github.com>

On Wed, 22 Oct 2025 10:42:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to the object allocation path to only allow direct allocation after failing TLAB allocation doing GCs.
>> 
>> Currently, when allocating an object, G1 (or actually any collector) first allocates from TLABs, then allocates from outside TLABs.
>> 
>> When G1 can't find space for a TLAB in the current region, it passes on control to `G1CollectedHeap::attempt_allocation[_slow]` that first tries to allocate that memory using a new region, or if that fails, do a GC. Potential allocation outside TLABs that would follow TLAB-allocation does the same.
>> 
>> G1's behavior to do a GC during failed TLAB allocation is problematic for the `UseGCOverheadLimit` functionality (https://bugs.openjdk.org/browse/JDK-8212084): if the GC overhead limit triggers in a TLAB allocation, it returns `null` for that TLAB allocation.
>> Control will be passed to outside-tlab allocation as described above. Since the garbage collections for TLAB allocations did free some memory (but because of exceeded gc overhead we returned null for the TLAB allocation), that allocation/collection for this outside-tlab allocation will succeed and return non-`null` to the mutator, effectively swallowing the information that GC overhead has been exceeded.
>> 
>> I split this out from the `UseGCOverheadLimit` change because I thought it is somewhat standalone, but I can merge it.
>> 
>> Testing: tier1-5, performance neutral after some tests
>> 
>> Hth,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * more parameter name changes, walulyai review

Maybe the title can be revised a bit -- sth like "G1: Disallow GC for TLAB allocation".

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27932#pullrequestreview-3365675897

From jsikstro at openjdk.org  Wed Oct 22 13:56:14 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 22 Oct 2025 13:56:14 GMT
Subject: RFR: 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
 [v2]
In-Reply-To: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
References: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
Message-ID: <uWb3hAk6qJfqXsUJC6v9Uzia5fcEEaKjFaYuogyY0RM=.3627cbd2-f2b1-48db-893b-4dc7b3c9fd38@github.com>

> Hello,
> 
> Parallel's MutableNUMASpace is the only GC interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used, and unsafe_max_tlab_alloc. It would be nice if Parallel's MutableNUMASpace could do without the Thread and instead find a thread-agnostic approach. By removing the need for the thread, it becomes possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs. Also, the lgrp_id that is stored in the Thread class should really have been moved to GCThreadLocalData after that concept was created, but with a thread-agnostic approach, the field can be removed entirely.
> 
> The current solution is not without problems. When a new allocation is made inside one of the LGRP spaces in MutableNUMASpace using cas_allocate(), the NUMA/LGRP id is polled and stored inside the Thread, and we only attempt to allocate on that LGRP. If allocation fails on the local LGRP, we do not try to allocate on any other (remote) LGRP(s). This fact is reflected in the TLAB accounting methods tlab_capacity, tlab_used, and unsafe_max_tlab_alloc, which only check how much memory is used, etc., for the LGRP matching the stored LGRP id in the Thread. This model breaks down when threads are allowed to migrate between different CPUs, and therefore also NUMA nodes, which might change the LGRP id.
> 
> For example, a system with two NUMA nodes gives us two LGRPs with ids 0 and 1. If a thread allocates most of its memory on LGRP 0 and then migrates to a CPU on LGRP 1, the thread will show that it allocated a significant amount of memory, but the used memory on the LGRP it is currently on could be very low. This would give a disproportionate allocation fraction. This is not a problem as the TLAB code accounts for this, but for a different reason entirely. The other way around could also be problematic. If a thread allocates very little memory on LGRP 0 and then migrates to LGRP 1, where another thread has allocated a lot of memory, the allocation fraction will be very low, when it could have a really high fraction if accounting for the used memory on its original LGRP.
> 
> A solution to both of these issues is to average the capacity, used, and available memory across all LGRPs for the TLAB accounting methods. This approach provides a more accurate and stable view of memory usage and availability, regardless of thread migration or imbalances in NUMA/LGRP allocation. However, there are trade-offs...

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

  unsafe_max_tlab_alloc must be aligned to MinObjAlignmentInBytes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27935/files
  - new: https://git.openjdk.org/jdk/pull/27935/files/703a7dcf..c8a2182f

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

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

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

From tschatzl at openjdk.org  Wed Oct 22 15:10:55 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 22 Oct 2025 15:10:55 GMT
Subject: RFR: 8370325: G1: Disallow GC for TLAB allocation [v3]
In-Reply-To: <2AYem1IPNgntTFzYJksJMwqeL6GyD9rWU_KiIeLUyKg=.1235976a-1394-4323-accf-cbc9ab54d626@github.com>
References: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
 <DkTWxmoD6v3ztHYmrA8to_9io62ZbjeWZph3g8bdaps=.27699623-05bd-4893-bbcb-aa4cc44ad382@github.com>
 <2AYem1IPNgntTFzYJksJMwqeL6GyD9rWU_KiIeLUyKg=.1235976a-1394-4323-accf-cbc9ab54d626@github.com>
Message-ID: <or1aRCVkMuAI3sD5ApH5Uc29BIr7MwlP1X1dKcJvxCc=.57602e05-5a53-4335-ba91-df3729ed367b@github.com>

On Wed, 22 Oct 2025 12:57:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Maybe the title can be revised a bit -- sth like "G1: Disallow GC for TLAB allocation".

Much better, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27932#issuecomment-3432896939

From kdnilsen at openjdk.org  Wed Oct 22 17:22:46 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 22 Oct 2025 17:22:46 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v28]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <Uj9m3_g8s-_EpLhtbEIs75BF7eUsLShQg1-85sYMOdw=.e994b4a3-c3cc-4db9-8556-fd412a46c6b9@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:

  Add sleep to CompressedClassSpaceSizeInJmapHeap.java test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/ee617c30..da92c344

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

  Stats: 2 lines in 1 file changed: 2 ins; 0 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 wkemper at openjdk.org  Wed Oct 22 21:17:58 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 22 Oct 2025 21:17:58 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
 <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
Message-ID: <rVC3Zah2_BBGsKyH3hUnJShcYCrl75zsP0dahR86Yas=.b971db3b-871d-4979-9ad6-081986a1207c@github.com>

On Fri, 17 Oct 2025 23:40:24 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Remove _gc_generation from ShenandoahHeap
>>  - Little cleanup, remove one active generation usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>>  - Fix build
>>  - Use existing _generation field instead of Heap::_gc_generation where possible
>>  - Only shenandoah vm operations participate in active/gc generation scheme
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp line 174:
> 
>> 172: // contained herein.
>> 173: void ShenandoahGenerationalEvacuationTask::promote_in_place(ShenandoahHeapRegion* region) {
>> 174:   assert(!_generation->is_old(), "Sanity check");
> 
> Would `assert(_generation->is_young()...` be too strong at line 174 for some reason? e.g. could `_generation` be `is_global()` here?
> 
> You could then confidently replace the `_heap->young_generation()` indirection at line 175 below with just `_generation`, also simplifying comprehension complexity & code maintainability.

Right, `_generation` could be global here. Global collections are allowed to promote in place.

> src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp line 55:
> 
>> 53:   explicit VM_ShenandoahOperation(ShenandoahGeneration* generation)
>> 54:   : _gc_id(GCId::current())
>> 55:   , _generation(generation) {
> 
> style question: shouldn't the comma go at the end of the previous line?

Yes (old habits).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2453370865
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2453372543

From wkemper at openjdk.org  Wed Oct 22 21:21:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 22 Oct 2025 21:21:39 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <Q8CsOHvb275UhtHxgGSq0jH_qIkDqmAlZcDeRrb2NiA=.93d20df1-7893-43f8-bbb2-ea5ac34b957a@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
 <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
 <Q8CsOHvb275UhtHxgGSq0jH_qIkDqmAlZcDeRrb2NiA=.93d20df1-7893-43f8-bbb2-ea5ac34b957a@github.com>
Message-ID: <V2LnQJsfA5Sqtqpi-ZMLayIbVUvMxF59PV24Hi8v2ak=.da56a3ae-4591-4e9a-bb97-fb8825d9d1ae@github.com>

On Wed, 22 Oct 2025 00:36:25 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 358:
>> 
>>> 356:     assert(_from_region != nullptr, "must set before work");
>>> 357:     assert(_heap->marking_context()->is_marked(p), "must be marked");
>>> 358:     assert(!_heap->marking_context()->allocated_after_mark_start(p), "must be truly marked");
>> 
>> Why not `_generation->complete_marking_context()...` with the help of a `_generation` field kept in the object? It would make the idiom uniform and consistent across all these closures.
>
> Or like you did below at line 784, perhaps `_heap->global_generation()->complete_marking_context()...` stashed in local `_ctx` field ?

The context here is only used for the assertion. I'll add an `assert(_heap->global_generation()->is_marking_complete())`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2453379755

From wkemper at openjdk.org  Wed Oct 22 23:12:33 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 22 Oct 2025 23:12:33 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
 <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
Message-ID: <rNUc1hBuOidwNeTg_mhe8YfcL7joW_t227s6kgy6RuA=.54b1717d-a1db-40bb-b27a-d2a5941d973a@github.com>

On Wed, 22 Oct 2025 01:05:28 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Remove _gc_generation from ShenandoahHeap
>>  - Little cleanup, remove one active generation usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>>  - Fix build
>>  - Use existing _generation field instead of Heap::_gc_generation where possible
>>  - Only shenandoah vm operations participate in active/gc generation scheme
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 851:
> 
>> 849:     }
>> 850: 
>> 851:     if (!_generation->is_global()) {
> 
> Is this ever `_generation->is_old()` ? I am guessing this is either global or young? I am guessing for the case of update_refs for a mixed collection we still pass in the `young` gen here?
> 
> It might be a good idea wherever we have a `_generation` field member in a class to indicate what it represents. In most cases, it's probably clear that it represents the generation subject to collection in that cycle. But for mixed collection sets, what does the `_generation` field represent?

I changed this to check if `_generation->is_young` because it will never be old here and this is more direct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2453545886

From wkemper at openjdk.org  Wed Oct 22 23:23:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 22 Oct 2025 23:23:23 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
 <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
Message-ID: <3hNmxXwDIQqbSuy_DwXM-JuiY4JYg_91rxy1uZEg_is=.621dbeaf-df56-4075-b43b-d1748f0dc7f2@github.com>

On Wed, 22 Oct 2025 01:21:30 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Remove _gc_generation from ShenandoahHeap
>>  - Little cleanup, remove one active generation usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>>  - Fix build
>>  - Use existing _generation field instead of Heap::_gc_generation where possible
>>  - Only shenandoah vm operations participate in active/gc generation scheme
>
> src/hotspot/share/gc/shenandoah/shenandoahMark.cpp line 82:
> 
>> 80: template<bool CANCELLABLE, StringDedupMode STRING_DEDUP>
>> 81: void ShenandoahMark::mark_loop(uint worker_id, TaskTerminator* terminator,
>> 82:                                ShenandoahGenerationType generation, StringDedup::Requests* const req) {
> 
> Since `ShenandoahMark` has a `_generation` data member with a `generation()` accessor, I'd rename the formal parameters of type `ShenandoahGenerationType` for all these methods from `generation` to `gen_type` or something like that to reduce confusion while reading the code.

Good point.

> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 1:
> 
>> 1: /*
> 
> Some of the spots here on where we need a completed marking context and where we are permitted to use a possibly in flight marking context isn't terribly clear. At some point, we should probably go through and clarify.

The `complete_marking_context` method just has an assertion in it that marking is complete. I believe the only code that need access to the incomplete marking context is the marking code itself.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2453555375
PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2453558370

From wkemper at openjdk.org  Wed Oct 22 23:30:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 22 Oct 2025 23:30:00 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v2]
In-Reply-To: <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <dcF3Fa23QwsLsMmPE6RxHN6x5cuA8LCaGIe_yTz2Y_8=.836dc85a-8954-4a2d-b8b3-7555cdcca6ab@github.com>
 <wV2CaGadli_lDTCT5ZMUXADn_7zzET1W6nn6pjgHXXc=.0844490a-32e9-4617-8b87-ec2462071b79@github.com>
Message-ID: <XMvbjrITvWRp0uQDLt6m8MrhdXTCj51hBw1SckZEoS4=.e588aebc-78d8-4ba0-a6f5-0e2db4d44fb3@github.com>

On Wed, 22 Oct 2025 01:43:50 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Remove _gc_generation from ShenandoahHeap
>>  - Little cleanup, remove one active generation usage
>>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>>  - Fix build
>>  - Use existing _generation field instead of Heap::_gc_generation where possible
>>  - Only shenandoah vm operations participate in active/gc generation scheme
>
> src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 152:
> 
>> 150:   StringDedup::Requests requests;
>> 151: 
>> 152:   // TODO: Why are we passing our own fields to our own method?
> 
> It's a method on our parent class which doesn't have a Terminator object handy.

I think it's mostly because other uses of this (public) method are from `MarkingTasks` which have a `Terminator` but not a `ShenandoahGeneration`. I deleted the TODO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27703#discussion_r2453568818

From tschatzl at openjdk.org  Thu Oct 23 07:08:20 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 23 Oct 2025 07:08:20 GMT
Subject: RFR: 8370325: G1: Disallow GC for TLAB allocation [v3]
In-Reply-To: <2AYem1IPNgntTFzYJksJMwqeL6GyD9rWU_KiIeLUyKg=.1235976a-1394-4323-accf-cbc9ab54d626@github.com>
References: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
 <DkTWxmoD6v3ztHYmrA8to_9io62ZbjeWZph3g8bdaps=.27699623-05bd-4893-bbcb-aa4cc44ad382@github.com>
 <2AYem1IPNgntTFzYJksJMwqeL6GyD9rWU_KiIeLUyKg=.1235976a-1394-4323-accf-cbc9ab54d626@github.com>
Message-ID: <MOJJm-rZiAWpZdEmMRk3JzzmBZe4-rIWpkujfvX8NTw=.fd4eb4c0-98dd-46a3-bef1-e6bd1298ba2e@github.com>

On Wed, 22 Oct 2025 12:57:24 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * more parameter name changes, walulyai review
>
> Maybe the title can be revised a bit -- sth like "G1: Disallow GC for TLAB allocation".

Thanks @albertnetymk @walulyai for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/27932#issuecomment-3435450345

From tschatzl at openjdk.org  Thu Oct 23 07:08:21 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 23 Oct 2025 07:08:21 GMT
Subject: Integrated: 8370325: G1: Disallow GC for TLAB allocation
In-Reply-To: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
References: <wgl0Q65Hpf6cBSUYOOaNsBtEuC1fQeHWqfZSWMqTJ6I=.c027c02e-49f6-442b-9e67-77b676e81b28@github.com>
Message-ID: <G8-VYiuY2cbzalDfRI289kkpzaPQac81vxVZzLrTovc=.8ecb7d5a-4841-4171-94c0-d39c9bed47a4@github.com>

On Wed, 22 Oct 2025 07:59:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to the object allocation path to only allow direct allocation after failing TLAB allocation doing GCs.
> 
> Currently, when allocating an object, G1 (or actually any collector) first allocates from TLABs, then allocates from outside TLABs.
> 
> When G1 can't find space for a TLAB in the current region, it passes on control to `G1CollectedHeap::attempt_allocation[_slow]` that first tries to allocate that memory using a new region, or if that fails, do a GC. Potential allocation outside TLABs that would follow TLAB-allocation does the same.
> 
> G1's behavior to do a GC during failed TLAB allocation is problematic for the `UseGCOverheadLimit` functionality (https://bugs.openjdk.org/browse/JDK-8212084): if the GC overhead limit triggers in a TLAB allocation, it returns `null` for that TLAB allocation.
> Control will be passed to outside-tlab allocation as described above. Since the garbage collections for TLAB allocations did free some memory (but because of exceeded gc overhead we returned null for the TLAB allocation), that allocation/collection for this outside-tlab allocation will succeed and return non-`null` to the mutator, effectively swallowing the information that GC overhead has been exceeded.
> 
> I split this out from the `UseGCOverheadLimit` change because I thought it is somewhat standalone, but I can merge it.
> 
> Testing: tier1-5, performance neutral after some tests
> 
> Hth,
>   Thomas

This pull request has now been integrated.

Changeset: 027aea9d
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/027aea9d2e0dff29fcd00fa7074ca955066929ec
Stats:     28 lines in 2 files changed: 9 ins; 5 del; 14 mod

8370325: G1: Disallow GC for TLAB allocation

Reviewed-by: iwalulya, ayang

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

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

From stefank at openjdk.org  Thu Oct 23 08:18:08 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 23 Oct 2025 08:18:08 GMT
Subject: RFR: 8369658: Client emulation mode sets MaxRAM too late [v2]
In-Reply-To: <tZ345kDmHX2HQTkvDjfQnnh-wRd3KEJ7cdH6tnKRKXU=.4e8157ca-0964-45f8-b6ab-ec0ac7e2216d@github.com>
References: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
 <tZ345kDmHX2HQTkvDjfQnnh-wRd3KEJ7cdH6tnKRKXU=.4e8157ca-0964-45f8-b6ab-ec0ac7e2216d@github.com>
Message-ID: <M_lwzs_kDX9QT0X85SbT20L_C5LWiO7Lbe-TNQwMECk=.d90134e4-9ed6-4861-bd41-162874524bc5@github.com>

On Tue, 14 Oct 2025 08:28:02 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> While working on the proposal for the potential deprecation of MaxRAM (see [JDK-8369347](https://bugs.openjdk.org/browse/JDK-8369347)) I saw that `CompilerConfig::ergo_initialize()` sets the value for `MaxRAM` after ergonomic heap sizing is already done, which is the only place in the VM that cares about `MaxRAM`. I suggest we move setting the value of `MaxRAM` to `Arguments::set_heap_size()` to fix this.
>> 
>> Even though the `MaxRAM` flag might be deprecated, the code should still account for the fact that client emulation mode might lower the maximum amount of physical memory that can be used for the Java heap. If the flag is removed, we'd still want to lower the maximum memory, so it makes sense to have the code in `Arguments::set_heap_size()` in both cases.
>> 
>> Testing:
>> * Oracle's tier1-2
>> * Local test with `java -XX:+NeverActAsServerClassMachine -Xlog:gc+init` to see that the lower limit is reflected in ergonomic heap sizing.
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment

Looks good. But the next step needs to be deprecate the client emulation mode.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27765#pullrequestreview-3368743381

From jsikstro at openjdk.org  Thu Oct 23 08:25:17 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 23 Oct 2025 08:25:17 GMT
Subject: RFR: 8369658: Client emulation mode sets MaxRAM too late [v2]
In-Reply-To: <MBCqBosLJPcwXU9NLXoK7zX8valcyW5X5yyEa5mXjVM=.47d729de-e9b2-4ba5-b955-0e2d286e2ece@github.com>
References: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
 <tZ345kDmHX2HQTkvDjfQnnh-wRd3KEJ7cdH6tnKRKXU=.4e8157ca-0964-45f8-b6ab-ec0ac7e2216d@github.com>
 <MBCqBosLJPcwXU9NLXoK7zX8valcyW5X5yyEa5mXjVM=.47d729de-e9b2-4ba5-b955-0e2d286e2ece@github.com>
Message-ID: <qaxPo3pci88DpH1gLySDB3U_iCgL5FrpRceP-_jEcWU=.af337155-eb5c-4135-b3b0-3505726bbce4@github.com>

On Tue, 14 Oct 2025 09:07:08 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment
>
> Marked as reviewed by aboldtch (Reviewer).

Thank you for the reviews! @xmas92 @stefank

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

PR Comment: https://git.openjdk.org/jdk/pull/27765#issuecomment-3435696840

From jsikstro at openjdk.org  Thu Oct 23 08:25:18 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 23 Oct 2025 08:25:18 GMT
Subject: Integrated: 8369658: Client emulation mode sets MaxRAM too late
In-Reply-To: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
References: <eFFGg71RcNNfH3nSBjEn6CYqfMbi0_k_LFLWItG-9eQ=.f417d049-0fae-4fc8-bd2e-a7a2f15cb127@github.com>
Message-ID: <Ni19tAFzhjDdJEypwlhZPmOO7Z0Fp_SHuauRqGwe0fk=.cdb759eb-65e3-4499-ba77-1e76e48ad2ce@github.com>

On Mon, 13 Oct 2025 11:25:04 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> While working on the proposal for the potential deprecation of MaxRAM (see [JDK-8369347](https://bugs.openjdk.org/browse/JDK-8369347)) I saw that `CompilerConfig::ergo_initialize()` sets the value for `MaxRAM` after ergonomic heap sizing is already done, which is the only place in the VM that cares about `MaxRAM`. I suggest we move setting the value of `MaxRAM` to `Arguments::set_heap_size()` to fix this.
> 
> Even though the `MaxRAM` flag might be deprecated, the code should still account for the fact that client emulation mode might lower the maximum amount of physical memory that can be used for the Java heap. If the flag is removed, we'd still want to lower the maximum memory, so it makes sense to have the code in `Arguments::set_heap_size()` in both cases.
> 
> Testing:
> * Oracle's tier1-2
> * Local test with `java -XX:+NeverActAsServerClassMachine -Xlog:gc+init` to see that the lower limit is reflected in ergonomic heap sizing.

This pull request has now been integrated.

Changeset: dcf46a0a
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dcf46a0a195d7386ed0bc872f60eb9c586425cc8
Stats:     32 lines in 3 files changed: 23 ins; 5 del; 4 mod

8369658: Client emulation mode sets MaxRAM too late

Reviewed-by: aboldtch, stefank

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

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

From jsikstro at openjdk.org  Thu Oct 23 08:53:25 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 23 Oct 2025 08:53:25 GMT
Subject: RFR: 8369346: Remove default value of and deprecate the MaxRAM flag
Message-ID: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>

Hello,

Please see the CSR for a more detailed explanation and specific information regarding the deprecation of the flag. To summarize, the JVM is well-equiped to detect system memory and handle potential truncation errors (see [JDK-8367413 ](https://bugs.openjdk.org/browse/JDK-8367413)), making MaxRAM largely redundant. Removing the default value from MaxRAM mainly impacts systems with more memory than the default (128GB on 64-bit systems and 4GB on 32-bit systems) that are running with `-XX:-UseCompressedOops` or `-XX:+UseZGC`, which disable compressed oops. We recommend users to use well-supported flags such as `-Xms` and `-Xmx` to influence heap sizing instead.

MaxRAM is used to a very small extent to influence memory allocation in JDK tests, where MaxRAMPercentage is much more common. When MaxRAM is eventually obsoleted, the few affected tests will need to be updated or use alternative flags.

Testing:
* Oracle's tier1-8

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

Commit messages:
 - 8369346: Remove default value of and deprecate the MaxRAM flag

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

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

From jsikstro at openjdk.org  Thu Oct 23 09:04:21 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 23 Oct 2025 09:04:21 GMT
Subject: RFR: 8369346: Remove default value of and deprecate the MaxRAM
 flag [v2]
In-Reply-To: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
References: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
Message-ID: <OvoPePoHT02JiHRAPK4J-hmXD6LlhOSxiZkkWED_fPc=.b0491706-ccc9-4ae0-9284-6b962f2cdcb3@github.com>

> Hello,
> 
> Please see the CSR for a more detailed explanation and specific information regarding the deprecation of the flag. To summarize, the JVM is well-equiped to detect system memory and handle potential truncation errors (see [JDK-8367413 ](https://bugs.openjdk.org/browse/JDK-8367413)), making MaxRAM largely redundant. Removing the default value from MaxRAM mainly impacts systems with more memory than the default (128GB on 64-bit systems and 4GB on 32-bit systems) that are running with `-XX:-UseCompressedOops` or `-XX:+UseZGC`, which disable compressed oops. We recommend users to use well-supported flags such as `-Xms` and `-Xmx` to influence heap sizing instead.
> 
> MaxRAM is used to a very small extent to influence memory allocation in JDK tests, where MaxRAMPercentage is much more common. When MaxRAM is eventually obsoleted, the few affected tests will need to be updated or use alternative flags.
> 
> Testing:
> * Oracle's tier1-8

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

  Move MaxRAM to deprecated section in java.md

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27952/files
  - new: https://git.openjdk.org/jdk/pull/27952/files/c9b672f6..03188828

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

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

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

From tschatzl at openjdk.org  Thu Oct 23 09:07:49 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 23 Oct 2025 09:07:49 GMT
Subject: RFR: 8212084: Implement UseGCOverheadLimit for G1
Message-ID: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>

Hi all,

  please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).

The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.

What is important here is how this works (derived from the Parallel GC implementation):

* check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a successive amount of GCs.
* keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.

Testing: tier1-5 without any OOMEs due to this feature, test case

Thanks,
  Thomas

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

Commit messages:
 - 8212084

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

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

From fandreuzzi at openjdk.org  Thu Oct 23 10:08:06 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 23 Oct 2025 10:08:06 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit
In-Reply-To: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
Message-ID: <FV2cVbxIJYqD4NfBeQOGqD13jLhNMY25eUUkdgoHABQ=.926f9d21-073b-456a-8847-d7597aa6fab4@github.com>

On Thu, 23 Oct 2025 07:11:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
> 
> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
> 
> What is important here is how this works (derived from the Parallel GC implementation):
> 
> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a successive amount of GCs.
> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
> 
> Testing: tier1-5 without any OOMEs due to this feature, test case
> 
> Thanks,
>   Thomas

test/hotspot/jtreg/gc/TestUseGCOverheadLimit.java line 82:

> 80:     System.out.println(output.getStdout());
> 81: 
> 82:     Asserts.assertTrue(output.getStdout().indexOf("GC Overhead Limit exceeded too often (5).") != -1,

Why not `OutputAnalyzer#stdoutShouldContain` here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27950#discussion_r2454595619

From iwalulya at openjdk.org  Thu Oct 23 11:01:04 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 23 Oct 2025 11:01:04 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit
In-Reply-To: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
Message-ID: <AtuHWcYRCprOGEWvLDKpR9FxRlyqPS2KZJhpWm0FgQY=.c418790b-6448-44e3-a46c-c9d69b4424ae@github.com>

On Thu, 23 Oct 2025 07:11:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
> 
> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
> 
> What is important here is how this works (derived from the Parallel GC implementation):
> 
> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a successive amount of GCs.
> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
> 
> Testing: tier1-5 without any OOMEs due to this feature, test case
> 
> Thanks,
>   Thomas

Some suggestions

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

> 974: 
> 975:   if (UseGCOverheadLimit) {
> 976:     bool little_mutator_time = (_policy->analytics()->long_term_gc_time_ratio() * 100) >= GCTimeLimit;

Suggestion:

    bool gc_time_over_limit = (_policy->analytics()->long_term_gc_time_ratio() * 100) >= GCTimeLimit;

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

> 976:     bool little_mutator_time = (_policy->analytics()->long_term_gc_time_ratio() * 100) >= GCTimeLimit;
> 977:     double free_space_percent = percent_of(num_available_regions() * G1HeapRegion::GrainBytes, max_capacity());
> 978:     bool little_free_space = free_space_percent < GCHeapFreeLimit;

Suggestion:

    bool free_space_below_limit = free_space_percent < GCHeapFreeLimit;

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

> 1000:                                                             bool maximal_compaction,
> 1001:                                                             bool expect_null_mutator_alloc_region) {
> 1002:   // Skip allocation if GC overhead has been exceeded to let the mutator run into

Suggestion:

  // Skip allocation if GC overhead limit has been exceeded to let the mutator run into

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

PR Review: https://git.openjdk.org/jdk/pull/27950#pullrequestreview-3369333247
PR Review Comment: https://git.openjdk.org/jdk/pull/27950#discussion_r2454708066
PR Review Comment: https://git.openjdk.org/jdk/pull/27950#discussion_r2454710623
PR Review Comment: https://git.openjdk.org/jdk/pull/27950#discussion_r2454716115

From ayang at openjdk.org  Thu Oct 23 11:10:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 23 Oct 2025 11:10:12 GMT
Subject: RFR: 8369346: Remove default value of and deprecate the MaxRAM
 flag [v2]
In-Reply-To: <OvoPePoHT02JiHRAPK4J-hmXD6LlhOSxiZkkWED_fPc=.b0491706-ccc9-4ae0-9284-6b962f2cdcb3@github.com>
References: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
 <OvoPePoHT02JiHRAPK4J-hmXD6LlhOSxiZkkWED_fPc=.b0491706-ccc9-4ae0-9284-6b962f2cdcb3@github.com>
Message-ID: <K985PNrEcJx874X6w1CrUVixl65x42h8IoYJQwtiK0A=.bfa31ede-c00b-443a-8254-afc49637382e@github.com>

On Thu, 23 Oct 2025 09:04:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Please see the CSR for a more detailed explanation and specific information regarding the deprecation of the flag. To summarize, the JVM is well-equiped to detect system memory and handle potential truncation errors (see [JDK-8367413 ](https://bugs.openjdk.org/browse/JDK-8367413)), making MaxRAM largely redundant. Removing the default value from MaxRAM mainly impacts systems with more memory than the default (128GB on 64-bit systems and 4GB on 32-bit systems) that are running with `-XX:-UseCompressedOops` or `-XX:+UseZGC`, which disable compressed oops. We recommend users to use well-supported flags such as `-Xms` and `-Xmx` to influence heap sizing instead.
>> 
>> MaxRAM is used to a very small extent to influence memory allocation in JDK tests, where MaxRAMPercentage is much more common. When MaxRAM is eventually obsoleted, the few affected tests will need to be updated or use alternative flags.
>> 
>> Testing:
>> * Oracle's tier1-8
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move MaxRAM to deprecated section in java.md

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27952#pullrequestreview-3369394093

From ayang at openjdk.org  Thu Oct 23 11:13:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 23 Oct 2025 11:13:14 GMT
Subject: RFR: 8370406: Parallel: Refactor
 ParCompactionManager::mark_and_push
In-Reply-To: <yNFxkkvXgK9V6m5p0HVzR9juUwukhdlxIsydKH2wG84=.276c6bfa-ec95-422c-853c-f66cccc728b5@github.com>
References: <yNFxkkvXgK9V6m5p0HVzR9juUwukhdlxIsydKH2wG84=.276c6bfa-ec95-422c-853c-f66cccc728b5@github.com>
Message-ID: <TAM10gftYqYgSZk5PcLwak2WVBSqEtcYehBYphrZXOs=.212750ea-f18d-4ee8-add4-6b14a9846c8d@github.com>

On Wed, 22 Oct 2025 08:26:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to reduce indentation level and inlining a single-caller method.
> 
> Test: tier1-3

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27933#issuecomment-3436355704

From ayang at openjdk.org  Thu Oct 23 11:13:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 23 Oct 2025 11:13:15 GMT
Subject: Integrated: 8370406: Parallel: Refactor
 ParCompactionManager::mark_and_push
In-Reply-To: <yNFxkkvXgK9V6m5p0HVzR9juUwukhdlxIsydKH2wG84=.276c6bfa-ec95-422c-853c-f66cccc728b5@github.com>
References: <yNFxkkvXgK9V6m5p0HVzR9juUwukhdlxIsydKH2wG84=.276c6bfa-ec95-422c-853c-f66cccc728b5@github.com>
Message-ID: <7IRABhw8S1O4k0OIk9eSiyVHhpB_Uz8BBAOFQyR8NGk=.23477273-09e9-457b-be03-cae4c4119a1c@github.com>

On Wed, 22 Oct 2025 08:26:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to reduce indentation level and inlining a single-caller method.
> 
> Test: tier1-3

This pull request has now been integrated.

Changeset: 5a83d6a8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a83d6a8355b36cffcf5945b9c6bcfc7aebdd136
Stats:     33 lines in 2 files changed: 11 ins; 14 del; 8 mod

8370406: Parallel: Refactor ParCompactionManager::mark_and_push

Reviewed-by: fandreuzzi, iwalulya

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

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

From tschatzl at openjdk.org  Thu Oct 23 11:53:37 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 23 Oct 2025 11:53:37 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v2]
In-Reply-To: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
Message-ID: <yYGaBQl_7jSvgXvobARk2QoL94MNviMTbAtpp5E1Udc=.8f870a1d-edaf-4da8-86de-38b319e80cb0@github.com>

> Hi all,
> 
>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
> 
> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
> 
> What is important here is how this works (derived from the Parallel GC implementation):
> 
> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
> 
> Testing: tier1-5 without any OOMEs due to this feature, test case
> 
> Thanks,
>   Thomas

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

  * walulyai review
  * fandreuzzi review
  * some additional comment tweaks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27950/files
  - new: https://git.openjdk.org/jdk/pull/27950/files/389e5a26..a8663e1b

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

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

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

From tschatzl at openjdk.org  Thu Oct 23 12:22:22 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 23 Oct 2025 12:22:22 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v3]
In-Reply-To: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
Message-ID: <F4h-Yhr6v0ty67PbRsTbOjOS-bPt_1j5YiyZKyxuDqA=.e7801ee0-5f02-467f-a406-b063a09ce183@github.com>

> Hi all,
> 
>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
> 
> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
> 
> What is important here is how this works (derived from the Parallel GC implementation):
> 
> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
> 
> Testing: tier1-5 without any OOMEs due to this feature, test case
> 
> Thanks,
>   Thomas

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

  * more comment fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27950/files
  - new: https://git.openjdk.org/jdk/pull/27950/files/a8663e1b..ac3223fa

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

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

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

From iwalulya at openjdk.org  Thu Oct 23 12:22:22 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 23 Oct 2025 12:22:22 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v3]
In-Reply-To: <F4h-Yhr6v0ty67PbRsTbOjOS-bPt_1j5YiyZKyxuDqA=.e7801ee0-5f02-467f-a406-b063a09ce183@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
 <F4h-Yhr6v0ty67PbRsTbOjOS-bPt_1j5YiyZKyxuDqA=.e7801ee0-5f02-467f-a406-b063a09ce183@github.com>
Message-ID: <qtmz__Tm9RBt7x8fJIDn7rGNz4s46k76NRyZXDWmrTI=.fa0a7a1b-3bfd-41cf-96da-5f3672253893@github.com>

On Thu, 23 Oct 2025 12:19:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
>> 
>> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
>> 
>> What is important here is how this works (derived from the Parallel GC implementation):
>> 
>> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
>> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
>> 
>> Testing: tier1-5 without any OOMEs due to this feature, test case
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * more comment fixes

Looks good!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27950#pullrequestreview-3369648734

From fandreuzzi at openjdk.org  Thu Oct 23 13:07:45 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 23 Oct 2025 13:07:45 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v3]
In-Reply-To: <F4h-Yhr6v0ty67PbRsTbOjOS-bPt_1j5YiyZKyxuDqA=.e7801ee0-5f02-467f-a406-b063a09ce183@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
 <F4h-Yhr6v0ty67PbRsTbOjOS-bPt_1j5YiyZKyxuDqA=.e7801ee0-5f02-467f-a406-b063a09ce183@github.com>
Message-ID: <eYekx3QJHmS7e4e_iCFQxyel2DfNrbw510BwN20vwGM=.d6bb85da-cc2e-4c42-8d9e-d793e150b985@github.com>

On Thu, 23 Oct 2025 12:22:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
>> 
>> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
>> 
>> What is important here is how this works (derived from the Parallel GC implementation):
>> 
>> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
>> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
>> 
>> Testing: tier1-5 without any OOMEs due to this feature, test case
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * more comment fixes

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27950#pullrequestreview-3369851985

From ayang at openjdk.org  Thu Oct 23 13:25:26 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 23 Oct 2025 13:25:26 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v3]
In-Reply-To: <F4h-Yhr6v0ty67PbRsTbOjOS-bPt_1j5YiyZKyxuDqA=.e7801ee0-5f02-467f-a406-b063a09ce183@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
 <F4h-Yhr6v0ty67PbRsTbOjOS-bPt_1j5YiyZKyxuDqA=.e7801ee0-5f02-467f-a406-b063a09ce183@github.com>
Message-ID: <f5ck3YOJMJV2pF55IFSFhAx4BlJjcM7ifb4EFHkS3OU=.d7b8792f-32f8-4a0f-a1bd-c1f78de3c853@github.com>

On Thu, 23 Oct 2025 12:22:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
>> 
>> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
>> 
>> What is important here is how this works (derived from the Parallel GC implementation):
>> 
>> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
>> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
>> 
>> Testing: tier1-5 without any OOMEs due to this feature, test case
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * more comment fixes

Marked as reviewed by ayang (Reviewer).

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 178:

> 176:   // memory (<= GCHeapFreeLimit) so that applications can exit gracefully or try
> 177:   // to keep running by easing off memory.
> 178:   static uintx _gc_overhead_counter;        // The amount of successive times we were over the limits.

I feel this field is more like a non-static member. YMMV.

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

PR Review: https://git.openjdk.org/jdk/pull/27950#pullrequestreview-3369932781
PR Review Comment: https://git.openjdk.org/jdk/pull/27950#discussion_r2455123299

From tschatzl at openjdk.org  Thu Oct 23 14:05:19 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 23 Oct 2025 14:05:19 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v4]
In-Reply-To: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
Message-ID: <OWVKv0L7MCja_7quSrmjeed38bEsG0i2yyEGqD7M7H8=.6906ab73-fecd-46d6-9ef3-7e8521b3c311@github.com>

> Hi all,
> 
>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
> 
> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
> 
> What is important here is how this works (derived from the Parallel GC implementation):
> 
> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
> 
> Testing: tier1-5 without any OOMEs due to this feature, test case
> 
> Thanks,
>   Thomas

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

  * reduce indentation in update_gc_overhead_limit_exceeded(), remove some unnecessary return
  * better name for update_gc_overhead_limit_exceeded()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27950/files
  - new: https://git.openjdk.org/jdk/pull/27950/files/ac3223fa..03334385

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

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

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

From kdnilsen at openjdk.org  Thu Oct 23 14:11:16 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 23 Oct 2025 14:11:16 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v29]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <2l4P4pkKeL63Muti7IZhWjXpqBqSxwEoOogPijXY7dE=.242f9bf9-96cd-42d0-91eb-8b403d6279a4@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:

  Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/da92c344..b107bc5c

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

  Stats: 26 lines in 1 file changed: 20 ins; 0 del; 6 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 syan at openjdk.org  Thu Oct 23 14:26:10 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 23 Oct 2025 14:26:10 GMT
Subject: RFR: 8370501:
 vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java
 intermittent timed out
Message-ID: <TmKN0TrkEFKoMAFMRotfxrpo3Lz2GMtjXOQ-5Zoj73g=.ae103b1e-1030-446a-908d-402d7afc1b2d@github.com>

Hi all,

We found that vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java intermittent timed out when the timeout factor is seted to 1, [JDK-8368668](https://bugs.openjdk.org/browse/JDK-8368668) missed fix this test. Although [JDK-8369491](https://bugs.openjdk.org/browse/JDK-8369491) has revert the default TIMEOUT_FACTOR back to 1. but I think it's necessary to make test run pass steady with TIMEOUT_FACTOR set to 1.

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

Commit messages:
 - 8370501: vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java intermittent timed out

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

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

From tschatzl at openjdk.org  Thu Oct 23 14:48:08 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 23 Oct 2025 14:48:08 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v5]
In-Reply-To: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
Message-ID: <nMzn0-OPLhbz74Q4BOq0hnT9CBNfYHZIhEW5UJzPuv8=.10d61ebf-766f-44eb-ba2b-b2fe73530485@github.com>

> Hi all,
> 
>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
> 
> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
> 
> What is important here is how this works (derived from the Parallel GC implementation):
> 
> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
> 
> Testing: tier1-5 without any OOMEs due to this feature, test case
> 
> Thanks,
>   Thomas

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

  * make _gc_overhead_counter non-static

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27950/files
  - new: https://git.openjdk.org/jdk/pull/27950/files/03334385..bdc9663b

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

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

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

From kdnilsen at openjdk.org  Thu Oct 23 16:28:31 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 23 Oct 2025 16:28:31 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v30]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <CddJy1vG993fIG_dQcqZdM1TvBbfbi518cE3Fppd7Wo=.f149e9b9-aa3f-444f-a201-b641ab76297a@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:

  fix errors in CompressedClassSpaceSizeInJmapHeap.java

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

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

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

  Stats: 4 lines in 1 file changed: 1 ins; 0 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 wkemper at openjdk.org  Thu Oct 23 17:10:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 23 Oct 2025 17:10:36 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v3]
In-Reply-To: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
Message-ID: <l7ycAU0OtZvP-RJ29EP3MW07-pzEPvGZ8R0muBvOcuE=.072746d3-6907-4877-8240-1c03c44fbee9@github.com>

> There are certain code paths in Shenandoah's generational mode that need to _know_ which generation is being collected, but it is not possible to pass this information on the stack (barriers, for example). To address this, we introduced an `_active_generation` member in `ShenandoahHeap`. Over time, the usage of this field grew beyond its intended purpose and we began to have issues where not all threads would see a consistent value for this field. To address _this_ issue, we added another field `_gc_generation` which was only meant to be used by GC threads. At this point, we have three different ways to determine which generation is being collected: the _active_ generation, the _gc_ generation, and the usual function parameters and member fields of the gc components. This PR removes `_gc_generation` and reduces the use of `_active_generation` to only those places where it is not possible to get this information from other means (barriers, mostly). All GC components that can have th
 is information passed through function calls, now do so.

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

 - More cleanup, review feedback
 - Some cleanup, review feedback
 - Fix idiosyncratic formatting
 - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
 - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
 - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
 - Remove _gc_generation from ShenandoahHeap
 - Little cleanup, remove one active generation usage
 - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
 - Finish removing usages of gc_generation, start on reducing usages of active_generation
 - ... and 3 more: https://git.openjdk.org/jdk/compare/45e145fa...d6238476

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

Changes: https://git.openjdk.org/jdk/pull/27703/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27703&range=02
  Stats: 522 lines in 32 files changed: 121 ins; 161 del; 240 mod
  Patch: https://git.openjdk.org/jdk/pull/27703.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27703/head:pull/27703

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

From ysr at openjdk.org  Thu Oct 23 17:45:23 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 23 Oct 2025 17:45:23 GMT
Subject: RFR: 8369068: GenShen: Generations still aren't reconciled
 assertion failure [v3]
In-Reply-To: <l7ycAU0OtZvP-RJ29EP3MW07-pzEPvGZ8R0muBvOcuE=.072746d3-6907-4877-8240-1c03c44fbee9@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
 <l7ycAU0OtZvP-RJ29EP3MW07-pzEPvGZ8R0muBvOcuE=.072746d3-6907-4877-8240-1c03c44fbee9@github.com>
Message-ID: <9N0e9G1mJKNpBv7HEZLiBdOAkgDG8buiCeRxNcXTaxQ=.b2b821fb-530b-4768-bf35-acc9cd58bb82@github.com>

On Thu, 23 Oct 2025 17:10:36 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> There are certain code paths in Shenandoah's generational mode that need to _know_ which generation is being collected, but it is not possible to pass this information on the stack (barriers, for example). To address this, we introduced an `_active_generation` member in `ShenandoahHeap`. Over time, the usage of this field grew beyond its intended purpose and we began to have issues where not all threads would see a consistent value for this field. To address _this_ issue, we added another field `_gc_generation` which was only meant to be used by GC threads. At this point, we have three different ways to determine which generation is being collected: the _active_ generation, the _gc_ generation, and the usual function parameters and member fields of the gc components. This PR removes `_gc_generation` and reduces the use of `_active_generation` to only those places where it is not possible to get this information from other means (barriers, mostly). All GC components that can have t
 his information passed through function calls, now do so.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - More cleanup, review feedback
>  - Some cleanup, review feedback
>  - Fix idiosyncratic formatting
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Remove _gc_generation from ShenandoahHeap
>  - Little cleanup, remove one active generation usage
>  - Merge remote-tracking branch 'jdk/master' into reduce-gc_generation-usage
>  - Finish removing usages of gc_generation, start on reducing usages of active_generation
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/45e145fa...d6238476

?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27703#pullrequestreview-3371556400

From wkemper at openjdk.org  Thu Oct 23 19:09:58 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 23 Oct 2025 19:09:58 GMT
Subject: Integrated: 8369068: GenShen: Generations still aren't reconciled
 assertion failure
In-Reply-To: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
References: <ujrjZVhsGI5Fko-14nHUjK4-zn0eHN3GYkFPZx8e9qE=.612b8f6c-00e3-4ec7-bc99-ee34762a3555@github.com>
Message-ID: <NamhS8lMjzk7AG8CrVtp7nXS2rJr6ZD41CQeyiJeX_Y=.4300d85b-56f2-47b0-a1a8-9ea1db0d5832@github.com>

On Wed, 8 Oct 2025 19:26:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

> There are certain code paths in Shenandoah's generational mode that need to _know_ which generation is being collected, but it is not possible to pass this information on the stack (barriers, for example). To address this, we introduced an `_active_generation` member in `ShenandoahHeap`. Over time, the usage of this field grew beyond its intended purpose and we began to have issues where not all threads would see a consistent value for this field. To address _this_ issue, we added another field `_gc_generation` which was only meant to be used by GC threads. At this point, we have three different ways to determine which generation is being collected: the _active_ generation, the _gc_ generation, and the usual function parameters and member fields of the gc components. This PR removes `_gc_generation` and reduces the use of `_active_generation` to only those places where it is not possible to get this information from other means (barriers, mostly). All GC components that can have th
 is information passed through function calls, now do so.

This pull request has now been integrated.

Changeset: b2e431a1
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2e431a1cb22b78eca396ac1d97e6c272de72aa9
Stats:     522 lines in 32 files changed: 121 ins; 161 del; 240 mod

8369068: GenShen: Generations still aren't reconciled assertion failure

Reviewed-by: ysr, kdnilsen

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

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

From wkemper at openjdk.org  Thu Oct 23 22:53:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 23 Oct 2025 22:53:18 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures
Message-ID: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>

Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.

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

Commit messages:
 - Actually log number of objects and their total size that failed promotion
 - Track and report number of objects and their total size that failed promotion

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

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

From wkemper at openjdk.org  Thu Oct 23 22:56:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 23 Oct 2025 22:56:13 GMT
Subject: RFR: 8370521: GenShen: Various code cleanup related to promotion
Message-ID: <fLqV6-Ycz0uhdc0ayoGQj5GpWnCmD-bo6JGDfg8UELU=.3f4698f2-c32b-4454-be42-52ed6d737ba3@github.com>

* Use more log tags for finer grained control over debug output. 
* Add instrumentation for plab and cset decisions
* Fix typos in comments and minor formatting issues
* Rename some methods and variables for easier reading

There are no behavioral changes here. These changes were hoisted from https://github.com/openjdk/jdk/pull/27632 to facilitate its review.

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

Commit messages:
 - Use tags to control log volume, rename methods in collection set, general cleanup

Changes: https://git.openjdk.org/jdk/pull/27963/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370521
  Stats: 75 lines in 12 files changed: 18 ins; 10 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/27963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27963/head:pull/27963

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

From kdnilsen at openjdk.org  Fri Oct 24 03:41:50 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 03:41:50 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v31]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <G9pq0QcX_t3_O_piD3HIbqfBhiVkZAhzhzAmO838WdQ=.148b7a66-ee59-4212-ae2a-6da19faad7cc@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:

  Rework implementation of CompressedClassSpaceSizeInJmapHeap.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/3b56759c..467e7514

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

  Stats: 27 lines in 1 file changed: 1 ins; 17 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 tschatzl at openjdk.org  Fri Oct 24 05:19:03 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Oct 2025 05:19:03 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v5]
In-Reply-To: <nMzn0-OPLhbz74Q4BOq0hnT9CBNfYHZIhEW5UJzPuv8=.10d61ebf-766f-44eb-ba2b-b2fe73530485@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
 <nMzn0-OPLhbz74Q4BOq0hnT9CBNfYHZIhEW5UJzPuv8=.10d61ebf-766f-44eb-ba2b-b2fe73530485@github.com>
Message-ID: <wnnnAcBV8eDtu1xFOJ67r5Aq7YdtNT84ZxkNxXMIpTg=.39974fe3-16fe-4c7b-ad88-84b639125e22@github.com>

On Thu, 23 Oct 2025 14:48:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
>> 
>> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
>> 
>> What is important here is how this works (derived from the Parallel GC implementation):
>> 
>> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
>> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
>> 
>> Testing: tier1-5 without any OOMEs due to this feature, test case
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * make _gc_overhead_counter non-static

Also ran up to tier8 in our CI with no additional issues afaict.

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

PR Comment: https://git.openjdk.org/jdk/pull/27950#issuecomment-3441096204

From tschatzl at openjdk.org  Fri Oct 24 05:58:01 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 24 Oct 2025 05:58:01 GMT
Subject: RFR: 8370501:
 vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java
 intermittent timed out
In-Reply-To: <TmKN0TrkEFKoMAFMRotfxrpo3Lz2GMtjXOQ-5Zoj73g=.ae103b1e-1030-446a-908d-402d7afc1b2d@github.com>
References: <TmKN0TrkEFKoMAFMRotfxrpo3Lz2GMtjXOQ-5Zoj73g=.ae103b1e-1030-446a-908d-402d7afc1b2d@github.com>
Message-ID: <6Kwe4gf9ucL4DXdmH5usxtVCxFaeNCHniIia4hrf9Us=.4f33baaf-0911-4f6b-b08c-b2828bcbb45b@github.com>

On Thu, 23 Oct 2025 14:18:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> We found that vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java intermittent timed out when the timeout factor is seted to 1, [JDK-8368668](https://bugs.openjdk.org/browse/JDK-8368668) missed fix this test. Although [JDK-8369491](https://bugs.openjdk.org/browse/JDK-8369491) has revert the default TIMEOUT_FACTOR back to 1. but I think it's necessary to make test run pass steady with TIMEOUT_FACTOR set to 1.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27954#pullrequestreview-3374666923

From aboldtch at openjdk.org  Fri Oct 24 06:49:20 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 24 Oct 2025 06:49:20 GMT
Subject: RFR: 8351137: ZGC: Improve ZValueStorage alignment support [v6]
In-Reply-To: <GNS93cR60yXhAg3e7xq700RXmu-pYa6muIwmfJIBrac=.f1991bdf-d6fc-4255-8f04-c5717455baa6@github.com>
References: <GNS93cR60yXhAg3e7xq700RXmu-pYa6muIwmfJIBrac=.f1991bdf-d6fc-4255-8f04-c5717455baa6@github.com>
Message-ID: <PiSiL1-Ldc2LhdYnQmSO-BdgfhcWjdS8w6xooLNuzNM=.7808ac30-b860-4054-ab9b-720833aef2b6@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 six additional commits since the last revision:

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

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

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

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

  Stats: 36081 lines in 862 files changed: 21933 ins; 9676 del; 4472 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 aboldtch at openjdk.org  Fri Oct 24 06:49:39 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 24 Oct 2025 06:49:39 GMT
Subject: RFR: 8367317: ZGC:
 ZVirtualMemoryReserver::force_reserve_discontiguous arithmetic underflow [v5]
In-Reply-To: <MrtRg-MtrMA5rRk0qu4Jd2tTJuMdEVi43XeQF05jUtI=.6ebb93f7-39d1-4f13-aaff-db62d99a0846@github.com>
References: <MrtRg-MtrMA5rRk0qu4Jd2tTJuMdEVi43XeQF05jUtI=.6ebb93f7-39d1-4f13-aaff-db62d99a0846@github.com>
Message-ID: <FF_Qo0ETqYuERkniXwzoko8dHvLc28-Lv7zVfuVojLE=.b24806c7-7ad7-4ea4-aa46-544cb1dba0a4@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 five additional commits since the last revision:

 - Merge tag 'jdk-26+21' into JDK-8367317
   
   Added tag jdk-26+21 for changeset 3e20a939
 - Merge tag 'jdk-26+19' into JDK-8367317
   
   Added tag jdk-26+19 for changeset b37a1a33
 - 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/da962d1f..5338f590

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

  Stats: 36081 lines in 862 files changed: 21933 ins; 9676 del; 4472 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 fandreuzzi at openjdk.org  Fri Oct 24 08:29:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 24 Oct 2025 08:29:05 GMT
Subject: RFR: 8370521: GenShen: Various code cleanup related to promotion
In-Reply-To: <fLqV6-Ycz0uhdc0ayoGQj5GpWnCmD-bo6JGDfg8UELU=.3f4698f2-c32b-4454-be42-52ed6d737ba3@github.com>
References: <fLqV6-Ycz0uhdc0ayoGQj5GpWnCmD-bo6JGDfg8UELU=.3f4698f2-c32b-4454-be42-52ed6d737ba3@github.com>
Message-ID: <L0DgwDXOqYbVOCTxKL6MNT520SD69qhSpfMEQM4QsFo=.ed8a96c5-e713-457d-836b-6513b2b8c402@github.com>

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

> * Use more log tags for finer grained control over debug output. 
> * Add instrumentation for plab and cset decisions
> * Fix typos in comments and minor formatting issues
> * Rename some methods and variables for easier reading
> 
> There are no behavioral changes here. These changes were hoisted from https://github.com/openjdk/jdk/pull/27632 to facilitate its review.

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27963#pullrequestreview-3375081429

From fandreuzzi at openjdk.org  Fri Oct 24 08:33:03 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 24 Oct 2025 08:33:03 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures
In-Reply-To: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
Message-ID: <z8ZK7MJ5f3QIYxP2fB7lMqUncuY7cgOuoQMCJZ55thQ=.43fce6b2-28a8-46aa-884a-11e63a2ce911@github.com>

On Thu, 23 Oct 2025 22:46:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.

Marked as reviewed by fandreuzzi (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27962#pullrequestreview-3375098543

From ayang at openjdk.org  Fri Oct 24 13:04:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 24 Oct 2025 13:04:17 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v5]
In-Reply-To: <nMzn0-OPLhbz74Q4BOq0hnT9CBNfYHZIhEW5UJzPuv8=.10d61ebf-766f-44eb-ba2b-b2fe73530485@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
 <nMzn0-OPLhbz74Q4BOq0hnT9CBNfYHZIhEW5UJzPuv8=.10d61ebf-766f-44eb-ba2b-b2fe73530485@github.com>
Message-ID: <iBJCBJdc51pQJ3d_fd6TZBF3eL1l9Op75py8ISbENno=.7bdbb369-bf93-444c-a641-918309a95e57@github.com>

On Thu, 23 Oct 2025 14:48:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
>> 
>> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
>> 
>> What is important here is how this works (derived from the Parallel GC implementation):
>> 
>> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
>> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
>> 
>> Testing: tier1-5 without any OOMEs due to this feature, test case
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * make _gc_overhead_counter non-static

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27950#pullrequestreview-3376548482

From shade at openjdk.org  Fri Oct 24 14:27:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Oct 2025 14:27:39 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures
In-Reply-To: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
Message-ID: <ioduoxj1_5Lor_T5HCx5VyKO3zJ5YYURyt9LUfSGnOc=.809fad1c-f342-4740-8e26-9778bdc88c09@github.com>

On Thu, 23 Oct 2025 22:46:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.

Looks fine, with a nit.

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

> 127:   // Return the count and size (in words) of failed promotions since the last reset
> 128:   size_t get_promotion_failed_count() const { return _promotion_failure_count; }
> 129:   size_t get_promotion_failed_words() const { return _promotion_failure_words; }

Shouldn't these be `AtomicAccess::load(...)`-s? I don't think you need memory ordering, but if you are doing the updates atomically somewhere, it stands to reason you want to match the loads with atomics as well.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27962#pullrequestreview-3377147963
PR Review Comment: https://git.openjdk.org/jdk/pull/27962#discussion_r2460754950

From iwalulya at openjdk.org  Fri Oct 24 14:36:47 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 24 Oct 2025 14:36:47 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v5]
In-Reply-To: <u1U80Vr5E9ceWrUbfjCNP6tq62bCWNmX-tkOIf9d270=.5b0f6cb4-f80e-45fe-a803-87506c1bcc87@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
 <u1U80Vr5E9ceWrUbfjCNP6tq62bCWNmX-tkOIf9d270=.5b0f6cb4-f80e-45fe-a803-87506c1bcc87@github.com>
Message-ID: <X5G9lYM4nE1IfSCs28C7OJgly1-pH3StRyLQlKlbNIo=.24718990-7647-4ad3-8ac8-757200b3e381@github.com>

On Tue, 21 Oct 2025 09:31:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full.
>> 
>> This is needed only when `UseAdaptiveSizePolicy` is on, because this is intended to avoid including extra OS-time in gc-pause-time tracking, used for young-gen resizing.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-os-free-mem
>  - Merge branch 'master' into pgc-os-free-mem
>  - review
>  - sizet
>  - Merge branch 'master' into pgc-os-free-mem
>  - Merge branch 'master' into pgc-os-free-mem
>  - review
>  - Merge branch 'master' into pgc-os-free-mem
>  - pgc-os-free-mem

Nit:

src/hotspot/share/gc/parallel/psScavenge.cpp line 562:

> 560:     uint64_t free_mem_in_os;
> 561:     if (os::free_memory(free_mem_in_os)) {
> 562:       size_t actual_free = (size_t)MIN2(old_gen->committed().byte_size() - old_gen->used_in_bytes() + free_mem_in_os,

Suggestion:

      uint64_t actual_free = old_gen->committed().byte_size() - old_gen->used_in_bytes() + free_mem_in_os;


with associated changes to the log, probably would have been easier to read

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27068#pullrequestreview-3377196960
PR Review Comment: https://git.openjdk.org/jdk/pull/27068#discussion_r2460791524

From wkemper at openjdk.org  Fri Oct 24 17:36:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 17:36:42 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v2]
In-Reply-To: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
Message-ID: <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>

> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.

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

  Use atomic load when reading promotion failure counters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27962/files
  - new: https://git.openjdk.org/jdk/pull/27962/files/1e80c2a9..9213b8cb

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

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

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

From kdnilsen at openjdk.org  Fri Oct 24 19:50:31 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 19:50:31 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v32]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <O3qsOVMs_LTS_2KjXDiXLpI_622FNnFaWdtCU5ceLas=.308063f4-c280-484a-844b-ce7b8b332a4c@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 with a new target base due to a merge or a rebase. The pull request now contains 154 commits:

 - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
 - Rework implementation of CompressedClassSpaceSizeInJmapHeap.java
 - fix errors in CompressedClassSpaceSizeInJmapHeap.java
 - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java
 - Add sleep to CompressedClassSpaceSizeInJmapHeap.java test
 - Fix up vmstructs and other infrastructure for jmap heap dump
 - After initialization, check for SoftMaxHeapSize changed by constraints enforcement
 - clamp SoftMaxHeapSize during initialization
 - revert change to SoftMaxHeapSizeConstraintFunc
 - fix anothr override declaration
 - ... and 144 more: https://git.openjdk.org/jdk/compare/97e5ac6e...abf9b1f8

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

Changes: https://git.openjdk.org/jdk/pull/26867/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=31
  Stats: 3529 lines in 44 files changed: 2120 ins; 1005 del; 404 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 24 20:36:02 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 20:36:02 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v2]
In-Reply-To: <NxI28ZlypwXIdFu7Kz2H_sL-y3NSppuwNK0HCklpxdw=.26ce0f9d-7229-4fbd-92b9-3bb743b572eb@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
 <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>
 <NxI28ZlypwXIdFu7Kz2H_sL-y3NSppuwNK0HCklpxdw=.26ce0f9d-7229-4fbd-92b9-3bb743b572eb@github.com>
Message-ID: <D5hNz0IlikMxhX5sndTxrTMUH1q9Zu-EnsI1-UKReB8=.d7c49ebd-c9b6-4626-9823-019e597d1775@github.com>

On Fri, 24 Oct 2025 20:29:41 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use atomic load when reading promotion failure counters
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 684:
> 
>> 682:   const size_t gc_id = heap->control_thread()->get_gc_id();
>> 683: 
>> 684:   AtomicAccess::inc(&_promotion_failure_count);
> 
> Just noticing that in the next code block, we acquire the heap->lock().  Could we just use that same heap lock to protect adjustments to _promotion_failure_count and _promotion_failure_words and then we would need to use Atomic access operations?

Should probably be ok to read these variables without lock.  We're only logging these results when evacuation is no longer happening.  Right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27962#discussion_r2461905434

From kdnilsen at openjdk.org  Fri Oct 24 20:36:02 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 20:36:02 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v2]
In-Reply-To: <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
 <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>
Message-ID: <NxI28ZlypwXIdFu7Kz2H_sL-y3NSppuwNK0HCklpxdw=.26ce0f9d-7229-4fbd-92b9-3bb743b572eb@github.com>

On Fri, 24 Oct 2025 17:36:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use atomic load when reading promotion failure counters

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 684:

> 682:   const size_t gc_id = heap->control_thread()->get_gc_id();
> 683: 
> 684:   AtomicAccess::inc(&_promotion_failure_count);

Just noticing that in the next code block, we acquire the heap->lock().  Could we just use that same heap lock to protect adjustments to _promotion_failure_count and _promotion_failure_words and then we would need to use Atomic access operations?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27962#discussion_r2461900363

From kdnilsen at openjdk.org  Fri Oct 24 20:36:03 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 20:36:03 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v2]
In-Reply-To: <D5hNz0IlikMxhX5sndTxrTMUH1q9Zu-EnsI1-UKReB8=.d7c49ebd-c9b6-4626-9823-019e597d1775@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
 <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>
 <NxI28ZlypwXIdFu7Kz2H_sL-y3NSppuwNK0HCklpxdw=.26ce0f9d-7229-4fbd-92b9-3bb743b572eb@github.com>
 <D5hNz0IlikMxhX5sndTxrTMUH1q9Zu-EnsI1-UKReB8=.d7c49ebd-c9b6-4626-9823-019e597d1775@github.com>
Message-ID: <qXqsYfGjmASqonE8FyRIStVxPgH4z_Obh7eMlOua8zE=.4dcab645-fb58-4d7f-b63c-50762bf4d350@github.com>

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

>> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 684:
>> 
>>> 682:   const size_t gc_id = heap->control_thread()->get_gc_id();
>>> 683: 
>>> 684:   AtomicAccess::inc(&_promotion_failure_count);
>> 
>> Just noticing that in the next code block, we acquire the heap->lock().  Could we just use that same heap lock to protect adjustments to _promotion_failure_count and _promotion_failure_words and then we would need to use Atomic access operations?
>
> Should probably be ok to read these variables without lock.  We're only logging these results when evacuation is no longer happening.  Right?

Now that we have this new log message, can we get rid of the "promotion failure messages" for individual objects?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27962#discussion_r2461910193

From kdnilsen at openjdk.org  Fri Oct 24 20:43:04 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 20:43:04 GMT
Subject: RFR: 8370521: GenShen: Various code cleanup related to promotion
In-Reply-To: <fLqV6-Ycz0uhdc0ayoGQj5GpWnCmD-bo6JGDfg8UELU=.3f4698f2-c32b-4454-be42-52ed6d737ba3@github.com>
References: <fLqV6-Ycz0uhdc0ayoGQj5GpWnCmD-bo6JGDfg8UELU=.3f4698f2-c32b-4454-be42-52ed6d737ba3@github.com>
Message-ID: <Utsv0_LxjqDLMfDDrAnfFgKeYe5I7FgNmX6Kvxza27k=.7634b660-f070-491e-8337-98651a9b7c18@github.com>

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

> * Use more log tags for finer grained control over debug output. 
> * Add instrumentation for plab and cset decisions
> * Fix typos in comments and minor formatting issues
> * Rename some methods and variables for easier reading
> 
> There are no behavioral changes here. These changes were hoisted from https://github.com/openjdk/jdk/pull/27632 to facilitate its review.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/27963#pullrequestreview-3378773101

From kdnilsen at openjdk.org  Fri Oct 24 20:58:17 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 20:58:17 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v32]
In-Reply-To: <O3qsOVMs_LTS_2KjXDiXLpI_622FNnFaWdtCU5ceLas=.308063f4-c280-484a-844b-ce7b8b332a4c@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <O3qsOVMs_LTS_2KjXDiXLpI_622FNnFaWdtCU5ceLas=.308063f4-c280-484a-844b-ce7b8b332a4c@github.com>
Message-ID: <znIq7rs0fgc4sIApy_pkytEmlBNGBQOz-VOmO75zWsU=.4f9edf0e-8e15-4657-ae54-aeb860a7091d@github.com>

On Fri, 24 Oct 2025 19:50:31 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 with a new target base due to a merge or a rebase. The pull request now contains 154 commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
>  - Rework implementation of CompressedClassSpaceSizeInJmapHeap.java
>  - fix errors in CompressedClassSpaceSizeInJmapHeap.java
>  - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java
>  - Add sleep to CompressedClassSpaceSizeInJmapHeap.java test
>  - Fix up vmstructs and other infrastructure for jmap heap dump
>  - After initialization, check for SoftMaxHeapSize changed by constraints enforcement
>  - clamp SoftMaxHeapSize during initialization
>  - revert change to SoftMaxHeapSizeConstraintFunc
>  - fix anothr override declaration
>  - ... and 144 more: https://git.openjdk.org/jdk/compare/97e5ac6e...abf9b1f8

> I'm not convinced the change above to move the constraints check sooner is needed in order to use the value of SoftMaxHeapSize in ShenandoahHeap::initialize().
> 
> What's the error you see without this change?

I did some testing after reverting my change to the shared code, and I wasn't able to identify exactly how this change relates to particular regression failures.   I've committed new changes to mitigate the issues without changing shared code:

1. Inside ShenandoahHeap::initialize(), we clamp the assignment to _soft_max_size between min_capacity() and max_capacity()
2. In ShenandoahHeap::post_initialize(), we check_soft_max_changed().  This will change the value of _soft_max_size if the current value of SoftMaxHeapSize, which has now had its constraints enforced, differs from the current value of _soft_max_size.  Constraints are enforced following initialize() but before post_initialize().

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

PR Comment: https://git.openjdk.org/jdk/pull/26867#issuecomment-3444885624

From wkemper at openjdk.org  Fri Oct 24 21:06:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 21:06:13 GMT
Subject: RFR: 8370041: GenShen: Filter young pointers from thread local SATB
 buffers when only marking old
Message-ID: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>

When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'.

# Background
When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things.

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

Commit messages:
 - Fix typo in comment
 - Remove duplicate satb flush closure
 - Only flush satb once during degenerated cycle
 - Cleanup and comments
 - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots
 - Fix assertion
 - Oops, move inline definition out of ifdef ASSERT
 - Try piggybacking satb flush on update roots
 - Flush old satb after update references
 - Remove unused code
 - ... and 8 more: https://git.openjdk.org/jdk/compare/62f11cd4...ec58b72f

Changes: https://git.openjdk.org/jdk/pull/27983/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27983&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370041
  Stats: 295 lines in 10 files changed: 93 ins; 180 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/27983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27983/head:pull/27983

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

From wkemper at openjdk.org  Fri Oct 24 21:13:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 21:13:13 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v31]
In-Reply-To: <G9pq0QcX_t3_O_piD3HIbqfBhiVkZAhzhzAmO838WdQ=.148b7a66-ee59-4212-ae2a-6da19faad7cc@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <G9pq0QcX_t3_O_piD3HIbqfBhiVkZAhzhzAmO838WdQ=.148b7a66-ee59-4212-ae2a-6da19faad7cc@github.com>
Message-ID: <AbjXE8V8V5ifr4fuy2XjtPaxtFrOvEF2DpOKnRjDzW0=.0920ab05-9847-4660-82ac-1ffd5145f90b@github.com>

On Fri, 24 Oct 2025 03:41:50 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:
> 
>   Rework implementation of CompressedClassSpaceSizeInJmapHeap.java

test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java line 78:

> 76:         do {
> 77:             exitValue = run(pb);
> 78:         } while ((exitValue != 0) && (allowed_retries-- > 0));

Just a nit, but the other variables here use Java's camel case convention, so should probably have `allowedRetries`, not `allowed_retries`.

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

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

From kdnilsen at openjdk.org  Fri Oct 24 21:30:01 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 24 Oct 2025 21:30:01 GMT
Subject: RFR: 8370041: GenShen: Filter young pointers from thread local
 SATB buffers when only marking old
In-Reply-To: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>
References: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>
Message-ID: <EHMbe6zcz7nrHw1FvDe1I5a6eargvsE03H6GhFCKkzY=.5c5ccd1d-8ef5-4ef8-9bda-a8548519b4fe@github.com>

On Fri, 24 Oct 2025 21:00:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'.
> 
> # Background
> When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things.

This is a great simplification.  Do we have any performance numbers, especially for reduction in p99.999 and p100 latencies with certain Extremem workloads, which I believe to be related to safepoint flushing of satb buffers?

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

> 1142:   //     becoming part of the old snapshot.
> 1143:   //  2. The region is allocated during evacuation of old. This is also not a concern because
> 1144:   //     we haven't yet finished marking old so no mixed evacuations will happen.

Might be worth mentioning that there may be some additional analysis and code required when we use the forwarding table to recycle cset regions during evacuation and/or updating.  If one of these regions becomes old before the SATB buffers have been flushed, then a young cset pointer that lingers in a SATB buffer will "all of a sudden" look like a valid old pointer and will not be purged from the SATB buffer.  When we subsequently scan the "object" referenced by this obsolete pointer, we are likely to find "garbage memory", possibly resulting in a crash.

I am thinking that an initial fix might be to do this flushing at init-update-refs instead of at final update refs, and to not recycle cset regions until evacuation is all done.  Is there a different handshake there that we might piggyback on?

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

PR Review: https://git.openjdk.org/jdk/pull/27983#pullrequestreview-3378867185
PR Review Comment: https://git.openjdk.org/jdk/pull/27983#discussion_r2461998590

From wkemper at openjdk.org  Fri Oct 24 21:57:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 21:57:01 GMT
Subject: RFR: 8370041: GenShen: Filter young pointers from thread local
 SATB buffers when only marking old
In-Reply-To: <EHMbe6zcz7nrHw1FvDe1I5a6eargvsE03H6GhFCKkzY=.5c5ccd1d-8ef5-4ef8-9bda-a8548519b4fe@github.com>
References: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>
 <EHMbe6zcz7nrHw1FvDe1I5a6eargvsE03H6GhFCKkzY=.5c5ccd1d-8ef5-4ef8-9bda-a8548519b4fe@github.com>
Message-ID: <zobzKELz5u8WQ_krYcy7-4YJjaIkJOKqsPYUPdREkZY=.f0ae2e98-05c7-4e2f-9423-a01dc67589a4@github.com>

On Fri, 24 Oct 2025 21:16:10 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'.
>> 
>> # Background
>> When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things.
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1144:
> 
>> 1142:   //     becoming part of the old snapshot.
>> 1143:   //  2. The region is allocated during evacuation of old. This is also not a concern because
>> 1144:   //     we haven't yet finished marking old so no mixed evacuations will happen.
> 
> Might be worth mentioning that there may be some additional analysis and code required when we use the forwarding table to recycle cset regions during evacuation and/or updating.  If one of these regions becomes old before the SATB buffers have been flushed, then a young cset pointer that lingers in a SATB buffer will "all of a sudden" look like a valid old pointer and will not be purged from the SATB buffer.  When we subsequently scan the "object" referenced by this obsolete pointer, we are likely to find "garbage memory", possibly resulting in a crash.
> 
> I am thinking that an initial fix might be to do this flushing at init-update-refs instead of at final update refs, and to not recycle cset regions until evacuation is all done.  Is there a different handshake there that we might piggyback on?

Hmm, that's a good point about recycling regions concurrently. I don't think we can flush before `init-update-refs` because forwarded pointers still exist and the SATB barrier doesn't try to resolve them. That is to say, "bad" pointers can be created throughout the update-refs phase. 

Even in the (hypothetical) scenario with a forwarding table, a region would only become `old` through an in-place-promotion (in which case, it will never have been recycled) or we will be doing a mixed evacuation. If we are running a mixed evacuation, we will already have finished marking old.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27983#discussion_r2462100316

From wkemper at openjdk.org  Fri Oct 24 22:20:02 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 22:20:02 GMT
Subject: RFR: 8370041: GenShen: Filter young pointers from thread local
 SATB buffers when only marking old
In-Reply-To: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>
References: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>
Message-ID: <RlmBQ64-XLAQsz0lvSvEVIYDmunaaFQliIqXJy3ZF38=.4bc8fbb6-e7fa-4814-aaee-dfac8d23dc2b@github.com>

On Fri, 24 Oct 2025 21:00:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'.
> 
> # Background
> When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things.

I have results from an earlier version of this PR that flushed the buffers during `init-mark`. That version showed a consistent 3% improvement on critical _and_ max jops. They also showed a reduction in p99.999 latency for some of the extremem measurements. I will retest with this version.

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

PR Comment: https://git.openjdk.org/jdk/pull/27983#issuecomment-3445088766

From shade at openjdk.org  Fri Oct 24 22:30:03 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Oct 2025 22:30:03 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v2]
In-Reply-To: <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
 <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>
Message-ID: <H6Z03UBbYB-fNJPx0LJo4rrZmOv7WOZSHgqrZkcItlc=.73339677-4d7f-4ff4-a810-ba47c70d6e73@github.com>

On Fri, 24 Oct 2025 17:36:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use atomic load when reading promotion failure counters

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27962#pullrequestreview-3379087151

From wkemper at openjdk.org  Fri Oct 24 22:30:04 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 22:30:04 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v2]
In-Reply-To: <qXqsYfGjmASqonE8FyRIStVxPgH4z_Obh7eMlOua8zE=.4dcab645-fb58-4d7f-b63c-50762bf4d350@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
 <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>
 <NxI28ZlypwXIdFu7Kz2H_sL-y3NSppuwNK0HCklpxdw=.26ce0f9d-7229-4fbd-92b9-3bb743b572eb@github.com>
 <D5hNz0IlikMxhX5sndTxrTMUH1q9Zu-EnsI1-UKReB8=.d7c49ebd-c9b6-4626-9823-019e597d1775@github.com>
 <qXqsYfGjmASqonE8FyRIStVxPgH4z_Obh7eMlOua8zE=.4dcab645-fb58-4d7f-b63c-50762bf4d350@github.com>
Message-ID: <CE5BxjiACE5fLL8-DzOyhGrCAYiw0wsV1p2ZEIzt_Uo=.b732ebe2-d42a-4594-ae36-2a11ce6a64fa@github.com>

On Fri, 24 Oct 2025 20:33:20 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Should probably be ok to read these variables without lock.  We're only logging these results when evacuation is no longer happening.  Right?
>
> Now that we have this new log message, can we get rid of the "promotion failure messages" for individual objects?

We only take the heap lock there conditionally when we haven't yet "squelched" the log message.  We could change this to a `log_debug(gc, plab)` level message. The message is still useful when trying to understand the history and context for a how a thread became unable to promote. I'm not completely convinced there aren't still cases where a thread _should_ be able to promote but can't for some (unknown) reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27962#discussion_r2462150204

From wkemper at openjdk.org  Fri Oct 24 22:30:05 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 22:30:05 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v2]
In-Reply-To: <CE5BxjiACE5fLL8-DzOyhGrCAYiw0wsV1p2ZEIzt_Uo=.b732ebe2-d42a-4594-ae36-2a11ce6a64fa@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
 <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>
 <NxI28ZlypwXIdFu7Kz2H_sL-y3NSppuwNK0HCklpxdw=.26ce0f9d-7229-4fbd-92b9-3bb743b572eb@github.com>
 <D5hNz0IlikMxhX5sndTxrTMUH1q9Zu-EnsI1-UKReB8=.d7c49ebd-c9b6-4626-9823-019e597d1775@github.com>
 <qXqsYfGjmASqonE8FyRIStVxPgH4z_Obh7eMlOua8zE=.4dcab645-fb58-4d7f-b63c-50762bf4d350@github.com>
 <CE5BxjiACE5fLL8-DzOyhGrCAYiw0wsV1p2ZEIzt_Uo=.b732ebe2-d42a-4594-ae36-2a11ce6a64fa@github.com>
Message-ID: <9GC0R3xlEfMvOMTdEXBL7EjLV8iRh_yaPP7a69YOpWE=.15978eed-6adb-461a-bb5d-1b6de91ed82f@github.com>

On Fri, 24 Oct 2025 22:25:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Now that we have this new log message, can we get rid of the "promotion failure messages" for individual objects?
>
> We only take the heap lock there conditionally when we haven't yet "squelched" the log message.  We could change this to a `log_debug(gc, plab)` level message. The message is still useful when trying to understand the history and context for a how a thread became unable to promote. I'm not completely convinced there aren't still cases where a thread _should_ be able to promote but can't for some (unknown) reason.

If we made this a `log_debug(gc, plab)` message, we could make the whole block of code conditional on the log level being enabled.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27962#discussion_r2462151932

From wkemper at openjdk.org  Fri Oct 24 23:22:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 23:22:39 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v3]
In-Reply-To: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
Message-ID: <WN3Bldr28ci72LLkBFYnFBBgUbqPXND10MgpxidHgmM=.841d7c82-7628-4f13-939a-692f0f92773f@github.com>

> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.

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

  Change log level of detailed promotion failure message
  
  And only do the work for the message if the log level is enabled.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27962/files
  - new: https://git.openjdk.org/jdk/pull/27962/files/9213b8cb..a86e34c8

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

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

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

From wkemper at openjdk.org  Fri Oct 24 23:46:17 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 24 Oct 2025 23:46:17 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v4]
In-Reply-To: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
Message-ID: <PuXQZmJFl5GEn43C9XGI_bTmj8TXpKKpkFqw4G1f73U=.63c652cd-89d7-490d-b385-43c1d18b274a@github.com>

> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.

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

  New method can be const

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27962/files
  - new: https://git.openjdk.org/jdk/pull/27962/files/a86e34c8..dac7a318

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

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

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

From syan at openjdk.org  Sat Oct 25 01:57:14 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 25 Oct 2025 01:57:14 GMT
Subject: RFR: 8370501:
 vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java
 intermittent timed out
In-Reply-To: <6Kwe4gf9ucL4DXdmH5usxtVCxFaeNCHniIia4hrf9Us=.4f33baaf-0911-4f6b-b08c-b2828bcbb45b@github.com>
References: <TmKN0TrkEFKoMAFMRotfxrpo3Lz2GMtjXOQ-5Zoj73g=.ae103b1e-1030-446a-908d-402d7afc1b2d@github.com>
 <6Kwe4gf9ucL4DXdmH5usxtVCxFaeNCHniIia4hrf9Us=.4f33baaf-0911-4f6b-b08c-b2828bcbb45b@github.com>
Message-ID: <CWRCGe8VtqoL_j4uDarqLx7MPqF8MIUoAq7EiG7RKbs=.3dbc668f-0a03-4d0e-9f43-0986c84df617@github.com>

On Fri, 24 Oct 2025 05:55:31 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>> We found that vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java intermittent timed out when the timeout factor is seted to 1, [JDK-8368668](https://bugs.openjdk.org/browse/JDK-8368668) missed fix this test. Although [JDK-8369491](https://bugs.openjdk.org/browse/JDK-8369491) has revert the default TIMEOUT_FACTOR back to 1. but I think it's necessary to make test run pass steady with TIMEOUT_FACTOR set to 1.
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks for the reviews @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/27954#issuecomment-3445457260

From syan at openjdk.org  Sat Oct 25 01:57:15 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 25 Oct 2025 01:57:15 GMT
Subject: Integrated: 8370501:
 vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java
 intermittent timed out
In-Reply-To: <TmKN0TrkEFKoMAFMRotfxrpo3Lz2GMtjXOQ-5Zoj73g=.ae103b1e-1030-446a-908d-402d7afc1b2d@github.com>
References: <TmKN0TrkEFKoMAFMRotfxrpo3Lz2GMtjXOQ-5Zoj73g=.ae103b1e-1030-446a-908d-402d7afc1b2d@github.com>
Message-ID: <_44RyMelyy8XCyEeaBR2brJWYwpsCAEbrQ6y6tLjBpc=.1b6cffa4-44c8-4058-988f-9df185501333@github.com>

On Thu, 23 Oct 2025 14:18:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> We found that vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java intermittent timed out when the timeout factor is seted to 1, [JDK-8368668](https://bugs.openjdk.org/browse/JDK-8368668) missed fix this test. Although [JDK-8369491](https://bugs.openjdk.org/browse/JDK-8369491) has revert the default TIMEOUT_FACTOR back to 1. but I think it's necessary to make test run pass steady with TIMEOUT_FACTOR set to 1.

This pull request has now been integrated.

Changeset: 32697bf6
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32697bf652429fa7247047465e365835dfa24b39
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8370501: vmTestbase/vm/gc/compact/Humongous_NonbranchyTree5M/TestDescription.java intermittent timed out

Reviewed-by: tschatzl

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

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

From syan at openjdk.org  Sat Oct 25 01:58:45 2025
From: syan at openjdk.org (SendaoYan)
Date: Sat, 25 Oct 2025 01:58:45 GMT
Subject: RFR: 8370649: Add intermittent tag for
 gc/shenandoah/generational/TestOldGrowthTriggers.java
Message-ID: <x7NXwU4vAyRvPiUjceN2dxSGFmtBZ_s5kn8yYR7bd4o=.635500ec-8789-460b-947e-c8e1f9ec28bf@github.com>

Hi all,

Test gc/shenandoah/generational/TestOldGrowthTriggers.java intermittent fails "'Trigger (Old): Old has overgrown' missing from stdout/stderr" with default JVM options by fastdebug build on linux-aarch64. The failure probability about 1/100.

Should we add '@key intermittent' tag for this test until the root cause has been fixed. The '@key intermittent' tag make some test infrasture disable or rerun this test automaticly when it's intermittent fails.

Test-fix only. no risk.

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

Commit messages:
 - 8370649: Add intermittent tag for gc/shenandoah/generational/TestOldGrowthTriggers.java

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

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

From kdnilsen at openjdk.org  Sun Oct 26 00:00:03 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 26 Oct 2025 00:00:03 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v33]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <32pNJLsvsTHcyUfKjADbM-t7phkQt6ZkHUzaztBy4pg=.d7ed6aac-b88f-4ca5-8487-e44884ffaf17@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:

  reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26867/files
  - new: https://git.openjdk.org/jdk/pull/26867/files/abf9b1f8..5557ae9b

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

  Stats: 6 lines in 1 file changed: 0 ins; 2 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 tschatzl at openjdk.org  Mon Oct 27 06:56:16 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 27 Oct 2025 06:56:16 GMT
Subject: RFR: 8212084: G1: Implement UseGCOverheadLimit [v5]
In-Reply-To: <nMzn0-OPLhbz74Q4BOq0hnT9CBNfYHZIhEW5UJzPuv8=.10d61ebf-766f-44eb-ba2b-b2fe73530485@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
 <nMzn0-OPLhbz74Q4BOq0hnT9CBNfYHZIhEW5UJzPuv8=.10d61ebf-766f-44eb-ba2b-b2fe73530485@github.com>
Message-ID: <qytAgrft_QuE2QYeBBobyKQELJQpCHYBK_9uFQr64PA=.0eccd202-6692-40ef-847f-735514c61eee@github.com>

On Thu, 23 Oct 2025 14:48:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
>> 
>> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
>> 
>> What is important here is how this works (derived from the Parallel GC implementation):
>> 
>> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
>> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
>> 
>> Testing: tier1-5 without any OOMEs due to this feature, test case
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * make _gc_overhead_counter non-static

Thanks for all the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/27950#issuecomment-3449765947

From tschatzl at openjdk.org  Mon Oct 27 06:56:18 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 27 Oct 2025 06:56:18 GMT
Subject: Integrated: 8212084: G1: Implement UseGCOverheadLimit
In-Reply-To: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
References: <02pBDpBJseH9B7YznDSPNMhL2LBkrps0fCqxMnorwXM=.9edcc9ef-e5d9-4f17-876c-88e1c37564c1@github.com>
Message-ID: <8s95QQx6LjoWohqKaaiTXphaOnmvTczbZEXeYCT4KHA=.6f47b6e3-24cd-4727-9bf8-0f26348ed457@github.com>

On Thu, 23 Oct 2025 07:11:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review these changes to implement the `UseGCOverheadLimit` functionality for G1 (and make the implementation for Parallel GC have similar output).
> 
> The `UseGCOverheadLimit` feature prematurely returns `null` from a GC if GC cpu usage limits and heap usage limits are met for some time. This is to avoid a VM limping along if garbage collection gets into an endless cycle of garbage collections or until a "real" OOME is thrown.
> 
> What is important here is how this works (derived from the Parallel GC implementation):
> 
> * check overheads at the end of the (initial) garbage collection (before upgrading) to see whether we are over the limits for a sequence of GCs.
> * keep doing GCs without actually allocating memory for the allocation request to keep on measuring gc CPU usage. This is important for measuring the correct cpu usage in case of the application being able to free memory on the OOME.
> 
> Testing: tier1-5 without any OOMEs due to this feature, test case
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 3d2ce804
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d2ce8045f9ea52c6559638f9cc7e0a0544b4540
Stats:     219 lines in 7 files changed: 186 ins; 15 del; 18 mod

8212084: G1: Implement UseGCOverheadLimit

Reviewed-by: ayang, iwalulya, fandreuzzi

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

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

From ayang at openjdk.org  Mon Oct 27 09:55:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Oct 2025 09:55:34 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v5]
In-Reply-To: <X5G9lYM4nE1IfSCs28C7OJgly1-pH3StRyLQlKlbNIo=.24718990-7647-4ad3-8ac8-757200b3e381@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
 <u1U80Vr5E9ceWrUbfjCNP6tq62bCWNmX-tkOIf9d270=.5b0f6cb4-f80e-45fe-a803-87506c1bcc87@github.com>
 <X5G9lYM4nE1IfSCs28C7OJgly1-pH3StRyLQlKlbNIo=.24718990-7647-4ad3-8ac8-757200b3e381@github.com>
Message-ID: <wMj_1AIKWzY_WADHkcX0OMpE6Clg9nzcmPlR8iqU2q0=.665bde4b-e830-4764-b028-32a83033ad34@github.com>

On Fri, 24 Oct 2025 14:33:28 GMT, Ivan Walulya <iwalulya 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 10 additional commits since the last revision:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-os-free-mem
>>  - Merge branch 'master' into pgc-os-free-mem
>>  - review
>>  - sizet
>>  - Merge branch 'master' into pgc-os-free-mem
>>  - Merge branch 'master' into pgc-os-free-mem
>>  - review
>>  - Merge branch 'master' into pgc-os-free-mem
>>  - pgc-os-free-mem
>
> src/hotspot/share/gc/parallel/psScavenge.cpp line 562:
> 
>> 560:     uint64_t free_mem_in_os;
>> 561:     if (os::free_memory(free_mem_in_os)) {
>> 562:       size_t actual_free = (size_t)MIN2(old_gen->committed().byte_size() - old_gen->used_in_bytes() + free_mem_in_os,
> 
> Suggestion:
> 
>       uint64_t actual_free = old_gen->committed().byte_size() - old_gen->used_in_bytes() + free_mem_in_os;
> 
> 
> with associated changes to the log, probably would have been easier to read

The long-term plan is to use `size_t` in `os::free_memory` as well, so I prefer limiting the scope of `uint64_t`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27068#discussion_r2465045547

From ayang at openjdk.org  Mon Oct 27 10:13:10 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Oct 2025 10:13:10 GMT
Subject: RFR: 8366781: Parallel: Include OS free memory in GC selection
 heuristics [v5]
In-Reply-To: <u1U80Vr5E9ceWrUbfjCNP6tq62bCWNmX-tkOIf9d270=.5b0f6cb4-f80e-45fe-a803-87506c1bcc87@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
 <u1U80Vr5E9ceWrUbfjCNP6tq62bCWNmX-tkOIf9d270=.5b0f6cb4-f80e-45fe-a803-87506c1bcc87@github.com>
Message-ID: <6p7b9aNLCuMr0RiXEQCwcrMFHBBp_9bPdxHR2f_sTeg=.ee2e5931-de89-4a03-b821-b00743717940@github.com>

On Tue, 21 Oct 2025 09:31:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full.
>> 
>> This is needed only when `UseAdaptiveSizePolicy` is on, because this is intended to avoid including extra OS-time in gc-pause-time tracking, used for young-gen resizing.
>> 
>> Test: tier1-3
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-os-free-mem
>  - Merge branch 'master' into pgc-os-free-mem
>  - review
>  - sizet
>  - Merge branch 'master' into pgc-os-free-mem
>  - Merge branch 'master' into pgc-os-free-mem
>  - review
>  - Merge branch 'master' into pgc-os-free-mem
>  - pgc-os-free-mem

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/27068#issuecomment-3450466224

From ayang at openjdk.org  Mon Oct 27 10:13:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Oct 2025 10:13:11 GMT
Subject: Integrated: 8366781: Parallel: Include OS free memory in GC selection
 heuristics
In-Reply-To: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
References: <YaH5ryUWlQ_xmGQZZPLMor6jn5bYoUMY057GCtC5OLM=.efbcab06-cec9-4b6e-8f6d-4da8230bfa3a@github.com>
Message-ID: <1DVRuMWxzMlDtF7kj-LRCYWA-k1_welKWF5xEfm2GoQ=.473fcef0-ec33-4a77-baf2-b9bfe6af1291@github.com>

On Wed, 3 Sep 2025 09:58:33 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add a new condition checking if OS has enough free memory to commit/expand old-gen, which determines whether the upcoming GC should be young or full.
> 
> This is needed only when `UseAdaptiveSizePolicy` is on, because this is intended to avoid including extra OS-time in gc-pause-time tracking, used for young-gen resizing.
> 
> Test: tier1-3

This pull request has now been integrated.

Changeset: 91e1dcb1
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91e1dcb1083cc8c451d2d169d7f2fdb51c1a158e
Stats:     37 lines in 1 file changed: 26 ins; 1 del; 10 mod

8366781: Parallel: Include OS free memory in GC selection heuristics

Reviewed-by: gli, iwalulya

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

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

From ayang at openjdk.org  Mon Oct 27 11:01:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Oct 2025 11:01:05 GMT
Subject: RFR: 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
 [v2]
In-Reply-To: <uWb3hAk6qJfqXsUJC6v9Uzia5fcEEaKjFaYuogyY0RM=.3627cbd2-f2b1-48db-893b-4dc7b3c9fd38@github.com>
References: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
 <uWb3hAk6qJfqXsUJC6v9Uzia5fcEEaKjFaYuogyY0RM=.3627cbd2-f2b1-48db-893b-4dc7b3c9fd38@github.com>
Message-ID: <pXMVCOGuifEyonnep4dnXkP_shcMGitttxENSlpWH0E=.cebe8e72-a1fa-4b33-ada9-5d541d559b44@github.com>

On Wed, 22 Oct 2025 13:56:14 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Parallel's MutableNUMASpace is the only GC interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used, and unsafe_max_tlab_alloc. It would be nice if Parallel's MutableNUMASpace could do without the Thread and instead find a thread-agnostic approach. By removing the need for the thread, it becomes possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs. Also, the lgrp_id that is stored in the Thread class should really have been moved to GCThreadLocalData after that concept was created, but with a thread-agnostic approach, the field can be removed entirely.
>> 
>> The current solution is not without problems. When a new allocation is made inside one of the LGRP spaces in MutableNUMASpace using cas_allocate(), the NUMA/LGRP id is polled and stored inside the Thread, and we only attempt to allocate on that LGRP. If allocation fails on the local LGRP, we do not try to allocate on any other (remote) LGRP(s). This fact is reflected in the TLAB accounting methods tlab_capacity, tlab_used, and unsafe_max_tlab_alloc, which only check how much memory is used, etc., for the LGRP matching the stored LGRP id in the Thread. This model breaks down when threads are allowed to migrate between different CPUs, and therefore also NUMA nodes, which might change the LGRP id.
>> 
>> For example, a system with two NUMA nodes gives us two LGRPs with ids 0 and 1. If a thread allocates most of its memory on LGRP 0 and then migrates to a CPU on LGRP 1, the thread will show that it allocated a significant amount of memory, but the used memory on the LGRP it is currently on could be very low. This would give a disproportionate allocation fraction. This is not a problem as the TLAB code accounts for this, but for a different reason entirely. The other way around could also be problematic. If a thread allocates very little memory on LGRP 0 and then migrates to LGRP 1, where another thread has allocated a lot of memory, the allocation fraction will be very low, when it could have a really high fraction if accounting for the used memory on its original LGRP.
>> 
>> A solution to both of these issues is to average the capacity, used, and available memory across all LGRPs for the TLAB accounting methods. This approach provides a more accurate and stable view of memory usage and availability, regardless of thread migration or imbalances in NUMA/LGRP allocation. However, th...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   unsafe_max_tlab_alloc must be aligned to MinObjAlignmentInBytes

src/hotspot/share/gc/parallel/mutableNUMASpace.cpp line 133:

> 131:     s += ls->space()->free_in_bytes();
> 132:   }
> 133:   return align_down(s / (size_t)lgrp_spaces()->length(), MinObjAlignmentInBytes);

I'd suggest placing `align_down` in its own line and a comment for why.

The rest look good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27935#discussion_r2465233372

From jsikstro at openjdk.org  Mon Oct 27 11:36:29 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 27 Oct 2025 11:36:29 GMT
Subject: RFR: 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
 [v3]
In-Reply-To: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
References: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
Message-ID: <JZlXmvc79AxZNq-kTpOFOcxq0htENPn6eTG1DJ3a0xU=.d9195708-6f44-44ca-9209-351d822c5909@github.com>

> Hello,
> 
> Parallel's MutableNUMASpace is the only GC interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used, and unsafe_max_tlab_alloc. It would be nice if Parallel's MutableNUMASpace could do without the Thread and instead find a thread-agnostic approach. By removing the need for the thread, it becomes possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs. Also, the lgrp_id that is stored in the Thread class should really have been moved to GCThreadLocalData after that concept was created, but with a thread-agnostic approach, the field can be removed entirely.
> 
> The current solution is not without problems. When a new allocation is made inside one of the LGRP spaces in MutableNUMASpace using cas_allocate(), the NUMA/LGRP id is polled and stored inside the Thread, and we only attempt to allocate on that LGRP. If allocation fails on the local LGRP, we do not try to allocate on any other (remote) LGRP(s). This fact is reflected in the TLAB accounting methods tlab_capacity, tlab_used, and unsafe_max_tlab_alloc, which only check how much memory is used, etc., for the LGRP matching the stored LGRP id in the Thread. This model breaks down when threads are allowed to migrate between different CPUs, and therefore also NUMA nodes, which might change the LGRP id.
> 
> For example, a system with two NUMA nodes gives us two LGRPs with ids 0 and 1. If a thread allocates most of its memory on LGRP 0 and then migrates to a CPU on LGRP 1, the thread will show that it allocated a significant amount of memory, but the used memory on the LGRP it is currently on could be very low. This would give a disproportionate allocation fraction. This is not a problem as the TLAB code accounts for this, but for a different reason entirely. The other way around could also be problematic. If a thread allocates very little memory on LGRP 0 and then migrates to LGRP 1, where another thread has allocated a lot of memory, the allocation fraction will be very low, when it could have a really high fraction if accounting for the used memory on its original LGRP.
> 
> A solution to both of these issues is to average the capacity, used, and available memory across all LGRPs for the TLAB accounting methods. This approach provides a more accurate and stable view of memory usage and availability, regardless of thread migration or imbalances in NUMA/LGRP allocation. However, there are trade-offs...

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

  Comment on unsafe_max_tlab_alloc alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27935/files
  - new: https://git.openjdk.org/jdk/pull/27935/files/c8a2182f..c4cd91a8

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

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

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

From ayang at openjdk.org  Mon Oct 27 11:40:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Oct 2025 11:40:50 GMT
Subject: RFR: 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
 [v3]
In-Reply-To: <JZlXmvc79AxZNq-kTpOFOcxq0htENPn6eTG1DJ3a0xU=.d9195708-6f44-44ca-9209-351d822c5909@github.com>
References: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
 <JZlXmvc79AxZNq-kTpOFOcxq0htENPn6eTG1DJ3a0xU=.d9195708-6f44-44ca-9209-351d822c5909@github.com>
Message-ID: <T-GJtti_DxJOaINYRg4Ne3LQOS0c2eUvAMCyes0UhC4=.5c6e9fb9-db1e-42c7-a18e-3b76efd3bcdc@github.com>

On Mon, 27 Oct 2025 11:36:29 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Parallel's MutableNUMASpace is the only GC interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used, and unsafe_max_tlab_alloc. It would be nice if Parallel's MutableNUMASpace could do without the Thread and instead find a thread-agnostic approach. By removing the need for the thread, it becomes possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs. Also, the lgrp_id that is stored in the Thread class should really have been moved to GCThreadLocalData after that concept was created, but with a thread-agnostic approach, the field can be removed entirely.
>> 
>> The current solution is not without problems. When a new allocation is made inside one of the LGRP spaces in MutableNUMASpace using cas_allocate(), the NUMA/LGRP id is polled and stored inside the Thread, and we only attempt to allocate on that LGRP. If allocation fails on the local LGRP, we do not try to allocate on any other (remote) LGRP(s). This fact is reflected in the TLAB accounting methods tlab_capacity, tlab_used, and unsafe_max_tlab_alloc, which only check how much memory is used, etc., for the LGRP matching the stored LGRP id in the Thread. This model breaks down when threads are allowed to migrate between different CPUs, and therefore also NUMA nodes, which might change the LGRP id.
>> 
>> For example, a system with two NUMA nodes gives us two LGRPs with ids 0 and 1. If a thread allocates most of its memory on LGRP 0 and then migrates to a CPU on LGRP 1, the thread will show that it allocated a significant amount of memory, but the used memory on the LGRP it is currently on could be very low. This would give a disproportionate allocation fraction. This is not a problem as the TLAB code accounts for this, but for a different reason entirely. The other way around could also be problematic. If a thread allocates very little memory on LGRP 0 and then migrates to LGRP 1, where another thread has allocated a lot of memory, the allocation fraction will be very low, when it could have a really high fraction if accounting for the used memory on its original LGRP.
>> 
>> A solution to both of these issues is to average the capacity, used, and available memory across all LGRPs for the TLAB accounting methods. This approach provides a more accurate and stable view of memory usage and availability, regardless of thread migration or imbalances in NUMA/LGRP allocation. However, th...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment on unsafe_max_tlab_alloc alignment

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27935#pullrequestreview-3383044784

From ayang at openjdk.org  Mon Oct 27 15:00:27 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 27 Oct 2025 15:00:27 GMT
Subject: RFR: 8370417: Parallel: TestAlwaysPreTouchBehavior.java fails with
 NUMA
Message-ID: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>

Perform pretouching for pages in eden + NUMA. The preceding `bias_region` calls will associate each OS page to the desired NUMA node.

Test: tier1-5

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

Commit messages:
 - pgc-numa-pretouch

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

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

From wkemper at openjdk.org  Mon Oct 27 17:06:10 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 27 Oct 2025 17:06:10 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v5]
In-Reply-To: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
Message-ID: <mazt173b7kviwaGYNV5SQbUcU0WdREAgL-9sVbLgGGg=.abb21ba8-5750-4fbd-b5ec-8e8196966f12@github.com>

> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.

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

  Fix build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27962/files
  - new: https://git.openjdk.org/jdk/pull/27962/files/dac7a318..96357b45

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

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

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

From shade at openjdk.org  Mon Oct 27 17:13:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 27 Oct 2025 17:13:45 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v5]
In-Reply-To: <mazt173b7kviwaGYNV5SQbUcU0WdREAgL-9sVbLgGGg=.abb21ba8-5750-4fbd-b5ec-8e8196966f12@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
 <mazt173b7kviwaGYNV5SQbUcU0WdREAgL-9sVbLgGGg=.abb21ba8-5750-4fbd-b5ec-8e8196966f12@github.com>
Message-ID: <DHaguYe1XrxEnDPEl2Keigs_k-y-fJKmQCqR9iWC_54=.adec1575-1ec1-4c5a-ab83-c55c0e7bb45c@github.com>

On Mon, 27 Oct 2025 17:06:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27962#pullrequestreview-3384598340

From wkemper at openjdk.org  Mon Oct 27 17:50:04 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 27 Oct 2025 17:50:04 GMT
Subject: RFR: 8370649: Add intermittent tag for
 gc/shenandoah/generational/TestOldGrowthTriggers.java
In-Reply-To: <x7NXwU4vAyRvPiUjceN2dxSGFmtBZ_s5kn8yYR7bd4o=.635500ec-8789-460b-947e-c8e1f9ec28bf@github.com>
References: <x7NXwU4vAyRvPiUjceN2dxSGFmtBZ_s5kn8yYR7bd4o=.635500ec-8789-460b-947e-c8e1f9ec28bf@github.com>
Message-ID: <QagaeQM-zcMSvaWjvJfFJqC1_daCKvcGYiEz6Ql2IKk=.87822603-fd98-4d6b-9b24-77c592ccb2a2@github.com>

On Sat, 25 Oct 2025 01:50:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test gc/shenandoah/generational/TestOldGrowthTriggers.java intermittent fails "'Trigger (Old): Old has overgrown' missing from stdout/stderr" with default JVM options by fastdebug build on linux-aarch64. The failure probability about 1/100.
> 
> Should we add '@key intermittent' tag for this test until the root cause has been fixed. The '@key intermittent' tag make some test infrasture disable or rerun this test automaticly when it's intermittent fails.
> 
> Test-fix only. no risk.

Thank you for this PR. We will still investigate the test failure.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27986#pullrequestreview-3384739668

From prappo at openjdk.org  Mon Oct 27 17:51:36 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 27 Oct 2025 17:51:36 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
Message-ID: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>

Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.

Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

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

Commit messages:
 - Initial commit

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

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

From iveresov at openjdk.org  Mon Oct 27 18:44:09 2025
From: iveresov at openjdk.org (Igor Veresov)
Date: Mon, 27 Oct 2025 18:44:09 GMT
Subject: RFR: 8370417: Parallel: TestAlwaysPreTouchBehavior.java fails with
 NUMA
In-Reply-To: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
References: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
Message-ID: <RjenwjjUEmpA-7lRND_kVi1t5maSmYipvcL5tJZd7Z8=.a296cb21-8219-4ac9-a8b1-95de09c17edc@github.com>

On Mon, 27 Oct 2025 14:52:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Perform pretouching for pages in eden + NUMA. The preceding `bias_region` calls will associate each OS page to the desired NUMA node.
> 
> Test: tier1-5

Looks good

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

Marked as reviewed by iveresov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28000#pullrequestreview-3384944529

From rriggs at openjdk.org  Mon Oct 27 20:45:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 27 Oct 2025 20:45:02 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <Cgql6iI8JuqqSOun9twdTUyH58EbM3FM_jaKF_a8iys=.f58c06ff-2c6b-41fb-bbc7-ae4f92d91401@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3385391439

From wkemper at openjdk.org  Mon Oct 27 21:01:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 27 Oct 2025 21:01:41 GMT
Subject: Integrated: 8370520: GenShen: Track and report on promotion failures
In-Reply-To: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
Message-ID: <Siip4JKBuqbF3QA7pl8YkNifDMg_QY8Aj2eAG6JS368=.72b3eab6-cabe-45a4-bf21-b413c8d78e51@github.com>

On Thu, 23 Oct 2025 22:46:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Keep track of promotion failures. Report the number of failures and total number of bytes that could not be promoted. These changes were hoisted out of https://github.com/openjdk/jdk/pull/27632.

This pull request has now been integrated.

Changeset: 70aa3678
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70aa3678fccddc1a626fd86b9cec348fae571555
Stats:     64 lines in 3 files changed: 36 ins; 12 del; 16 mod

8370520: GenShen: Track and report on promotion failures

Reviewed-by: shade, fandreuzzi

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

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

From kdnilsen at openjdk.org  Mon Oct 27 21:54:11 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 27 Oct 2025 21:54:11 GMT
Subject: RFR: 8370520: GenShen: Track and report on promotion failures [v2]
In-Reply-To: <9GC0R3xlEfMvOMTdEXBL7EjLV8iRh_yaPP7a69YOpWE=.15978eed-6adb-461a-bb5d-1b6de91ed82f@github.com>
References: <OnXUM7gCLPuS1S1nhCaqoX2lvjswRHwOGH5I8kz9fRY=.205c0dc4-a397-480e-bbb0-3af2a7d892c0@github.com>
 <mMYPLLPzzO-KvWx8USEkKpJExSonhOwq7RM_DVklXnQ=.1701919b-94ac-4a98-80c8-26445060c3c2@github.com>
 <NxI28ZlypwXIdFu7Kz2H_sL-y3NSppuwNK0HCklpxdw=.26ce0f9d-7229-4fbd-92b9-3bb743b572eb@github.com>
 <D5hNz0IlikMxhX5sndTxrTMUH1q9Zu-EnsI1-UKReB8=.d7c49ebd-c9b6-4626-9823-019e597d1775@github.com>
 <qXqsYfGjmASqonE8FyRIStVxPgH4z_Obh7eMlOua8zE=.4dcab645-fb58-4d7f-b63c-50762bf4d350@github.com>
 <CE5BxjiACE5fLL8-DzOyhGrCAYiw0wsV1p2ZEIzt_Uo=.b732ebe2-d42a-4594-ae36-2a11ce6a64fa@github.com>
 <9GC0R3xlEfMvOMTdEXBL7EjLV8iRh_yaPP7a69YOpWE=.15978eed-6adb-461a-bb5d-1b6de91ed82f@github.com>
Message-ID: <M0K8ECd6Ayi4Pgbb0NwcDQPSYzPn5pd5W-T_nlh86GI=.6738e4f2-ff9f-4632-abef-c36406f7b078@github.com>

On Fri, 24 Oct 2025 22:27:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> We only take the heap lock there conditionally when we haven't yet "squelched" the log message.  We could change this to a `log_debug(gc, plab)` level message. The message is still useful when trying to understand the history and context for a how a thread became unable to promote. I'm not completely convinced there aren't still cases where a thread _should_ be able to promote but can't for some (unknown) reason.
>
> If we made this a `log_debug(gc, plab)` message, we could make the whole block of code conditional on the log level being enabled.

I'd be comfortable with that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27962#discussion_r2467171498

From xpeng at openjdk.org  Mon Oct 27 21:59:35 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 27 Oct 2025 21:59:35 GMT
Subject: RFR: 8361099: Shenandoah: Improve heap lock contention by using
 CAS for memory allocation [v5]
In-Reply-To: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
References: <RO_fEPp3SvrFkDJ6v26Rt5V0bFtt1qJLibNOUbt84b8=.107dc7be-3b77-46e3-9913-184d97c48098@github.com>
Message-ID: <JAyYP5BmPJpXWfdQt3NTPUC8KQQ5F-rRc-b2AFfrjTs=.42295acf-daa5-4d7b-ac05-323416e88163@github.com>

> Shenandoah always allocates memory with heap lock, we have observed heavy heap lock contention on memory allocation path in performance analysis of some service in which we tried to adopt Shenandoah. This change is to propose an optimization for the code path of mutator memory allocation to improve heap lock contention, at vey high level, here is how it works:
> * ShenandoahFreeSet holds a N (default to 13) number of ShenandoahHeapRegion* which are used by mutator threads for regular object allocations, they are called shared regions/directly allocatable regions, which are stored in PaddedEnd data structure(padded array).
> * Each mutator thread will be assigned one of the directly allocatable regions, the thread will try to allocate in the directly allocatable region with CAS atomic operation, if fails will try 2 more consecutive  directly allocatable regions in the array storing directly allocatable region.
> * If mutator thread fails after trying 3 directly allocatable regions, it will:
>    * Take heap lock
>    * Try to retire the directly allocatable regions which are ready to retire.
>    *  Iterator mutator partition and allocate directly allocatable regions and store to the padded array if any need to be retired.
>    *  Satisfy mutator allocation request if possible.
> 
> 
> I'm not expecting significant performance impact for most of the cases since in most case the contention on heap lock it not high enough to cause performance issue, I have done many tests, here are some of them:
> 
> 1. Dacapo lusearch test on EC2 host with 96 CPU cores:
> Openjdk TIP:
> 
> [ec2-user at ip-172-31-42-91 jdk]$ ./master-jdk/bin/java -XX:-TieredCompilation -XX:+AlwaysPreTouch -Xms4G -Xmx4G -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:+UnlockDiagnosticVMOptions  -XX:-ShenandoahUncommit -XX:ShenandoahGCMode=generational  -XX:+UseTLAB -jar ~/tools/dacapo/dacapo-23.11-MR2-chopin.jar  -n 10 lusearch  | grep "metered full smoothing"
> ===== DaCapo tail latency, metered full smoothing: 50% 131684 usec, 90% 200192 usec, 99% 211369 usec, 99.9% 212517 usec, 99.99% 213043 usec, max 235289 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 1568 usec, 90% 36101 usec, 99% 42172 usec, 99.9% 42928 usec, 99.99% 43100 usec, max 43305 usec, measured over 524288 events =====
> ===== DaCapo tail latency, metered full smoothing: 50% 52644 usec, 90% 124393 usec, 99% 137711 usec, 99.9% 139355 usec, 99.99% 139749 usec, max 146722 usec, measured over 524288 events ====...

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

 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'openjdk:master' into cas-alloc-1
 - format
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Merge branch 'master' into cas-alloc-1
 - Move ShenandoahHeapRegionIterationClosure to shenandoahFreeSet.hpp
 - Merge branch 'openjdk:master' into cas-alloc-1
 - Fix errors caused by renaming ofAtomic to AtomicAccess
 - Merge branch 'openjdk:master' into cas-alloc-1
 - ... and 125 more: https://git.openjdk.org/jdk/compare/2f613911...e6bfef05

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

Changes: https://git.openjdk.org/jdk/pull/26171/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26171&range=04
  Stats: 735 lines in 16 files changed: 674 ins; 7 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/26171.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26171/head:pull/26171

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

From syan at openjdk.org  Tue Oct 28 01:24:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 28 Oct 2025 01:24:11 GMT
Subject: RFR: 8370649: Add intermittent tag for
 gc/shenandoah/generational/TestOldGrowthTriggers.java
In-Reply-To: <QagaeQM-zcMSvaWjvJfFJqC1_daCKvcGYiEz6Ql2IKk=.87822603-fd98-4d6b-9b24-77c592ccb2a2@github.com>
References: <x7NXwU4vAyRvPiUjceN2dxSGFmtBZ_s5kn8yYR7bd4o=.635500ec-8789-460b-947e-c8e1f9ec28bf@github.com>
 <QagaeQM-zcMSvaWjvJfFJqC1_daCKvcGYiEz6Ql2IKk=.87822603-fd98-4d6b-9b24-77c592ccb2a2@github.com>
Message-ID: <9ysx-wUFeHHX5b2P7jGI5Rt2t2KlqH-paYaYeAAN2s8=.78781c4b-6cc8-467e-9eb4-88dd94c7c820@github.com>

On Mon, 27 Oct 2025 17:47:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Hi all,
>> 
>> Test gc/shenandoah/generational/TestOldGrowthTriggers.java intermittent fails "'Trigger (Old): Old has overgrown' missing from stdout/stderr" with default JVM options by fastdebug build on linux-aarch64. The failure probability about 1/100.
>> 
>> Should we add '@key intermittent' tag for this test until the root cause has been fixed. The '@key intermittent' tag make some test infrasture disable or rerun this test automaticly when it's intermittent fails.
>> 
>> Test-fix only. no risk.
>
> Thank you for this PR. We will still investigate the test failure.

Thanks for the reviews @earthling-amzn

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

PR Comment: https://git.openjdk.org/jdk/pull/27986#issuecomment-3454025662

From syan at openjdk.org  Tue Oct 28 01:24:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 28 Oct 2025 01:24:12 GMT
Subject: Integrated: 8370649: Add intermittent tag for
 gc/shenandoah/generational/TestOldGrowthTriggers.java
In-Reply-To: <x7NXwU4vAyRvPiUjceN2dxSGFmtBZ_s5kn8yYR7bd4o=.635500ec-8789-460b-947e-c8e1f9ec28bf@github.com>
References: <x7NXwU4vAyRvPiUjceN2dxSGFmtBZ_s5kn8yYR7bd4o=.635500ec-8789-460b-947e-c8e1f9ec28bf@github.com>
Message-ID: <YLl9oHdNhJzcToenaHIFQjJ5VrzlxdzI3HhTosBZrZo=.7dda50ed-4e31-461e-938b-ece511826209@github.com>

On Sat, 25 Oct 2025 01:50:25 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test gc/shenandoah/generational/TestOldGrowthTriggers.java intermittent fails "'Trigger (Old): Old has overgrown' missing from stdout/stderr" with default JVM options by fastdebug build on linux-aarch64. The failure probability about 1/100.
> 
> Should we add '@key intermittent' tag for this test until the root cause has been fixed. The '@key intermittent' tag make some test infrasture disable or rerun this test automaticly when it's intermittent fails.
> 
> Test-fix only. no risk.

This pull request has now been integrated.

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

8370649: Add intermittent tag for gc/shenandoah/generational/TestOldGrowthTriggers.java

Reviewed-by: wkemper

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

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

From dholmes at openjdk.org  Tue Oct 28 03:27:03 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Oct 2025 03:27:03 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v8]
In-Reply-To: <cqcQvTn_HuW6vnkLDhzL7NOzJD9n6VrnFf2ylbIrhlo=.4646b21f-0195-4884-8c7f-c1dd4d6b2526@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <cqcQvTn_HuW6vnkLDhzL7NOzJD9n6VrnFf2ylbIrhlo=.4646b21f-0195-4884-8c7f-c1dd4d6b2526@github.com>
Message-ID: <KIaL4YwJahqRS1AAnHomAh8V9ljnsNwpjFnyPS4qh-4=.39ed0a8d-69ea-436b-9281-acf8a338113f@github.com>

On Mon, 20 Oct 2025 07:54:40 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:
> 
>   subtraction for checking overflow

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

> 286:   // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value.
> 287:   // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx.
> 288:   if (std::numeric_limits<size_t>::max() - value < MaxHeapSize) { // overflow

Sorry but I still don't see how this new check is in practice any different to the existing (albeit conditional) `(value > (max_uintx - MaxHeapSize))`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2467769558

From alanb at openjdk.org  Tue Oct 28 07:00:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 07:00:03 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <QV5x3ifu4W23G6ObLyr0N87dJl42FMVMrbhQfxCLnlg=.1e26456b-b77d-44b3-94ec-d2956abadd59@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1044:

> 1042:      * already cancelled. This interrupts the threads executing unfinished subtasks. This
> 1043:      * method then waits for all threads to finish. If interrupted while waiting then it
> 1044:      * will continue to wait until the threads finish, before completing with the interrupted

Can you drop the change to this file from the PR as we have reworded this paragraph as part of the updated for JEP 525.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468133283

From alanb at openjdk.org  Tue Oct 28 07:52:03 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 07:52:03 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <lkMcK5XyH2Y_la8uIGT2EbV_PfVSagbCirDpFoiPhNI=.218bbaec-0ad7-48be-9909-29668893d58d@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

I skimmed through the replace and it looks okay. There are several places where we should be linking as "interrupted status" will look like a grammatical error with the change. We do that as needed, not this PR.

This is the first update to some of these files in 2025 so you will need to update the copyright header of those files.

src/java.base/share/classes/java/net/DatagramSocket.java line 614:

> 612:      *        interrupting a thread receiving a datagram packet will close the
> 613:      *        underlying channel and cause this method to throw {@link
> 614:      *        java.nio.channels.ClosedByInterruptException} with the interrupted

Can you change this to "the thread's interrupted status set"?

src/java.base/share/classes/java/net/DatagramSocket.java line 620:

> 618:      *        datagram packet. In that case, interrupting the virtual thread will
> 619:      *        cause it to wakeup and close the socket. This method will then throw
> 620:      *        {@code SocketException} with the interrupted status set.

Same thing here, and in ServerSocket and Socket.

test/jdk/java/lang/Thread/virtual/CustomScheduler.java line 207:

> 205: 
> 206:     /**
> 207:      * Test running task with the carrier interrupted status set.

We can change this to "the carrier's interrupted status set".

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387081610
PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468253205
PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468257078
PR Review Comment: https://git.openjdk.org/jdk/pull/27972#discussion_r2468273763

From azafari at openjdk.org  Tue Oct 28 09:35:20 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 28 Oct 2025 09:35:20 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v8]
In-Reply-To: <KIaL4YwJahqRS1AAnHomAh8V9ljnsNwpjFnyPS4qh-4=.39ed0a8d-69ea-436b-9281-acf8a338113f@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <cqcQvTn_HuW6vnkLDhzL7NOzJD9n6VrnFf2ylbIrhlo=.4646b21f-0195-4884-8c7f-c1dd4d6b2526@github.com>
 <KIaL4YwJahqRS1AAnHomAh8V9ljnsNwpjFnyPS4qh-4=.39ed0a8d-69ea-436b-9281-acf8a338113f@github.com>
Message-ID: <zE8nqxuIWvZ6ZelZtl0uBNeB1YV_h27xpWePneIWBy4=.19533555-4ba8-475c-9d23-3261f5f1222d@github.com>

On Tue, 28 Oct 2025 03:24:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   subtraction for checking overflow
>
> src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288:
> 
>> 286:   // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value.
>> 287:   // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx.
>> 288:   if (std::numeric_limits<size_t>::max() - value < MaxHeapSize) { // overflow
> 
> Sorry but I still don't see how this new check is in practice any different to the existing (albeit conditional) `(value > (max_uintx - MaxHeapSize))`?

No difference other than not depends on the other conditions. The existing condition needs two more conjunctions to be true.
Without this change here, when we run jvm with the options as shown in this [comment](https://github.com/openjdk/jdk/pull/26955#issuecomment-3241790796 
) (to make the HeapMinBaseAddress overflow) it crashes with an assertion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2468720165

From jsikstro at openjdk.org  Tue Oct 28 09:51:24 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 28 Oct 2025 09:51:24 GMT
Subject: RFR: 8370417: Parallel: TestAlwaysPreTouchBehavior.java fails with
 NUMA
In-Reply-To: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
References: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
Message-ID: <qcGO0Lo6wWKJ6KnqD6F7WL8YvEarRQ8hxJzH7zag16U=.5b1af4de-e836-4de8-8225-47705323ea05@github.com>

On Mon, 27 Oct 2025 14:52:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Perform pretouching for pages in eden + NUMA. The preceding `bias_region` calls will associate each OS page to the desired NUMA node.
> 
> Test: tier1-5

Looks good. Works on my NUMA machine.

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

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28000#pullrequestreview-3387738770

From dholmes at openjdk.org  Tue Oct 28 10:01:41 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Oct 2025 10:01:41 GMT
Subject: RFR: 8369392: Safepoint sync should suspend GC and Java threads
 concurrently
In-Reply-To: <lSHOlZaZLYem0Pl_-fjEuLLw4RXFh2eOHJ_7s8gomIg=.2ac597ce-54fc-465a-a682-b3d1c8812945@github.com>
References: <lSHOlZaZLYem0Pl_-fjEuLLw4RXFh2eOHJ_7s8gomIg=.2ac597ce-54fc-465a-a682-b3d1c8812945@github.com>
Message-ID: <U8kg5eSPaujMPbAkM_0eglGyrArzZXcvfjsaLCGwrls=.8586a09b-8e3e-457b-8537-333fb10b2639@github.com>

On Tue, 21 Oct 2025 20:00:15 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> As @shipilev  mentioned in the description description of [JDK-8369392](https://bugs.openjdk.org/browse/JDK-8369392), we could rearrange the code and ask GC to suspend after announcing safepoint, GC threads and Java threads will sync simultaneously. [The other option](https://github.com/openjdk/jdk/pull/27739/files) I have test is to split STS synchronize into `synchronize_begin` and `synchronize`, which makes GC thread suspension fully aysnc(same Java threads), but I didn't see big performance difference, therefore I chose the simple solution suggested by Aleksey. 
> 
> 
> Test:
> - [x] tier1

This is really for GC folk to decide upon but a few general comments.

This seems like a reasonable hypothesis but the JBS issue does not provide any detailed performance results for each of the GCs to shows the hypothesis is correct and there is some actual value to doing this.

Tier1 testing alone does not seem sufficient to me. And which GCs on which platforms were tested?

I have to wonder whether suspending the GC threads after taking the Threads_lock could have any unintended consequences?

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

PR Comment: https://git.openjdk.org/jdk/pull/27924#issuecomment-3455557440

From prappo at openjdk.org  Tue Oct 28 10:06:36 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Oct 2025 10:06:36 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v2]
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <yc7z0Iro9HRJNOfaF6av4z0ZeBJ7UAG2lKTz7k21h68=.88323ef5-6349-4360-8306-442113ec3de0@github.com>

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision:

 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
    + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
    + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
    + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
    + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
    + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf
    + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d
    + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d
 - Reword for clarity as suggested
 - Drop to ease upcoming merge from loom repo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27972/files
  - new: https://git.openjdk.org/jdk/pull/27972/files/a10f8b43..89dbafe0

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

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

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

From alanb at openjdk.org  Tue Oct 28 10:10:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 10:10:11 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v2]
In-Reply-To: <yc7z0Iro9HRJNOfaF6av4z0ZeBJ7UAG2lKTz7k21h68=.88323ef5-6349-4360-8306-442113ec3de0@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <yc7z0Iro9HRJNOfaF6av4z0ZeBJ7UAG2lKTz7k21h68=.88323ef5-6349-4360-8306-442113ec3de0@github.com>
Message-ID: <lepfhtvr9Gy7c6wi7Lww4O5l_Fc9HqBdmYsTqOe51Pc=.0e9c56fd-40bc-460c-87f3-aa34f659d111@github.com>

On Tue, 28 Oct 2025 10:06:36 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
>     + update test/...

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3387827557

From dholmes at openjdk.org  Tue Oct 28 10:34:06 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 28 Oct 2025 10:34:06 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v8]
In-Reply-To: <zE8nqxuIWvZ6ZelZtl0uBNeB1YV_h27xpWePneIWBy4=.19533555-4ba8-475c-9d23-3261f5f1222d@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <cqcQvTn_HuW6vnkLDhzL7NOzJD9n6VrnFf2ylbIrhlo=.4646b21f-0195-4884-8c7f-c1dd4d6b2526@github.com>
 <KIaL4YwJahqRS1AAnHomAh8V9ljnsNwpjFnyPS4qh-4=.39ed0a8d-69ea-436b-9281-acf8a338113f@github.com>
 <zE8nqxuIWvZ6ZelZtl0uBNeB1YV_h27xpWePneIWBy4=.19533555-4ba8-475c-9d23-3261f5f1222d@github.com>
Message-ID: <V_q4Y0qgXwXx4qsV7TI5yWRr-ylb9-lA9o6PxIHwSvI=.7ca20f28-39da-45dd-b191-cda9320b1b80@github.com>

On Tue, 28 Oct 2025 09:32:04 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288:
>> 
>>> 286:   // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value.
>>> 287:   // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx.
>>> 288:   if (std::numeric_limits<size_t>::max() - value < MaxHeapSize) { // overflow
>> 
>> Sorry but I still don't see how this new check is in practice any different to the existing (albeit conditional) `(value > (max_uintx - MaxHeapSize))`?
>
> No difference other than not depends on the other conditions. The existing condition needs two more conjunctions to be true.
> Without this change here, when we run jvm with the options as shown in this [comment](https://github.com/openjdk/jdk/pull/26955#issuecomment-3241790796 
> ) (to make the HeapMinBaseAddress overflow) it crashes with an assertion.

If they are the same then we no longer need the conditional one surely. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2468950628

From tschatzl at openjdk.org  Tue Oct 28 11:09:06 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 28 Oct 2025 11:09:06 GMT
Subject: RFR: 8370417: Parallel: TestAlwaysPreTouchBehavior.java fails with
 NUMA
In-Reply-To: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
References: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
Message-ID: <pUud-2Hj_JpQXuDJwoEDo4CUOba3AJhzAM8hTME_TBc=.68a0efc4-bad9-4bea-92af-f0f1c8b7fca4@github.com>

On Mon, 27 Oct 2025 14:52:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Perform pretouching for pages in eden + NUMA. The preceding `bias_region` calls will associate each OS page to the desired NUMA node.
> 
> Test: tier1-5

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28000#pullrequestreview-3388133954

From ayang at openjdk.org  Tue Oct 28 12:22:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 28 Oct 2025 12:22:16 GMT
Subject: RFR: 8370417: Parallel: TestAlwaysPreTouchBehavior.java fails with
 NUMA
In-Reply-To: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
References: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
Message-ID: <wpqsIMRNf6d_RB08IVvkrHZ3kvWtlXla7MAERTc1ZiE=.3ae60747-1430-491c-9859-48a5d696fb8c@github.com>

On Mon, 27 Oct 2025 14:52:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Perform pretouching for pages in eden + NUMA. The preceding `bias_region` calls will associate each OS page to the desired NUMA node.
> 
> Test: tier1-5

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28000#issuecomment-3456181310

From ayang at openjdk.org  Tue Oct 28 12:22:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 28 Oct 2025 12:22:16 GMT
Subject: Integrated: 8370417: Parallel: TestAlwaysPreTouchBehavior.java fails
 with NUMA
In-Reply-To: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
References: <ICi6TYrizzoNzsv1Q0PMJStYxeMxC7o6vaCwkPOJ514=.c469e4aa-e85f-49d0-bf71-36a8d8486322@github.com>
Message-ID: <e4lqPsM0fJKV6-d-06ulLIcb0KwxFJCCQugjdhq46yM=.8e456919-928b-4792-b225-e04da6007802@github.com>

On Mon, 27 Oct 2025 14:52:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Perform pretouching for pages in eden + NUMA. The preceding `bias_region` calls will associate each OS page to the desired NUMA node.
> 
> Test: tier1-5

This pull request has now been integrated.

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

8370417: Parallel: TestAlwaysPreTouchBehavior.java fails with NUMA

Reviewed-by: iveresov, jsikstro, tschatzl

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

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

From ayang at openjdk.org  Tue Oct 28 12:27:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 28 Oct 2025 12:27:33 GMT
Subject: RFR: 8370806: Parallel: Revise logs in
 PSYoungGen::compute_desired_sizes
Message-ID: <P8SdHixd52hImm2Ag0vRbCevG-9klwzc7UZ1iH7nLGs=.19e569e1-6e03-48fe-88c5-14c0abf9546c@github.com>

Trivial removing extraneous `)` in logs.

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

Commit messages:
 - pgc-log-trivial

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

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

From tschatzl at openjdk.org  Tue Oct 28 12:36:05 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 28 Oct 2025 12:36:05 GMT
Subject: RFR: 8370806: Parallel: Revise logs in
 PSYoungGen::compute_desired_sizes
In-Reply-To: <P8SdHixd52hImm2Ag0vRbCevG-9klwzc7UZ1iH7nLGs=.19e569e1-6e03-48fe-88c5-14c0abf9546c@github.com>
References: <P8SdHixd52hImm2Ag0vRbCevG-9klwzc7UZ1iH7nLGs=.19e569e1-6e03-48fe-88c5-14c0abf9546c@github.com>
Message-ID: <l4dihsuZFyij0AJtBOh2MalB1Dh5ILN61kdXL6FPrbk=.8b170b43-cec1-4e98-bcc6-335776a6c17d@github.com>

On Tue, 28 Oct 2025 12:19:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing extraneous `)` in logs.

Trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28019#pullrequestreview-3388547954

From ayang at openjdk.org  Tue Oct 28 13:25:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 28 Oct 2025 13:25:11 GMT
Subject: RFR: 8370806: Parallel: Revise logs in
 PSYoungGen::compute_desired_sizes
In-Reply-To: <P8SdHixd52hImm2Ag0vRbCevG-9klwzc7UZ1iH7nLGs=.19e569e1-6e03-48fe-88c5-14c0abf9546c@github.com>
References: <P8SdHixd52hImm2Ag0vRbCevG-9klwzc7UZ1iH7nLGs=.19e569e1-6e03-48fe-88c5-14c0abf9546c@github.com>
Message-ID: <c94D-qWWimwk4Co7C2S8p61AzRud_qjQWmXDM20KWok=.5add3f69-b077-42d9-89ba-e15829e019bc@github.com>

On Tue, 28 Oct 2025 12:19:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing extraneous `)` in logs.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/28019#issuecomment-3456434828

From ayang at openjdk.org  Tue Oct 28 13:25:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 28 Oct 2025 13:25:12 GMT
Subject: Integrated: 8370806: Parallel: Revise logs in
 PSYoungGen::compute_desired_sizes
In-Reply-To: <P8SdHixd52hImm2Ag0vRbCevG-9klwzc7UZ1iH7nLGs=.19e569e1-6e03-48fe-88c5-14c0abf9546c@github.com>
References: <P8SdHixd52hImm2Ag0vRbCevG-9klwzc7UZ1iH7nLGs=.19e569e1-6e03-48fe-88c5-14c0abf9546c@github.com>
Message-ID: <DdSOzqR7JdLmxT4T_4_h-nXC9GI-vm7dLAbD8wZ6JoE=.8e0539bb-e3e9-4015-b4c6-21a228201135@github.com>

On Tue, 28 Oct 2025 12:19:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing extraneous `)` in logs.

This pull request has now been integrated.

Changeset: 307637a4
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/307637a4973801abb9969fad41b017aa6a153973
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8370806: Parallel: Revise logs in PSYoungGen::compute_desired_sizes

Reviewed-by: tschatzl

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

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

From prappo at openjdk.org  Tue Oct 28 14:25:06 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 28 Oct 2025 14:25:06 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

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

 - Merge remote-tracking branch 'jdk/master' into 8370568
 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
    + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
    + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
    + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
    + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
    + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf
    + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d
    + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d
 - Reword for clarity as suggested
 - Drop to ease upcoming merge from loom repo
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27972/files
  - new: https://git.openjdk.org/jdk/pull/27972/files/89dbafe0..b3297337

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

  Stats: 3639 lines in 160 files changed: 1891 ins; 1140 del; 608 mod
  Patch: https://git.openjdk.org/jdk/pull/27972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972

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

From duke at openjdk.org  Tue Oct 28 17:33:38 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 28 Oct 2025 17:33:38 GMT
Subject: RFR: 8369013: Shenandoah: passive mode should support enabling
 ShenandoahCardBarrier
Message-ID: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>

Add card barriers to passive mode to test out the price of card barriers. 

How this change is implemented is to instantiate the old region in passive mode - old region owns the card table so this would minimize the code change with a bit price of native memory. It does sound weird to have old gen in passive mode, but since passive mode is a just diagnostic mode, we'll go with it for the cleanliness of the change.

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

Commit messages:
 - Missed UnlockDiagnosticVMOptions
 - Corrected copyright header
 - Addressed comments and added a test
 - 8369013: Shenandoah: passive mode should support enabling ShenandoahCardBarrier

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

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

From duke at openjdk.org  Tue Oct 28 17:33:43 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 28 Oct 2025 17:33:43 GMT
Subject: RFR: 8369013: Shenandoah: passive mode should support enabling
 ShenandoahCardBarrier
In-Reply-To: <IC9iRd85al7PvkX5Petc-7f2TVXrZXDBLkLn7dTB2Ng=.6bffddaf-dfa3-4c2a-bafb-123e7e834a83@github.com>
References: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
 <IC9iRd85al7PvkX5Petc-7f2TVXrZXDBLkLn7dTB2Ng=.6bffddaf-dfa3-4c2a-bafb-123e7e834a83@github.com>
Message-ID: <7fmLPWnHWEMLkVD5t_cXpkH_-WQ3-5Pxz7aGw4lbjsE=.a462aebf-32e1-4b88-a84a-f719a26897fe@github.com>

On Fri, 24 Oct 2025 20:44:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Add card barriers to passive mode to test out the price of card barriers. 
>> 
>> How this change is implemented is to instantiate the old region in passive mode - old region owns the card table so this would minimize the code change with a bit price of native memory. It does sound weird to have old gen in passive mode, but since passive mode is a just diagnostic mode, we'll go with it for the cleanliness of the change.
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp line 47:
> 
>> 45: 
>> 46:   static ShenandoahGenerationalHeap* heap() {
>> 47:     shenandoah_assert_generational();
> 
> Can we put these assertions back? I don't see any code in the PR that would invalidate these assertions. I also don't see any changes that would instantiate the generational heap for non generational mode, so if there _is_ code trying to use the generational heap, its behavior will be undefined.

It would crash at here with the assertion: [code](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp#L65). Provided some of the stacktrace below. It's mostly because we enabled card barrier flag and the code just fell through and assumes it's generational.

Would it be more appropriate to change [this line](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp#L65) to be `ShenandoahHeap* heap = ShenandoahHeap::heap();`?




Stack: [0x00007f1082bd2000,0x00007f1082cd2000],  sp=0x00007f1082cce370,  free space=1008k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x13e0e90]  NativeStackPrinter::print_stack(outputStream*, char*, int, unsigned char*&, bool
, int)+0x70  (shenandoahGenerationalHeap.hpp:47)
V  [libjvm.so+0x18fd2e9]  VMError::report(outputStream*, bool)+0x1bff  (vmError.cpp:979)
V  [libjvm.so+0x1900d01]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, 
unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x8b1  (vmError.cpp:1887)
V  [libjvm.so+0xacf5ca]  report_vm_status_error(char const*, int, char const*, int, char const*)+0x0  (deb
ug.cpp:196)
V  [libjvm.so+0xacf33b]  print_error_for_unit_test(char const*, char const*, __va_list_tag*)+0x0  (debug.c
pp:149)
V  [libjvm.so+0x15bbec1]  ShenandoahAsserts::assert_generational(char const*, int)+0x8b  (shenandoahAssert
s.cpp:532)
V  [libjvm.so+0x15be196]  ShenandoahGenerationalHeap::heap()+0x19  (shenandoahGenerationalHeap.hpp:47)
V  [libjvm.so+0x16993bc]  void card_mark_barrier<narrowOop>(narrowOop*, oopDesc*)+0x73  (shenandoahReferenceProcessor.cpp:65)
V  [libjvm.so+0x169a2ac]  bool ShenandoahReferenceProcessor::discover<narrowOop>(oopDesc*, ReferenceType, unsigned int)+0x1da  (shenandoahReferenceProcessor.cpp:409)
V  [libjvm.so+0x1698a5d]  ShenandoahReferenceProcessor::discover_reference(oopDesc*, ReferenceType)+0xed  (shenandoahReferenceProcessor.cpp:433)
V  [libjvm.so+0x1684aeb]  bool InstanceRefKlass::try_discover<narrowOop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0> >(oopDesc*, ReferenceType, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0>*)+0x77  (instanceRefKlass.inline.hpp:74)
V  [libjvm.so+0x1682bfc]  void InstanceRefKlass::oop_oop_iterate_discovery<narrowOop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0>, AlwaysContains>(oopDesc*, ReferenceType, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0>*, AlwaysContains&)+0x2c  (instanceRefKlass.inline.hpp:84)
V  [libjvm.so+0x1680acc]  void InstanceRefKlass::oop_oop_iterate_ref_processing<narrowOop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0>, AlwaysContains>(oopDesc*, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0>*, AlwaysContains&)+0x80  (instanceRefKlass.inline.hpp:111)
V  [libjvm.so+0x167ec2e]  void InstanceRefKlass::oop_oop_iterate_ref_processing<narrowOop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0> >(oopDesc*, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0>*)+0x2c  (instanceRefKlass.inline.hpp:134)
V  [libjvm.so+0x167ba88]  void InstanceRefKlass::oop_oop_iterate<narrowOop, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0> >(oopDesc*, ShenandoahMarkRefsClosure<(ShenandoahGenerationType)0>*)+0x16c  (instanceRefKlass.inline.hpp:154)

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 255:
> 
>> 253:   // for the purpose of having card table.
>> 254:   if (ShenandoahCardBarrier && !(mode()->is_generational())) {
>> 255:     _generation_sizer.heap_size_changed(max_capacity());
> 
> I think we could simplify here by not using the `_generation_sizer`. It should be fine to pass `max_capacity()` instead of `max_capacity_old` here.

Yeah that'd be simpler. Updating. Thanks.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp line 533:
> 
>> 531: 
>> 532:   ShenandoahOldGeneration*   old_generation()    const {
>> 533:     assert(mode()->is_generational(), "Old generation requires generational mode");
> 
> Can we assert that `ShenandoahCardBarrier` is on instead of removing this assertion?

Sure

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27966#discussion_r2462100322
PR Review Comment: https://git.openjdk.org/jdk/pull/27966#discussion_r2462131735
PR Review Comment: https://git.openjdk.org/jdk/pull/27966#discussion_r2462100239

From wkemper at openjdk.org  Tue Oct 28 17:33:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Oct 2025 17:33:42 GMT
Subject: RFR: 8369013: Shenandoah: passive mode should support enabling
 ShenandoahCardBarrier
In-Reply-To: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
References: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
Message-ID: <IC9iRd85al7PvkX5Petc-7f2TVXrZXDBLkLn7dTB2Ng=.6bffddaf-dfa3-4c2a-bafb-123e7e834a83@github.com>

On Fri, 24 Oct 2025 00:18:03 GMT, Rui Li <duke at openjdk.org> wrote:

> Add card barriers to passive mode to test out the price of card barriers. 
> 
> How this change is implemented is to instantiate the old region in passive mode - old region owns the card table so this would minimize the code change with a bit price of native memory. It does sound weird to have old gen in passive mode, but since passive mode is a just diagnostic mode, we'll go with it for the cleanliness of the change.

This turned out to be simpler than expected. Nice work. I suggest some small changes.

src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.hpp line 47:

> 45: 
> 46:   static ShenandoahGenerationalHeap* heap() {
> 47:     shenandoah_assert_generational();

Can we put these assertions back? I don't see any code in the PR that would invalidate these assertions. I also don't see any changes that would instantiate the generational heap for non generational mode, so if there _is_ code trying to use the generational heap, its behavior will be undefined.

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

> 253:   // for the purpose of having card table.
> 254:   if (ShenandoahCardBarrier && !(mode()->is_generational())) {
> 255:     _generation_sizer.heap_size_changed(max_capacity());

I think we could simplify here by not using the `_generation_sizer`. It should be fine to pass `max_capacity()` instead of `max_capacity_old` here.

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

> 531: 
> 532:   ShenandoahOldGeneration*   old_generation()    const {
> 533:     assert(mode()->is_generational(), "Old generation requires generational mode");

Can we assert that `ShenandoahCardBarrier` is on instead of removing this assertion?

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

> 564:   // For exporting to SA
> 565:   int                          _log_min_obj_alignment_in_bytes;
> 566:   ShenandoahGenerationSizer     _generation_sizer;

I don't think we need this here.

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27966#pullrequestreview-3378765228
PR Review Comment: https://git.openjdk.org/jdk/pull/27966#discussion_r2461936571
PR Review Comment: https://git.openjdk.org/jdk/pull/27966#discussion_r2461923434
PR Review Comment: https://git.openjdk.org/jdk/pull/27966#discussion_r2461925051
PR Review Comment: https://git.openjdk.org/jdk/pull/27966#discussion_r2461928806

From wkemper at openjdk.org  Tue Oct 28 20:54:05 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Oct 2025 20:54:05 GMT
Subject: RFR: 8370726: GenShen: Misplaced assertion that old referent is marked
 during young collection
Message-ID: <5L_CsIwXfAAGEIcPhVkxeBWa4CtaJ5SBDwQxQZTUg4o=.8a624a29-3c90-4b33-9467-415016a7c36d@github.com>

Recently introduced assertion is too strong:

#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (/codebuild/output/src2096/src/s3/00/src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp:332), pid=1373, tid=1375
# Error: Marking should be complete for object 0x00000007ffc029b0 in the Old generation

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

Commit messages:
 - Something in full gc still needs 'active' generation?
 - Give reference processor a generation field

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

PR: https://git.openjdk.org/jdk/pull/28026

From wkemper at openjdk.org  Tue Oct 28 20:57:34 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Oct 2025 20:57:34 GMT
Subject: RFR: 8370667: TestPinnedGarbage.java intermittent trigger assert
 Region \d+ pinning status is inconsistent
Message-ID: <qwMPg0AlulQm41xokIJdJrHjxr6_8czjsgfRBFE0A4U=.b1d8de31-7136-4549-83c6-29b50964b2b7@github.com>

This broke recently because we expanded the scope of the assertion to check all regions. However, there are times when the pin status for a region is only updated if the region belongs to the generation being collected. This change restores the previous behavior of the assertion.

-------------

Commit messages:
 - Only verify region pins for collected generation

Changes: https://git.openjdk.org/jdk/pull/28027/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28027&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370667
  Stats: 13 lines in 4 files changed: 7 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/28027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28027/head:pull/28027

PR: https://git.openjdk.org/jdk/pull/28027

From wkemper at openjdk.org  Tue Oct 28 21:35:04 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 28 Oct 2025 21:35:04 GMT
Subject: RFR: 8369013: Shenandoah: passive mode should support enabling
 ShenandoahCardBarrier
In-Reply-To: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
References: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
Message-ID: <2lQ8u6wu_P-mNdo4R9VY9BaqGc24tL7H5eher3hgx28=.e7f574eb-94b3-4c6f-8f3a-e81757c59e1b@github.com>

On Fri, 24 Oct 2025 00:18:03 GMT, Rui Li <duke at openjdk.org> wrote:

> Add card barriers to passive mode to test out the price of card barriers. 
> 
> How this change is implemented is to instantiate the old region in passive mode - old region owns the card table so this would minimize the code change with a bit price of native memory. It does sound weird to have old gen in passive mode, but since passive mode is a just diagnostic mode, we'll go with it for the cleanliness of the change.

Looks good. I think we should clear the card table for each degenerated cycle. Thank you for adding the test!

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1177:

> 1175: 
> 1176:   // passive mode with ShenandoahCardBarrier turned on, clean the write table without swapping the tables
> 1177:   if (ShenandoahCardBarrier && !heap->mode()->is_generational()) {

In general, the passive mode will only initiate a _degenerated_ cycle. It will run a full GC only if the degenerated cycle cannot evacuate or it doesn't make "good progress". Could we move this behavior into `shDegeneratedGC` or somewhere in `shPassiveHeuristic`? Cleaning the card table on every GC would be more aligned with the concurrent mode behavior.

-------------

PR Review: https://git.openjdk.org/jdk/pull/27966#pullrequestreview-3390877820
PR Review Comment: https://git.openjdk.org/jdk/pull/27966#discussion_r2471100098

From xpeng at openjdk.org  Tue Oct 28 21:42:30 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 28 Oct 2025 21:42:30 GMT
Subject: RFR: 8369392: Safepoint sync should suspend GC and Java threads
 concurrently
In-Reply-To: <onIu_olSbf2sk7N1rfB3N86d_Z97LFWFHQJdxbRQohg=.5db63563-ee11-4dcc-a821-c382e4abf86c@github.com>
References: <lSHOlZaZLYem0Pl_-fjEuLLw4RXFh2eOHJ_7s8gomIg=.2ac597ce-54fc-465a-a682-b3d1c8812945@github.com>
 <onIu_olSbf2sk7N1rfB3N86d_Z97LFWFHQJdxbRQohg=.5db63563-ee11-4dcc-a821-c382e4abf86c@github.com>
Message-ID: <EzEC80x0QC6PhPCyaNP5VfGl7us5bXA73kTMq4M5xXk=.1646cf29-467b-466d-a345-fb0cd1d418ab@github.com>

On Tue, 28 Oct 2025 06:53:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I don't think this should be done for ZGC. We intentionally perform the lengthy GC syncronization before we start to synchronize the Java thread. With the proposed change the Java threads could end up blocking longer because they now also have to wait for the GC threads to synchronize.

Thanks for the feedback, now I think I know why Kim said it won't help ZGC. The simple solution in PR applies to all GCs, we may still the more sophisticated solution like https://github.com/openjdk/jdk/pull/27739 so we can control the behavior on individual GC if necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27924#issuecomment-3458606384

From duke at openjdk.org  Wed Oct 29 01:13:53 2025
From: duke at openjdk.org (Rui Li)
Date: Wed, 29 Oct 2025 01:13:53 GMT
Subject: RFR: 8369013: Shenandoah: passive mode should support enabling
 ShenandoahCardBarrier [v2]
In-Reply-To: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
References: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
Message-ID: <kLIIvY_00AF-WOL9vM3fIg1i_itrnbJDyXHMbhuerGQ=.40637b69-7c5f-4701-8799-294ebe863a11@github.com>

> Add card barriers to passive mode to test out the price of card barriers. 
> 
> How this change is implemented is to instantiate the old region in passive mode - old region owns the card table so this would minimize the code change with a bit price of native memory. It does sound weird to have old gen in passive mode, but since passive mode is a just diagnostic mode, we'll go with it for the cleanliness of the change.

Rui Li has updated the pull request incrementally with one additional commit since the last revision:

  Move write table clean to degen

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27966/files
  - new: https://git.openjdk.org/jdk/pull/27966/files/ecde5211..e6fdbc60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27966&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27966&range=00-01

  Stats: 11 lines in 2 files changed: 6 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/27966.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27966/head:pull/27966

PR: https://git.openjdk.org/jdk/pull/27966

From rriggs at openjdk.org  Wed Oct 29 01:49:05 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 29 Oct 2025 01:49:05 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
Message-ID: <v3sPAyJyhuAw4LHK4-chOQbBYB7dYiwWKkEywWCr9XM=.1215b812-d7f6-4217-af78-e753b53dd64d@github.com>

On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test...

Nice cleanup.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3391422490

From syan at openjdk.org  Wed Oct 29 03:50:27 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 29 Oct 2025 03:50:27 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v4]
In-Reply-To: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
Message-ID: <u4_yr8XlcwExJvlTEGVRHKg521NXp4rjqeJSpp63_r8=.47eeaae3-5df2-432b-85b9-0b8e1b4c1f52@github.com>

> Hi all,
> 
> We observed the test vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java intermittent fails. since the target application intermittent OOM. The target application will try to exhaust the heap memory and then trigger garbage collection by `ClassUnloader.eatMemory()` in file test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Target.java.
> 
> So I think it's better to limited the max heap usage of target application. Before this PR, the physical memory usage is about 30.7GB(this depends the total free memory on the test machine), and the jtreg main action take about 11 seconds to finish; After this PR, the physical memory usage is about 126MB, and the jtreg main action take about 0.7 senonds to finish. I use below command to get the usage of physical memory.
> 
> Change has been verified locally, test-fix only, no risk.
> 
> 
> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Use WhiteBox.getWhiteBox().fullGC() instead of ClassUnloader.eatMemory()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28011/files
  - new: https://git.openjdk.org/jdk/pull/28011/files/e69a794a..9d2ae419

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=02-03

  Stats: 56 lines in 19 files changed: 33 ins; 1 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/28011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28011/head:pull/28011

PR: https://git.openjdk.org/jdk/pull/28011

From syan at openjdk.org  Wed Oct 29 03:50:28 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 29 Oct 2025 03:50:28 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v2]
In-Reply-To: <hbE-q4Dd94Yz4DMJJm1osFl5fhZdfRzFRZMqGR3eyMg=.de031c83-9c93-4d24-ac4e-8dd0be4a23f2@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <2jIgGsZc-No5W_YOfNPjkRHfVoqD_qclZBr8YB4GQxw=.1db39abf-d7a7-4405-b910-421f33fde366@github.com>
 <hbE-q4Dd94Yz4DMJJm1osFl5fhZdfRzFRZMqGR3eyMg=.de031c83-9c93-4d24-ac4e-8dd0be4a23f2@github.com>
Message-ID: <wuNvem0__qpgXHj3oVsFa6LSfqd6ddNfFwQJ9XG_K80=.37350128-f9e6-4ea9-bf37-202e9f21dac5@github.com>

On Wed, 29 Oct 2025 03:04:30 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> I think it would be better to use WhiteBox.fullGC()
> 
> It is the fast and robust way to trigger Full GC without risks hitting OOME. The test has been developed before WhiteBox was added.

The 'ClassUnloader.eatMemory()' has been replaced as 'WhiteBox.getWhiteBox().fullGC()' for the 9 releated tests. Change has been verified locally.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28011#issuecomment-3459505044

From syan at openjdk.org  Wed Oct 29 03:55:41 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 29 Oct 2025 03:55:41 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v5]
In-Reply-To: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
Message-ID: <fToeyPN0Xbgrr0JXXpNvGj7vScmpkQfI-NicyIvDPnc=.3d1bde89-2a95-487e-a029-a203a56ebd99@github.com>

> Hi all,
> 
> We observed the test vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java intermittent fails. since the target application intermittent OOM. The target application will try to exhaust the heap memory and then trigger garbage collection by `ClassUnloader.eatMemory()` in file test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Target.java.
> 
> So I think it's better to limited the max heap usage of target application. Before this PR, the physical memory usage is about 30.7GB(this depends the total free memory on the test machine), and the jtreg main action take about 11 seconds to finish; After this PR, the physical memory usage is about 126MB, and the jtreg main action take about 0.7 senonds to finish. I use below command to get the usage of physical memory.
> 
> Change has been verified locally, test-fix only, no risk.
> 
> 
> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Update the test description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28011/files
  - new: https://git.openjdk.org/jdk/pull/28011/files/9d2ae419..f8e72ecf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28011/head:pull/28011

PR: https://git.openjdk.org/jdk/pull/28011

From duke at openjdk.org  Wed Oct 29 04:02:23 2025
From: duke at openjdk.org (duke)
Date: Wed, 29 Oct 2025 04:02:23 GMT
Subject: Withdrawn: 8231269: CompileTask::is_unloaded is slow due to JNIHandles
 type checks
In-Reply-To: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
References: <EHaEtNfaTsFGbyNRL3O-wYfnD1Y6y55o_UpkVz1n3l4=.15aa7c47-f9ea-41a4-b74f-71c571aacdd2@github.com>
Message-ID: <P5leTc21AdqxwdMIc1q9-d-4AX1wWmDayKDFLqCe9U4=.9e588eb5-bea9-4ff0-ac98-7ce7463e177c@github.com>

On Wed, 12 Mar 2025 19:45:41 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> [JDK-8163511](https://bugs.openjdk.org/browse/JDK-8163511) made the `CompileTask` improvement to avoid blocking class unloading if a relevant compile task is in queue. Current code does a sleight-of-hand to make sure the the `method*` in `CompileTask` are still valid before using them. Still a noble goal, so we keep trying to do this.
> 
> The code tries to switch weak JNI handle with a strong one when it wants to capture the holder to block unloading. Since we are reusing the same field, we have to do type checks like `JNIHandles::is_weak_global_handle(_method_holder)`. Unfortunately, that type-check goes all the way to `OopStorage` allocation code to verify the handle is really allocated in the relevant `OopStorage`. This takes internal `OopStorage` locks, and thus is slow.
> 
> This issue is clearly visible in Leyden, when there are lots of `CompileTask`-s in the queue, dumped by AOT code loader. It also does not help that `CompileTask::select_task` is effectively quadratic in number of methods in queue, so we end up calling `CompileTask::is_unloaded` very often.
> 
> It is possible to mitigate this issue by splitting the related fields into weak and strong ones. But as Kim mentions in the bug, we should not be using JNI handles here at all, and instead go directly for relevant `OopStorage`-s. This is what this PR does, among other things that should hopefully make the whole mechanics clearer.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `compiler/classUnloading`, 100x still passes; these tests are sensitive to bugs in this code
>  - [x] Linux x86_64 server fastdebug, `all`
>  - [x] Linux AArch64 server fastdebug, `all`

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/24018

From lmesnik at openjdk.org  Wed Oct 29 04:12:09 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Wed, 29 Oct 2025 04:12:09 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v5]
In-Reply-To: <fToeyPN0Xbgrr0JXXpNvGj7vScmpkQfI-NicyIvDPnc=.3d1bde89-2a95-487e-a029-a203a56ebd99@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <fToeyPN0Xbgrr0JXXpNvGj7vScmpkQfI-NicyIvDPnc=.3d1bde89-2a95-487e-a029-a203a56ebd99@github.com>
Message-ID: <BiWf1-fjH_b7uqLrz4r2S5wq0BTkpIBYKvVBm0iL2Xk=.6a9d4efb-47eb-4faa-b31e-5176bfa0bbf9@github.com>

On Wed, 29 Oct 2025 03:55:41 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> We observed the test vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java intermittent fails. since the target application intermittent OOM. The target application will try to exhaust the heap memory and then trigger garbage collection by `ClassUnloader.eatMemory()` in file test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Target.java.
>> 
>> So I think it's better to limited the max heap usage of target application. Before this PR, the physical memory usage is about 30.7GB(this depends the total free memory on the test machine), and the jtreg main action take about 11 seconds to finish; After this PR, the physical memory usage is about 126MB, and the jtreg main action take about 0.7 senonds to finish. I use below command to get the usage of physical memory.
>> 
>> Change has been verified locally, test-fix only, no risk.
>> 
>> 
>> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update the test description

Changes requested by lmesnik (Reviewer).

test/hotspot/jtreg/vmTestbase/gc/gctests/SoftReference/soft003/soft003.java line 2:

> 1: /*
> 2:  * Copyright (c) 2007, 2025, Oracle and/or its affiliates. All rights reserved.

Only copyright changes in this file.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java line 57:

> 55:  *      -jdk ${test.jdk}
> 56:  *      -target nsk.jvmti.AttachOnDemand.attach020.attach020Target
> 57:  *      -javaOpts="-XX:+UsePerfData -Xmx128M ${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI"

Please remove Xmx128M in all tests, it is not needed now.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/TestDescription.java line 53:

> 51:  *      -jdk ${test.jdk}
> 52:  *      -target nsk.jvmti.AttachOnDemand.attach021.attach021Target
> 53:  *      -javaOpts="-XX:+UsePerfData -Xmx128M ${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI"

Please remove Xmx128M, it is not needed now.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart001.java line 68:

> 66:     private int runThis(String argv[], PrintStream out) {
> 67:         try {
> 68:             for (int i=0; i<ITERATIONS; i++)

The loop and try//catch are not needed anymore.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart002.java line 66:

> 64:         try {
> 65:             for (int i=0; i<ITERATIONS; i++)
> 66:                 ClassUnloader.eatMemory(); // provoke garbage collecting

The loop and try//catch are not needed anymore.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001.java line 75:

> 73:         // Provoke OutOfMemoryError in order to clear all soft references
> 74:         for (int i= 0; i < GC_TRYS; i++)
> 75:             ClassUnloader.eatMemory();

loop is not needed, I think

-------------

PR Review: https://git.openjdk.org/jdk/pull/28011#pullrequestreview-3391592901
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471667879
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471667402
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471668298
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471669523
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471670038
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471670896

From syan at openjdk.org  Wed Oct 29 06:12:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 29 Oct 2025 06:12:40 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v6]
In-Reply-To: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
Message-ID: <d7z-5cAPJbLREU353xrrlgOQsdBl2-ioFt1Hw5x4Vas=.a0b7261d-2fab-4592-95fa-334a90158b6c@github.com>

> Hi all,
> 
> We observed the test vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java intermittent fails. since the target application intermittent OOM. The target application will try to exhaust the heap memory and then trigger garbage collection by `ClassUnloader.eatMemory()` in file test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Target.java.
> 
> So I think it's better to limited the max heap usage of target application. Before this PR, the physical memory usage is about 30.7GB(this depends the total free memory on the test machine), and the jtreg main action take about 11 seconds to finish; After this PR, the physical memory usage is about 126MB, and the jtreg main action take about 0.7 senonds to finish. I use below command to get the usage of physical memory.
> 
> Change has been verified locally, test-fix only, no risk.
> 
> 
> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status

SendaoYan has updated the pull request incrementally with two additional commits since the last revision:

 - Revert change to test/hotspot/jtreg/vmTestbase/gc/gctests/SoftReference/soft003/soft003.java
 - Remove unnecessary -X128M

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28011/files
  - new: https://git.openjdk.org/jdk/pull/28011/files/f8e72ecf..499eb8ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=04-05

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28011/head:pull/28011

PR: https://git.openjdk.org/jdk/pull/28011

From syan at openjdk.org  Wed Oct 29 06:17:19 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 29 Oct 2025 06:17:19 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v7]
In-Reply-To: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
Message-ID: <rbmUKfMFxC1tlKHP5X3OjsHejE5obugkJQL25BzUKCA=.0299bce2-659b-484c-9f60-6703ab800c9b@github.com>

> Hi all,
> 
> We observed the test vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java intermittent fails. since the target application intermittent OOM. The target application will try to exhaust the heap memory and then trigger garbage collection by `ClassUnloader.eatMemory()` in file test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Target.java.
> 
> So I think it's better to limited the max heap usage of target application. Before this PR, the physical memory usage is about 30.7GB(this depends the total free memory on the test machine), and the jtreg main action take about 11 seconds to finish; After this PR, the physical memory usage is about 126MB, and the jtreg main action take about 0.7 senonds to finish. I use below command to get the usage of physical memory.
> 
> Change has been verified locally, test-fix only, no risk.
> 
> 
> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary try/catch and loop

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28011/files
  - new: https://git.openjdk.org/jdk/pull/28011/files/499eb8ca..baacc0a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=05-06

  Stats: 19 lines in 3 files changed: 0 ins; 15 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28011/head:pull/28011

PR: https://git.openjdk.org/jdk/pull/28011

From syan at openjdk.org  Wed Oct 29 06:42:08 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 29 Oct 2025 06:42:08 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v5]
In-Reply-To: <BiWf1-fjH_b7uqLrz4r2S5wq0BTkpIBYKvVBm0iL2Xk=.6a9d4efb-47eb-4faa-b31e-5176bfa0bbf9@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <fToeyPN0Xbgrr0JXXpNvGj7vScmpkQfI-NicyIvDPnc=.3d1bde89-2a95-487e-a029-a203a56ebd99@github.com>
 <BiWf1-fjH_b7uqLrz4r2S5wq0BTkpIBYKvVBm0iL2Xk=.6a9d4efb-47eb-4faa-b31e-5176bfa0bbf9@github.com>
Message-ID: <sagHGR6wr0LfDAWiWDuasWzA7nH-YlJjHW4EGW6SzDs=.78b27756-3223-4516-98a0-85745d7244a2@github.com>

On Wed, 29 Oct 2025 04:05:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update the test description
>
> test/hotspot/jtreg/vmTestbase/gc/gctests/SoftReference/soft003/soft003.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2007, 2025, Oracle and/or its affiliates. All rights reserved.
> 
> Only copyright changes in this file.

Sorry. Fixed.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java line 57:
> 
>> 55:  *      -jdk ${test.jdk}
>> 56:  *      -target nsk.jvmti.AttachOnDemand.attach020.attach020Target
>> 57:  *      -javaOpts="-XX:+UsePerfData -Xmx128M ${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI"
> 
> Please remove Xmx128M in all tests, it is not needed now.

Thanks, all the '-Xmx128M' has been removed.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/TestDescription.java line 53:
> 
>> 51:  *      -jdk ${test.jdk}
>> 52:  *      -target nsk.jvmti.AttachOnDemand.attach021.attach021Target
>> 53:  *      -javaOpts="-XX:+UsePerfData -Xmx128M ${test.vm.opts} ${test.java.opts} -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI"
> 
> Please remove Xmx128M, it is not needed now.

Thanks, all the '-Xmx128M' has been removed.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart001.java line 68:
> 
>> 66:     private int runThis(String argv[], PrintStream out) {
>> 67:         try {
>> 68:             for (int i=0; i<ITERATIONS; i++)
> 
> The loop and try//catch are not needed anymore.

Thanks. The loop and try/catch has been removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471882988
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471881837
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471882285
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471886100

From syan at openjdk.org  Wed Oct 29 06:42:12 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 29 Oct 2025 06:42:12 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v7]
In-Reply-To: <BiWf1-fjH_b7uqLrz4r2S5wq0BTkpIBYKvVBm0iL2Xk=.6a9d4efb-47eb-4faa-b31e-5176bfa0bbf9@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <fToeyPN0Xbgrr0JXXpNvGj7vScmpkQfI-NicyIvDPnc=.3d1bde89-2a95-487e-a029-a203a56ebd99@github.com>
 <BiWf1-fjH_b7uqLrz4r2S5wq0BTkpIBYKvVBm0iL2Xk=.6a9d4efb-47eb-4faa-b31e-5176bfa0bbf9@github.com>
Message-ID: <95erTe2mN-h8JuP4NonStvz8-sCdqP-VTYmpO8Rhv1k=.a34500fb-efd5-4684-83d8-64c02e3172dc@github.com>

On Wed, 29 Oct 2025 04:07:38 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary try/catch and loop
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GarbageCollectionStart/gcstart002.java line 66:
> 
>> 64:         try {
>> 65:             for (int i=0; i<ITERATIONS; i++)
>> 66:                 ClassUnloader.eatMemory(); // provoke garbage collecting
> 
> The loop and try//catch are not needed anymore.

Thanks, the try/catch has been removed.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/allocation/AP12/ap12t001.java line 75:
> 
>> 73:         // Provoke OutOfMemoryError in order to clear all soft references
>> 74:         for (int i= 0; i < GC_TRYS; i++)
>> 75:             ClassUnloader.eatMemory();
> 
> loop is not needed, I think

The loop and the loop count variable GC_TRYS has been removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471881952
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2471882069

From tschatzl at openjdk.org  Wed Oct 29 07:57:32 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 07:57:32 GMT
Subject: RFR: 8370807: G1: Fix comment about not selecting pinned regions into
 collection set
Message-ID: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>

Hi all,

  please review this cleanup of the region attribute registration methods.

Testing: gha

Thanks,
  Thomas

-------------

Commit messages:
 - 8370807

Changes: https://git.openjdk.org/jdk/pull/28038/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28038&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370807
  Stats: 32 lines in 6 files changed: 9 ins; 6 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/28038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28038/head:pull/28038

PR: https://git.openjdk.org/jdk/pull/28038

From tschatzl at openjdk.org  Wed Oct 29 08:25:18 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 08:25:18 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked() conform
 to coding style
Message-ID: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>

Hi all,

  please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.

Testing: gha

(Please note the dependency on #28038)

Thanks,
  Thomas

-------------

Depends on: https://git.openjdk.org/jdk/pull/28038

Commit messages:
 - 8370804

Changes: https://git.openjdk.org/jdk/pull/28039/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28039&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370804
  Stats: 26 lines in 6 files changed: 0 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/28039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28039/head:pull/28039

PR: https://git.openjdk.org/jdk/pull/28039

From fandreuzzi at openjdk.org  Wed Oct 29 08:59:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 29 Oct 2025 08:59:05 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style
In-Reply-To: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
Message-ID: <b8o2HMwdUybXi3IZhcKzeDVWjkoYz0XWlwSDVz58QK4=.a3e7dfc4-e9a9-4452-9bdd-bf149d2a00d6@github.com>

On Wed, 29 Oct 2025 08:18:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
> 
> Testing: gha
> 
> (Please note the dependency on #28038)
> 
> Thanks,
>   Thomas

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2556:

> 2554:     virtual bool do_heap_region(G1HeapRegion* r) {
> 2555:       G1CollectedHeap* g1h = G1CollectedHeap::heap();
> 2556:       bool const is_remset_tracked = g1h->region_attr(r->bottom()).is_remset_tracked();

`const bool` is a bit more common in the codebase

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28039#discussion_r2472191244

From sjohanss at openjdk.org  Wed Oct 29 09:37:56 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 29 Oct 2025 09:37:56 GMT
Subject: RFR: 8370807: G1: Fix comment about not selecting pinned regions
 into collection set
In-Reply-To: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
Message-ID: <5MByrpesDIs5r_GYWIECbildQ8_zlVDlUcRAd_gkN3g=.457602c4-0d03-4ce4-92f6-e1d4fd8c4e06@github.com>

On Wed, 29 Oct 2025 07:50:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this cleanup of the region attribute registration methods.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Change looks good, but the bug-title could be updated to reflect that this is not just a change to a comment.

-------------

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28038#pullrequestreview-3392401946

From iwalulya at openjdk.org  Wed Oct 29 09:37:57 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 29 Oct 2025 09:37:57 GMT
Subject: RFR: 8370807: G1: Fix comment about not selecting pinned regions
 into collection set
In-Reply-To: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
Message-ID: <sy3f7LbiSgwEz5yhXgrycXI2jnrJHuNYD6Om1EtUvWk=.08edebf9-58c4-4d32-85ce-e201793527b0@github.com>

On Wed, 29 Oct 2025 07:50:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this cleanup of the region attribute registration methods.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28038#pullrequestreview-3392411212

From iwalulya at openjdk.org  Wed Oct 29 09:41:16 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 29 Oct 2025 09:41:16 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style
In-Reply-To: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
Message-ID: <Mcqy4YOLIefy_7EFJE2hK9dosMopB0HbfnmDRLoccM4=.76e715cd-57ea-49db-94f1-54f55398a6de@github.com>

On Wed, 29 Oct 2025 08:18:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
> 
> Testing: gha
> 
> (Please note the dependency on #28038)
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28039#pullrequestreview-3392414946

From sjohanss at openjdk.org  Wed Oct 29 09:41:17 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 29 Oct 2025 09:41:17 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style
In-Reply-To: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
Message-ID: <xyKNgG7rz-_wDkgFwVKMhrZzZqTvfJkoWyp0GC9seC8=.8a52062e-dd64-4b6e-b036-ab6d4663a03c@github.com>

On Wed, 29 Oct 2025 08:18:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
> 
> Testing: gha
> 
> (Please note the dependency on #28038)
> 
> Thanks,
>   Thomas

Looks good, but please change to `const bool` as noted.

-------------

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28039#pullrequestreview-3392425577

From jpai at openjdk.org  Wed Oct 29 09:42:22 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 09:42:22 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
Message-ID: <qLpdKhKbOfwPeA1gneRLcXvylaEegFkQvElsKZsh-_k=.a1b88ff7-f4e9-4bcd-a0d4-52dccfa43b02@github.com>

On Tue, 28 Oct 2025 14:25:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
>     + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/Test...

Hello Pavel, these changes look OK to me.

Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392430217

From lkorinth at openjdk.org  Wed Oct 29 09:52:51 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 29 Oct 2025 09:52:51 GMT
Subject: RFR: 8369346: Remove default value of and deprecate the MaxRAM
 flag [v2]
In-Reply-To: <OvoPePoHT02JiHRAPK4J-hmXD6LlhOSxiZkkWED_fPc=.b0491706-ccc9-4ae0-9284-6b962f2cdcb3@github.com>
References: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
 <OvoPePoHT02JiHRAPK4J-hmXD6LlhOSxiZkkWED_fPc=.b0491706-ccc9-4ae0-9284-6b962f2cdcb3@github.com>
Message-ID: <AwUfZKQq0JymZksiKOL6DANGiLjVQih1uew-nw2zcqw=.c87221e2-9834-45b3-9e30-620abbc146b6@github.com>

On Thu, 23 Oct 2025 09:04:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Please see the CSR for a more detailed explanation and specific information regarding the deprecation of the flag. To summarize, the JVM is well-equiped to detect system memory and handle potential truncation errors (see [JDK-8367413 ](https://bugs.openjdk.org/browse/JDK-8367413)), making MaxRAM largely redundant. Removing the default value from MaxRAM mainly impacts systems with more memory than the default (128GB on 64-bit systems and 4GB on 32-bit systems) that are running with `-XX:-UseCompressedOops` or `-XX:+UseZGC`, which disable compressed oops. We recommend users to use well-supported flags such as `-Xms` and `-Xmx` to influence heap sizing instead.
>> 
>> MaxRAM is used to a very small extent to influence memory allocation in JDK tests, where MaxRAMPercentage is much more common. When MaxRAM is eventually obsoleted, the few affected tests will need to be updated or use alternative flags.
>> 
>> Testing:
>> * Oracle's tier1-8
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move MaxRAM to deprecated section in java.md

Looks good to me!

-------------

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27952#pullrequestreview-3392471051

From jsikstro at openjdk.org  Wed Oct 29 10:03:53 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 29 Oct 2025 10:03:53 GMT
Subject: RFR: 8369346: Remove default value of and deprecate the MaxRAM
 flag [v3]
In-Reply-To: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
References: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
Message-ID: <MCg1Jnk1ubpfSaZZz-D7dKY69FAUqCeNqgdD3SkueE4=.2b428ea8-1db3-41e4-bcc7-cf0252c808b0@github.com>

> Hello,
> 
> Please see the CSR for a more detailed explanation and specific information regarding the deprecation of the flag. To summarize, the JVM is well-equiped to detect system memory and handle potential truncation errors (see [JDK-8367413 ](https://bugs.openjdk.org/browse/JDK-8367413)), making MaxRAM largely redundant. Removing the default value from MaxRAM mainly impacts systems with more memory than the default (128GB on 64-bit systems and 4GB on 32-bit systems) that are running with `-XX:-UseCompressedOops` or `-XX:+UseZGC`, which disable compressed oops. We recommend users to use well-supported flags such as `-Xms` and `-Xmx` to influence heap sizing instead.
> 
> MaxRAM is used to a very small extent to influence memory allocation in JDK tests, where MaxRAMPercentage is much more common. When MaxRAM is eventually obsoleted, the few affected tests will need to be updated or use alternative flags.
> 
> Testing:
> * Oracle's tier1-8

Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8369346_remove_default_maxram
 - Move MaxRAM to deprecated section in java.md
 - 8369346: Remove default value of and deprecate the MaxRAM flag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27952/files
  - new: https://git.openjdk.org/jdk/pull/27952/files/03188828..905554ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27952&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27952&range=01-02

  Stats: 11449 lines in 335 files changed: 6388 ins; 3777 del; 1284 mod
  Patch: https://git.openjdk.org/jdk/pull/27952.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27952/head:pull/27952

PR: https://git.openjdk.org/jdk/pull/27952

From tschatzl at openjdk.org  Wed Oct 29 10:14:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 10:14:28 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style [v2]
In-Reply-To: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
Message-ID: <UCcfTpc8OqoNfIFps_Vd8yFZXZJ6Ee5UZAfTcbeTMNg=.40520775-0354-41f5-86cf-571e5f09082d@github.com>

> Hi all,
> 
>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
> 
> Testing: gha
> 
> (Please note the dependency on #28038)
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28039/files
  - new: https://git.openjdk.org/jdk/pull/28039/files/3367eb0a..865d37e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28039&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28039&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28039/head:pull/28039

PR: https://git.openjdk.org/jdk/pull/28039

From tschatzl at openjdk.org  Wed Oct 29 10:14:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 10:14:29 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style [v2]
In-Reply-To: <UCcfTpc8OqoNfIFps_Vd8yFZXZJ6Ee5UZAfTcbeTMNg=.40520775-0354-41f5-86cf-571e5f09082d@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
 <UCcfTpc8OqoNfIFps_Vd8yFZXZJ6Ee5UZAfTcbeTMNg=.40520775-0354-41f5-86cf-571e5f09082d@github.com>
Message-ID: <psBFErYsvLQ5aKW_TFepVgTeKAb8S0iVA-DKpqj8FYU=.524db1ed-58b0-4325-bf29-b95fc37dda62@github.com>

On Wed, 29 Oct 2025 10:11:00 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
>> 
>> Testing: gha
>> 
>> (Please note the dependency on #28038)
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Fine with me.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2556:

> 2554:     virtual bool do_heap_region(G1HeapRegion* r) {
> 2555:       G1CollectedHeap* g1h = G1CollectedHeap::heap();
> 2556:       bool const is_remset_tracked = g1h->region_attr(r->bottom()).is_remset_tracked();

Suggestion:

      const bool is_remset_tracked = g1h->region_attr(r->bottom()).is_remset_tracked();

-------------

PR Review: https://git.openjdk.org/jdk/pull/28039#pullrequestreview-3392539395
PR Review Comment: https://git.openjdk.org/jdk/pull/28039#discussion_r2472403934

From fandreuzzi at openjdk.org  Wed Oct 29 10:21:09 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 29 Oct 2025 10:21:09 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style [v2]
In-Reply-To: <UCcfTpc8OqoNfIFps_Vd8yFZXZJ6Ee5UZAfTcbeTMNg=.40520775-0354-41f5-86cf-571e5f09082d@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
 <UCcfTpc8OqoNfIFps_Vd8yFZXZJ6Ee5UZAfTcbeTMNg=.40520775-0354-41f5-86cf-571e5f09082d@github.com>
Message-ID: <24kPBKpAum4kng1JxTdoss4ScWrcc63MP0-29IdGa-I=.c3e867a2-6e43-40d9-b2a4-ad09c6898283@github.com>

On Wed, 29 Oct 2025 10:14:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
>> 
>> Testing: gha
>> 
>> (Please note the dependency on #28038)
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28039#pullrequestreview-3392574027

From prappo at openjdk.org  Wed Oct 29 10:25:59 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 10:25:59 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v4]
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <gg6TPlCojBnZ8qcFe6BtzrZ55ugS4EVLPBn-Yhjkv6A=.3904d4d5-bafe-4cc4-b566-2b3f8c2e01c4@github.com>

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

Pavel Rappo 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:

 - Fix one more occurrence
 - Merge remote-tracking branch 'jdk/master' into 8370568
 - Merge remote-tracking branch 'jdk/master' into 8370568
 - Update copyright years
   
   Note: any commit hashes below might be outdated due to subsequent
   history rewriting (e.g. git rebase).
   
    + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
    + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
    + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
    + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
    + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
    + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
    + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
    + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
    + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/InterruptThread/intrpthrd001/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002/newclass02/java.base/java/lang/Object.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t002/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP01/sp01t003/TestDescription.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/AllDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/gc/FinDiag.java due to a10f8b4304d
    + update test/hotspot/jtreg/vmTestbase/nsk/share/runner/MemDiag.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/JoinWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/SleepWithDuration.java due to a10f8b4304d
    + update test/jdk/java/lang/Thread/virtual/CustomScheduler.java due to a6a23d6fdaf
    + update test/jdk/java/nio/channels/Channels/SocketChannelStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/CloseDuringTransfer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/FileChannel/ClosedByInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Pipe/PipeInterrupt.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/LotsOfInterrupts.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/SelectWithConsumer.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/Selector/WakeupAfterClose.java due to a10f8b4304d
    + update test/jdk/java/nio/channels/SocketChannel/AdaptorStreams.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/CallWithInterruptSet.java due to a10f8b4304d
    + update test/jdk/java/nio/file/Files/InterruptCopy.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/LostInterrupt.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/CompletableFuture/SwallowedInterruptedException.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/CloseTest.java due to a10f8b4304d
    + update test/jdk/java/util/concurrent/ExecutorService/InvokeTest.java due to a10f8b4304d
    + update test/jdk/java/util/zip/InterruptibleZip.java due to a10f8b4304d
 - Reword for clarity as suggested
 - Drop to ease upcoming merge from loom repo
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27972/files
  - new: https://git.openjdk.org/jdk/pull/27972/files/b3297337..32e4c36a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27972&range=02-03

  Stats: 2165 lines in 89 files changed: 1112 ins; 785 del; 268 mod
  Patch: https://git.openjdk.org/jdk/pull/27972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27972/head:pull/27972

PR: https://git.openjdk.org/jdk/pull/27972

From prappo at openjdk.org  Wed Oct 29 10:26:00 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 10:26:00 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v3]
In-Reply-To: <qLpdKhKbOfwPeA1gneRLcXvylaEegFkQvElsKZsh-_k=.a1b88ff7-f4e9-4bcd-a0d4-52dccfa43b02@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <MbbNOs7vRtObRbkxlT7koaQIWn25GSWwKkjKGf8M1N8=.9b766314-b28a-47da-b04b-c249bab53e70@github.com>
 <qLpdKhKbOfwPeA1gneRLcXvylaEegFkQvElsKZsh-_k=.a1b88ff7-f4e9-4bcd-a0d4-52dccfa43b02@github.com>
Message-ID: <OsOSZtU1oXKFaS2JB5H0w4E8zTaQKAM6felDUtAFfzQ=.a8af697e-0420-40a4-862a-c9582f8dca85@github.com>

On Wed, 29 Oct 2025 09:39:55 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Pavel, these changes look OK to me.
> 
> Over time I think it will be harder to keep track or enforce this in code comments but I think it is easier to enforce for API specification text.

Moving from "interrupted" to "interrupt" was a slow drift rather than a landslide. I think it's okay to repair it once. _Loom_ is already in and once _structured concurrency_ is in, I don't expect many new occurrences of "interrupt" in the foreseeable future. But you are right, the important bit is the specification, not the code comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27972#issuecomment-3460767516

From jpai at openjdk.org  Wed Oct 29 10:29:34 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 29 Oct 2025 10:29:34 GMT
Subject: RFR: 8370568: Refer to Thread.interrupted as "interrupted status"
 consistently [v4]
In-Reply-To: <gg6TPlCojBnZ8qcFe6BtzrZ55ugS4EVLPBn-Yhjkv6A=.3904d4d5-bafe-4cc4-b566-2b3f8c2e01c4@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
 <gg6TPlCojBnZ8qcFe6BtzrZ55ugS4EVLPBn-Yhjkv6A=.3904d4d5-bafe-4cc4-b566-2b3f8c2e01c4@github.com>
Message-ID: <scuwz6xRGZcJJf4dzvgO3vy1WipJBC3I3S4tA-0EcuU=.c4b8faf2-5638-4d92-8e3f-2aff06338e1e@github.com>

On Wed, 29 Oct 2025 10:25:59 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
>> 
>> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.
>
> Pavel Rappo 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:
> 
>  - Fix one more occurrence
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Merge remote-tracking branch 'jdk/master' into 8370568
>  - Update copyright years
>    
>    Note: any commit hashes below might be outdated due to subsequent
>    history rewriting (e.g. git rebase).
>    
>     + update make/langtools/tools/javacserver/server/CompilerThreadPool.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/lang/Object.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/net/DatagramSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/net/ServerSocket.java due to a6a23d6fdaf
>     + update src/java.base/share/classes/java/nio/channels/DatagramChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/FileChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/InterruptibleChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ReadableByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ScatteringByteChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/Selector.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/ServerSocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/java/nio/channels/SocketChannel.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/nio/ch/Interruptible.java due to a10f8b4304d
>     + update src/java.base/share/classes/sun/security/ssl/StatusResponseManager.java due to a10f8b4304d
>     + update src/java.desktop/share/classes/java/awt/Robot.java due to a10f8b4304d
>     + update src/java.xml/share/classes/com/sun/org/apache/xerces/internal/parsers/DOMParserImpl.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpMultiChannel.java due to a10f8b4304d
>     + update src/jdk.sctp/share/classes/com/sun/nio/sctp/SctpServerChannel.java due to a10f8b4304d
>     + update test/hotspot/jtreg/serviceability/jvmti/vthread/GetThreadState/GetThreadStateTest.java due to a10f8b4304d
> ...

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27972#pullrequestreview-3392609024

From ayang at openjdk.org  Wed Oct 29 10:31:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 29 Oct 2025 10:31:36 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
Message-ID: <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>

On Wed, 29 Oct 2025 07:50:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this cleanup of the region attribute registration methods.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp line 207:

> 205: }
> 206: 
> 207: void G1CollectedHeap::register_old_collection_set_region_with_region_attr(G1HeapRegion* r) {

Why "collection_set" in the name? Is it a precondition that `r` is in cset?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28038#discussion_r2472462323

From ayang at openjdk.org  Wed Oct 29 10:44:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 29 Oct 2025 10:44:15 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style [v2]
In-Reply-To: <UCcfTpc8OqoNfIFps_Vd8yFZXZJ6Ee5UZAfTcbeTMNg=.40520775-0354-41f5-86cf-571e5f09082d@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
 <UCcfTpc8OqoNfIFps_Vd8yFZXZJ6Ee5UZAfTcbeTMNg=.40520775-0354-41f5-86cf-571e5f09082d@github.com>
Message-ID: <zFxOuuDaV9qEs9yAaxxQdFQ_vGUar2eIEgKwCkl46aI=.e564560e-58b9-444c-af62-4b0c12576ce1@github.com>

On Wed, 29 Oct 2025 10:14:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
>> 
>> Testing: gha
>> 
>> (Please note the dependency on #28038)
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28039#pullrequestreview-3392667686

From tschatzl at openjdk.org  Wed Oct 29 11:00:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 11:00:38 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>
Message-ID: <eQQw_HzcpL7kG8RifvARimaHq5NNqbQ2JoacmHtlS-4=.46355fb3-ddaf-4dcf-96e1-0e9bafedc0f2@github.com>

On Wed, 29 Oct 2025 10:29:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this cleanup of the region attribute registration methods.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp line 207:
> 
>> 205: }
>> 206: 
>> 207: void G1CollectedHeap::register_old_collection_set_region_with_region_attr(G1HeapRegion* r) {
> 
> Why "collection_set" in the name? Is it a precondition that `r` is in cset?

It must be a region that is currently being added to the collection set. I.e. registered to the attribute table to be in the collection set.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28038#discussion_r2472548602

From ayang at openjdk.org  Wed Oct 29 11:11:53 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 29 Oct 2025 11:11:53 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <eQQw_HzcpL7kG8RifvARimaHq5NNqbQ2JoacmHtlS-4=.46355fb3-ddaf-4dcf-96e1-0e9bafedc0f2@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>
 <eQQw_HzcpL7kG8RifvARimaHq5NNqbQ2JoacmHtlS-4=.46355fb3-ddaf-4dcf-96e1-0e9bafedc0f2@github.com>
Message-ID: <LH2cLNVqqyuPtdlz6Q43PLo4-UuilcfYANHwOCzTVUc=.b9c3e695-2a1f-4a8e-8ee0-613b8a2d74a6@github.com>

On Wed, 29 Oct 2025 10:56:44 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.inline.hpp line 207:
>> 
>>> 205: }
>>> 206: 
>>> 207: void G1CollectedHeap::register_old_collection_set_region_with_region_attr(G1HeapRegion* r) {
>> 
>> Why "collection_set" in the name? Is it a precondition that `r` is in cset?
>
> It must be a region that is currently being added to the collection set. I.e. registered to the attribute table to be in the collection set.

Then `in_cset` is a postcondition, not a precondition. The new name seems to suggest the arg (`r`) is old + in_cset, as a precondition.

Looking at the impl, one can't see anything related to "collection_set" in this context. I'd suggest restoring the original name, but YMMV.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28038#discussion_r2472587774

From tschatzl at openjdk.org  Wed Oct 29 11:31:00 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 11:31:00 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <LH2cLNVqqyuPtdlz6Q43PLo4-UuilcfYANHwOCzTVUc=.b9c3e695-2a1f-4a8e-8ee0-613b8a2d74a6@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>
 <eQQw_HzcpL7kG8RifvARimaHq5NNqbQ2JoacmHtlS-4=.46355fb3-ddaf-4dcf-96e1-0e9bafedc0f2@github.com>
 <LH2cLNVqqyuPtdlz6Q43PLo4-UuilcfYANHwOCzTVUc=.b9c3e695-2a1f-4a8e-8ee0-613b8a2d74a6@github.com>
Message-ID: <6uZomnymRe3KjOHB7WOAJ7mv0j7XW9jWhPJfnXO5eLk=.88d654f0-c1af-43ce-a54a-26fce1e64f31@github.com>

On Wed, 29 Oct 2025 11:09:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> It must be a region that is currently being added to the collection set. I.e. registered to the attribute table to be in the collection set.
>
> Then `in_cset` is a postcondition, not a precondition. The new name seems to suggest the arg (`r`) is old + in_cset, as a precondition.
> 
> Looking at the impl, one can't see anything related to "collection_set" in this context. I'd suggest restoring the original name, but YMMV.

The `set_in_old` call is the giveaway - in the region attribute table you only set a region to "Old" if it is 

  static const region_type_t Old          =   1;    // The region is in the collection set and an old region.

Old regions not in the collection set are just `NotInCset`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28038#discussion_r2472636224

From tschatzl at openjdk.org  Wed Oct 29 11:35:00 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 11:35:00 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <6uZomnymRe3KjOHB7WOAJ7mv0j7XW9jWhPJfnXO5eLk=.88d654f0-c1af-43ce-a54a-26fce1e64f31@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>
 <eQQw_HzcpL7kG8RifvARimaHq5NNqbQ2JoacmHtlS-4=.46355fb3-ddaf-4dcf-96e1-0e9bafedc0f2@github.com>
 <LH2cLNVqqyuPtdlz6Q43PLo4-UuilcfYANHwOCzTVUc=.b9c3e695-2a1f-4a8e-8ee0-613b8a2d74a6@github.com>
 <6uZomnymRe3KjOHB7WOAJ7mv0j7XW9jWhPJfnXO5eLk=.88d654f0-c1af-43ce-a54a-26fce1e64f31@github.com>
Message-ID: <HmT235Lv_nOCpZ52mw0pai3lsiqscwl8tiietJ5KuOE=.f1635975-30f6-4a85-99b8-5329572fc9b4@github.com>

On Wed, 29 Oct 2025 11:27:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Then `in_cset` is a postcondition, not a precondition. The new name seems to suggest the arg (`r`) is old + in_cset, as a precondition.
>> 
>> Looking at the impl, one can't see anything related to "collection_set" in this context. I'd suggest restoring the original name, but YMMV.
>
> The `set_in_old` call is the giveaway - in the region attribute table you only set a region to "Old" if it is 
> 
>   static const region_type_t Old          =   1;    // The region is in the collection set and an old region.
> 
> Old regions not in the collection set are just `NotInCset`.

The "Young" and "NewSurvivor" do not have the `collection_set` tagging because they are always in the collection set (i.e. it's obvious).

I thought it would be good to make it clear in the name that for old regions, we only add (old) regions that are part of the collection set.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28038#discussion_r2472647815

From tschatzl at openjdk.org  Wed Oct 29 11:42:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 11:42:57 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <HmT235Lv_nOCpZ52mw0pai3lsiqscwl8tiietJ5KuOE=.f1635975-30f6-4a85-99b8-5329572fc9b4@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>
 <eQQw_HzcpL7kG8RifvARimaHq5NNqbQ2JoacmHtlS-4=.46355fb3-ddaf-4dcf-96e1-0e9bafedc0f2@github.com>
 <LH2cLNVqqyuPtdlz6Q43PLo4-UuilcfYANHwOCzTVUc=.b9c3e695-2a1f-4a8e-8ee0-613b8a2d74a6@github.com>
 <6uZomnymRe3KjOHB7WOAJ7mv0j7XW9jWhPJfnXO5eLk=.88d654f0-c1af-43ce-a54a-26fce1e64f31@github.com>
 <HmT235Lv_nOCpZ52mw0pai3lsiqscwl8tiietJ5KuOE=.f1635975-30f6-4a85-99b8-5329572fc9b4@github.com>
Message-ID: <xYz6Hby_eH6oUfgX5pqU2EDx1PddKiD4mIeGhH5SPn0=.b6918463-fa8b-4aa3-8c56-d7868aa64d84@github.com>

On Wed, 29 Oct 2025 11:32:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> The `set_in_old` call is the giveaway - in the region attribute table you only set a region to "Old" if it is 
>> 
>>   static const region_type_t Old          =   1;    // The region is in the collection set and an old region.
>> 
>> Old regions not in the collection set are just `NotInCset`.
>
> The "Young" and "NewSurvivor" do not have the `collection_set` tagging because they are always in the collection set (i.e. it's obvious).
> 
> I thought it would be good to make it clear in the name that for old regions, we only add (old) regions that are part of the collection set.

The attribute table is an accelerator table - it only mirrors information from elsewhere used during GC. So the given region is already(*) in the collection set, but we can't check easily.

(*) Formally, from the code flow it isn't yet - the cardset group this region is contained in (which determines whether the related regions are in) will also be added during the `G1CollectionSet::add_group_to_collection_set()` call. This would just require some reordering of the calls, but logically it already is. If you really want I can do that in this change too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28038#discussion_r2472673906

From ayang at openjdk.org  Wed Oct 29 11:52:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 29 Oct 2025 11:52:22 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <xYz6Hby_eH6oUfgX5pqU2EDx1PddKiD4mIeGhH5SPn0=.b6918463-fa8b-4aa3-8c56-d7868aa64d84@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>
 <eQQw_HzcpL7kG8RifvARimaHq5NNqbQ2JoacmHtlS-4=.46355fb3-ddaf-4dcf-96e1-0e9bafedc0f2@github.com>
 <LH2cLNVqqyuPtdlz6Q43PLo4-UuilcfYANHwOCzTVUc=.b9c3e695-2a1f-4a8e-8ee0-613b8a2d74a6@github.com>
 <6uZomnymRe3KjOHB7WOAJ7mv0j7XW9jWhPJfnXO5eLk=.88d654f0-c1af-43ce-a54a-26fce1e64f31@github.com>
 <HmT235Lv_nOCpZ52mw0pai3lsiqscwl8tiietJ5KuOE=.f1635975-30f6-4a85-99b8-5329572fc9b4@github.com>
 <xYz6Hby_eH6oUfgX5pqU2EDx1PddKiD4mIeGhH5SPn0=.b6918463-fa8b-4aa3-8c56-d7868aa64d84@github.com>
Message-ID: <yQFOCiNQcSAtS8nzDXtxqe769Jb6HM-s-mXgD-rSwys=.56b72371-0132-4bc2-b9b1-192e232cceaa@github.com>

On Wed, 29 Oct 2025 11:40:26 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> So the given region is already(*) in the collection set

If that's indeed precondition, the new name makes sense.

There is `assert(!hr->in_collection_set(),` in the caller, which is conflicting with this semantic.

> If you really want I can do that in this change too.

I'd prefer doing that (new name + new precondition) in another PR, as the current title imply naming changes only, but up to you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28038#discussion_r2472697834

From tschatzl at openjdk.org  Wed Oct 29 12:41:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 12:41:53 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <yQFOCiNQcSAtS8nzDXtxqe769Jb6HM-s-mXgD-rSwys=.56b72371-0132-4bc2-b9b1-192e232cceaa@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>
 <eQQw_HzcpL7kG8RifvARimaHq5NNqbQ2JoacmHtlS-4=.46355fb3-ddaf-4dcf-96e1-0e9bafedc0f2@github.com>
 <LH2cLNVqqyuPtdlz6Q43PLo4-UuilcfYANHwOCzTVUc=.b9c3e695-2a1f-4a8e-8ee0-613b8a2d74a6@github.com>
 <6uZomnymRe3KjOHB7WOAJ7mv0j7XW9jWhPJfnXO5eLk=.88d654f0-c1af-43ce-a54a-26fce1e64f31@github.com>
 <HmT235Lv_nOCpZ52mw0pai3lsiqscwl8tiietJ5KuOE=.f1635975-30f6-4a85-99b8-5329572fc9b4@github.com>
 <xYz6Hby_eH6oUfgX5pqU2EDx1PddKiD4mIeGhH5SPn0=.b6918463-fa8b-4aa3-8c56-d7868aa64d84@github.com>
 <yQFOCiNQcSAtS8nzDXtxqe769Jb6HM-s-mXgD-rSwys=.56b72371-0132-4bc2-b9b1-192e232cceaa@github.com>
Message-ID: <wMnLRp8MiwdbDNpkm9SgLaqHcTC27hoGySuBGGwrRyM=.c321c23f-4866-49ce-be55-4cbf95cce75a@github.com>

On Wed, 29 Oct 2025 11:49:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> There is assert(!hr->in_collection_set(), in the caller, which is conflicting with this semantic.

The reason is that that assert only checks the accelerator table, which must not indicate that we already added it. There is no long form of that in-collections-set check any more, we removed it quite some time ago because we thought it was superfluous.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28038#discussion_r2472857013

From tschatzl at openjdk.org  Wed Oct 29 12:41:54 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 12:41:54 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <wMnLRp8MiwdbDNpkm9SgLaqHcTC27hoGySuBGGwrRyM=.c321c23f-4866-49ce-be55-4cbf95cce75a@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <KotNtVGc6_B16XJv9aLexZTQejxoAGPHgqll00vbB-4=.daea96f7-29fd-496b-93e4-5de22a0dfebe@github.com>
 <eQQw_HzcpL7kG8RifvARimaHq5NNqbQ2JoacmHtlS-4=.46355fb3-ddaf-4dcf-96e1-0e9bafedc0f2@github.com>
 <LH2cLNVqqyuPtdlz6Q43PLo4-UuilcfYANHwOCzTVUc=.b9c3e695-2a1f-4a8e-8ee0-613b8a2d74a6@github.com>
 <6uZomnymRe3KjOHB7WOAJ7mv0j7XW9jWhPJfnXO5eLk=.88d654f0-c1af-43ce-a54a-26fce1e64f31@github.com>
 <HmT235Lv_nOCpZ52mw0pai3lsiqscwl8tiietJ5KuOE=.f1635975-30f6-4a85-99b8-5329572fc9b4@github.com>
 <xYz6Hby_eH6oUfgX5pqU2EDx1PddKiD4mIeGhH5SPn0=.b6918463-fa8b-4aa3-8c56-d7868aa64d84@github.com>
 <yQFOCiNQcSAtS8nzDXtxqe769Jb6HM-s-mXgD-rSwys=.56b72371-0132-4bc2-b9b1-192e232cceaa@github.com>
 <wMnLRp8MiwdbDNpkm9SgLaqHcTC27hoGySuBGGwrRyM=.c321c23f-4866-49ce-be55-4cbf95cce75a@github.com>
Message-ID: <fN1WpheXmg7leofiuhkbKqQUcAAZLmbyISVQxI1QWfM=.3aefa8ae-42d0-4c63-a309-6f75d975839a@github.com>

On Wed, 29 Oct 2025 12:37:28 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>>> So the given region is already(*) in the collection set
>> 
>> If that's indeed precondition, the new name makes sense.
>> 
>> There is `assert(!hr->in_collection_set(),` in the caller, which is conflicting with this semantic.
>> 
>>> If you really want I can do that in this change too.
>> 
>> I'd prefer doing that (new name + new precondition) in another PR, as the current title imply naming changes only, but up to you.
>
>> There is assert(!hr->in_collection_set(), in the caller, which is conflicting with this semantic.
> 
> The reason is that that assert only checks the accelerator table, which must not indicate that we already added it. There is no long form of that in-collections-set check any more, we removed it quite some time ago because we thought it was superfluous.

So reordering the calls does not change the situation, i.e. there is no long-form check for the condition (i.e. the region is in the collection set already and we are just updating the attribute table).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28038#discussion_r2472861304

From jsikstro at openjdk.org  Wed Oct 29 12:50:30 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 29 Oct 2025 12:50:30 GMT
Subject: RFR: 8369346: Remove default value of and deprecate the MaxRAM
 flag [v3]
In-Reply-To: <K985PNrEcJx874X6w1CrUVixl65x42h8IoYJQwtiK0A=.bfa31ede-c00b-443a-8254-afc49637382e@github.com>
References: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
 <OvoPePoHT02JiHRAPK4J-hmXD6LlhOSxiZkkWED_fPc=.b0491706-ccc9-4ae0-9284-6b962f2cdcb3@github.com>
 <K985PNrEcJx874X6w1CrUVixl65x42h8IoYJQwtiK0A=.bfa31ede-c00b-443a-8254-afc49637382e@github.com>
Message-ID: <peklyMgjLGBUR_u69hx_zhMQAduXmIeO5aWBRpRQxdw=.50ea06fc-4b4e-4dae-999c-770a198a9e52@github.com>

On Thu, 23 Oct 2025 11:07:01 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8369346_remove_default_maxram
>>  - Move MaxRAM to deprecated section in java.md
>>  - 8369346: Remove default value of and deprecate the MaxRAM flag
>
> Marked as reviewed by ayang (Reviewer).

Thank you for the reviews! @albertnetymk @lkorinth

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27952#issuecomment-3461328431

From jsikstro at openjdk.org  Wed Oct 29 12:50:31 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 29 Oct 2025 12:50:31 GMT
Subject: Integrated: 8369346: Remove default value of and deprecate the MaxRAM
 flag
In-Reply-To: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
References: <fXMr2CnKV-b5KkCHaKtwYdI-Z2ouuHZf_BLSgXqLeQ0=.5c6b0345-1de4-437e-a60d-ad3f850fc4a8@github.com>
Message-ID: <q9STD7zOSgKN5d7qZVU_Mml7pKG2AKh9OfeV3L9wekU=.04c13c0b-5b06-452d-9214-dd4469ea5e1b@github.com>

On Thu, 23 Oct 2025 08:43:25 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> Please see the CSR for a more detailed explanation and specific information regarding the deprecation of the flag. To summarize, the JVM is well-equiped to detect system memory and handle potential truncation errors (see [JDK-8367413 ](https://bugs.openjdk.org/browse/JDK-8367413)), making MaxRAM largely redundant. Removing the default value from MaxRAM mainly impacts systems with more memory than the default (128GB on 64-bit systems and 4GB on 32-bit systems) that are running with `-XX:-UseCompressedOops` or `-XX:+UseZGC`, which disable compressed oops. We recommend users to use well-supported flags such as `-Xms` and `-Xmx` to influence heap sizing instead.
> 
> MaxRAM is used to a very small extent to influence memory allocation in JDK tests, where MaxRAMPercentage is much more common. When MaxRAM is eventually obsoleted, the few affected tests will need to be updated or use alternative flags.
> 
> Testing:
> * Oracle's tier1-8

This pull request has now been integrated.

Changeset: 6964cede
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6964cede0269327d2f13e446e307d531282cdaf9
Stats:     95 lines in 17 files changed: 21 ins; 63 del; 11 mod

8369346: Remove default value of and deprecate the MaxRAM flag

Reviewed-by: ayang, lkorinth

-------------

PR: https://git.openjdk.org/jdk/pull/27952

From tschatzl at openjdk.org  Wed Oct 29 13:15:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 13:15:53 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
 [v2]
In-Reply-To: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
Message-ID: <g0UMaNBq93iAMIbG6LmpxdhGrNa0lpDCXV0XLubfbDs=.1c97a219-0c98-4962-8739-670aa95eef78@github.com>

> Hi all,
> 
>   please review this cleanup of the region attribute registration methods.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * ayang review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28038/files
  - new: https://git.openjdk.org/jdk/pull/28038/files/162f3875..818c353c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28038&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28038&range=00-01

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28038/head:pull/28038

PR: https://git.openjdk.org/jdk/pull/28038

From tschatzl at openjdk.org  Wed Oct 29 13:54:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 13:54:28 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
 [v3]
In-Reply-To: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
Message-ID: <1hjP_Y6o1a4AMFrYSssMCdV_EsWmugT6iT_fvbwx-fw=.fd780f18-1b56-4400-9aac-69e756cfcec1@github.com>

> Hi all,
> 
>   please review this cleanup of the region attribute registration methods.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Thomas Schatzl 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 branch 'master' into 8370807-pinned-region-flag-not-propagated
 - * ayang review
 - 8370807
   
   Hi all,
   
     please review this cleanup of the region attribute registration methods.
   
   Testing: gha
   
   Thanks,
     Thomas

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28038/files
  - new: https://git.openjdk.org/jdk/pull/28038/files/818c353c..f2491bf7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28038&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28038&range=01-02

  Stats: 3041 lines in 118 files changed: 1855 ins; 868 del; 318 mod
  Patch: https://git.openjdk.org/jdk/pull/28038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28038/head:pull/28038

PR: https://git.openjdk.org/jdk/pull/28038

From tschatzl at openjdk.org  Wed Oct 29 14:00:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 14:00:07 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
 [v4]
In-Reply-To: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
Message-ID: <Ql1d7aOcuC-P4Nilhap2KGieKhQ690hocfayQRWMAJ0=.a6a99654-8bb0-434e-88cb-1049f3ee56f0@github.com>

> Hi all,
> 
>   please review this cleanup of the region attribute registration methods.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * ayang review2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28038/files
  - new: https://git.openjdk.org/jdk/pull/28038/files/f2491bf7..e946b780

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28038&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28038&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28038/head:pull/28038

PR: https://git.openjdk.org/jdk/pull/28038

From tschatzl at openjdk.org  Wed Oct 29 15:38:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 15:38:53 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
 [v5]
In-Reply-To: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
Message-ID: <J9WIIftube16YwkykWGy_phcJgqKz0KMdkLyvAaukyk=.373cf43b-5aec-4be9-99ee-e2e0f80d94a7@github.com>

> Hi all,
> 
>   please review this cleanup of the region attribute registration methods.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  * add more verification before changing the attribute table

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28038/files
  - new: https://git.openjdk.org/jdk/pull/28038/files/e946b780..e432694f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28038&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28038&range=03-04

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28038.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28038/head:pull/28038

PR: https://git.openjdk.org/jdk/pull/28038

From prappo at openjdk.org  Wed Oct 29 15:39:31 2025
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 29 Oct 2025 15:39:31 GMT
Subject: Integrated: 8370568: Refer to Thread.interrupted as
 "interrupted status" consistently
In-Reply-To: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
References: <wFRYGiQIQoK8ljiDNU-abxQ--wS-SEeSjm6K5w-4VG0=.a7e0dc2b-350f-4762-85b4-830b41178c13@github.com>
Message-ID: <uaeBmYjuxH0uTzmwhhHFy2gkyLBM1oT6f9PTUvlLIYs=.1da2ac77-fc8c-473a-8f67-dee5c28b327c@github.com>

On Fri, 24 Oct 2025 09:45:38 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Throughout documentation and source code, the `Thread.interrupted` flag is referred to as either "interrupt**ed** status" or "interrupt status". It might be good to be consistent.
> 
> Historically, it seems to have initially been "interrupted status". This is how the flag is called in `java.lang.Thread` and the "Java Concurrency in Practice" book. ("The Java Programming Language" calls it "interrupted **state**".) However, over the years "interrupt status" appeared in documentation and source code through networking and NIO classes.

This pull request has now been integrated.

Changeset: 28f2591b
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/28f2591bad49c4d1590325c3d315d850ab6bcc7d
Stats:     260 lines in 77 files changed: 4 ins; 0 del; 256 mod

8370568: Refer to Thread.interrupted as "interrupted status" consistently

Reviewed-by: jpai, rriggs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/27972

From tschatzl at openjdk.org  Wed Oct 29 15:58:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 29 Oct 2025 15:58:38 GMT
Subject: RFR: 8370889: G1: Inline
 G1PrepareEvacuationTask::sample_card_set_size()
Message-ID: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>

Hi all,

  please review this simple inlining of a one-liner method that is used once (discounting the check before that line that is actually repeated just a few lines below the call).

Also made the member name a bit more specific.

Testing: gha

Thanks,
  Thomas

-------------

Commit messages:
 - 8370889

Changes: https://git.openjdk.org/jdk/pull/28046/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28046&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370889
  Stats: 21 lines in 1 file changed: 6 ins; 10 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28046.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28046/head:pull/28046

PR: https://git.openjdk.org/jdk/pull/28046

From wkemper at openjdk.org  Wed Oct 29 17:20:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 29 Oct 2025 17:20:36 GMT
Subject: RFR: 8369013: Shenandoah: passive mode should support enabling
 ShenandoahCardBarrier [v2]
In-Reply-To: <kLIIvY_00AF-WOL9vM3fIg1i_itrnbJDyXHMbhuerGQ=.40637b69-7c5f-4701-8799-294ebe863a11@github.com>
References: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
 <kLIIvY_00AF-WOL9vM3fIg1i_itrnbJDyXHMbhuerGQ=.40637b69-7c5f-4701-8799-294ebe863a11@github.com>
Message-ID: <LUlC3yfZUxusT7ZwSln5lt1RWBkwqd8ck2hiux7Nxsw=.f6a2e3dc-5311-48d6-b0f2-74b3daa1e37c@github.com>

On Wed, 29 Oct 2025 01:13:53 GMT, Rui Li <duke at openjdk.org> wrote:

>> Add card barriers to passive mode to test out the price of card barriers. 
>> 
>> How this change is implemented is to instantiate the old region in passive mode - old region owns the card table so this would minimize the code change with a bit price of native memory. It does sound weird to have old gen in passive mode, but since passive mode is a just diagnostic mode, we'll go with it for the cleanliness of the change.
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move write table clean to degen

Looks good. Thank you!

-------------

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27966#pullrequestreview-3394917347

From duke at openjdk.org  Wed Oct 29 17:40:24 2025
From: duke at openjdk.org (Nityanand Rai)
Date: Wed, 29 Oct 2025 17:40:24 GMT
Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java
Message-ID: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>

Fix typos in debug log messages and comments in Concurrent.java

-------------

Commit messages:
 - Merge branch 'openjdk:master' into 8369323
 - Apply suggestions from code review
 - Merge branch 'openjdk:master' into 8369323
 - Merge branch 'openjdk:master' into 8369323
 - Fix typos in debug log messages and comments in Concurrent.java

Changes: https://git.openjdk.org/jdk/pull/27810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369323
  Stats: 8 lines in 1 file changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27810/head:pull/27810

PR: https://git.openjdk.org/jdk/pull/27810

From aturbanov at openjdk.org  Wed Oct 29 17:40:30 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Oct 2025 17:40:30 GMT
Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java
In-Reply-To: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
References: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
Message-ID: <g2HYONWCRXtZoNI3srAVtWL3eXD8cwFWi2TCSYfQs5g=.c9b61116-466c-40ab-b3a9-1a72bfdd66da@github.com>

On Tue, 14 Oct 2025 21:54:19 GMT, Nityanand Rai <duke at openjdk.org> wrote:

> Fix typos in debug log messages and comments in Concurrent.java

test/hotspot/jtreg/vmTestbase/vm/gc/concurrent/Concurrent.java line 82:

> 80:         }
> 81: 
> 82:         log.debug("The expected forest parameters: tree height = " + treeHeight  + " number of trees = " + ntrees

Suggestion:

        log.debug("The expected forest parameters: tree height = " + treeHeight + " number of trees = " + ntrees

test/hotspot/jtreg/vmTestbase/vm/gc/concurrent/Concurrent.java line 107:

> 105:                     instance.nodeGarbageSize = nodeGarbageSize;
> 106: 
> 107:                     log.debug("The forest real parameters: tree height = " + treeHeight  + " number of trees = " + instance.trees.length

Suggestion:

                    log.debug("The forest real parameters: tree height = " + treeHeight + " number of trees = " + instance.trees.length

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27810#discussion_r2431579251
PR Review Comment: https://git.openjdk.org/jdk/pull/27810#discussion_r2431579831

From syan at openjdk.org  Wed Oct 29 17:40:27 2025
From: syan at openjdk.org (SendaoYan)
Date: Wed, 29 Oct 2025 17:40:27 GMT
Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java
In-Reply-To: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
References: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
Message-ID: <U98Ge8EBMgqcWUFcVR4VVkiDYfVZuWfzE5uSju6b148=.4c8b7583-7270-48a7-ad08-473248d24ae0@github.com>

On Tue, 14 Oct 2025 21:54:19 GMT, Nityanand Rai <duke at openjdk.org> wrote:

> Fix typos in debug log messages and comments in Concurrent.java

Marked as reviewed by syan (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27810#pullrequestreview-3343173824

From phh at openjdk.org  Wed Oct 29 17:40:26 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 29 Oct 2025 17:40:26 GMT
Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java
In-Reply-To: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
References: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
Message-ID: <uK1REXcT7AQEaW1xsSsg5Akl32H5gamcYHb5z7eLfvM=.4141fc48-00ed-452d-975c-cbeb42fd76a5@github.com>

On Tue, 14 Oct 2025 21:54:19 GMT, Nityanand Rai <duke at openjdk.org> wrote:

> Fix typos in debug log messages and comments in Concurrent.java

Looks ok, but jcheck says there are tabs or trailing whitespace.

Seems jcheck checks for OCA and reviewers as well as white space. :) Lgtm.

-------------

Changes requested by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27810#pullrequestreview-3341446218
Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27810#pullrequestreview-3341983623

From wkemper at openjdk.org  Wed Oct 29 17:40:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 29 Oct 2025 17:40:25 GMT
Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java
In-Reply-To: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
References: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
Message-ID: <LtYR1Ejcz2FGUGMeMwVjSU2H5OR0o4KjG9BeQPzIMJg=.f2a6c616-4d4f-4a2f-b6d7-71d7d87ed4ce@github.com>

On Tue, 14 Oct 2025 21:54:19 GMT, Nityanand Rai <duke at openjdk.org> wrote:

> Fix typos in debug log messages and comments in Concurrent.java

LGTM

-------------

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27810#pullrequestreview-3337648779

From fandreuzzi at openjdk.org  Wed Oct 29 17:41:36 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 29 Oct 2025 17:41:36 GMT
Subject: RFR: 8370889: G1: Inline
 G1PrepareEvacuationTask::sample_card_set_size()
In-Reply-To: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>
References: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>
Message-ID: <_JJ7R5TGHQNW1kdaeDXGA1V3tt6gQAtNpHRBlZt2TqQ=.bea9dd5d-e186-4722-b186-ab2785f1da21@github.com>

On Wed, 29 Oct 2025 15:51:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this simple inlining of a one-liner method that is used once (discounting the check before that line that is actually repeated just a few lines below the call).
> 
> Also made the member name a bit more specific.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28046#pullrequestreview-3394984884

From ayang at openjdk.org  Wed Oct 29 19:38:48 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 29 Oct 2025 19:38:48 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
 [v5]
In-Reply-To: <J9WIIftube16YwkykWGy_phcJgqKz0KMdkLyvAaukyk=.373cf43b-5aec-4be9-99ee-e2e0f80d94a7@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <J9WIIftube16YwkykWGy_phcJgqKz0KMdkLyvAaukyk=.373cf43b-5aec-4be9-99ee-e2e0f80d94a7@github.com>
Message-ID: <hoXhq6vfZMNrCp0ue2a8Q0gbj7wSj1qzilIAVscO8VU=.0e69f6b2-f0f1-4a45-899b-a3cfd3112659@github.com>

On Wed, 29 Oct 2025 15:38:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this cleanup of the region attribute registration methods.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * add more verification before changing the attribute table

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28038#pullrequestreview-3395776756

From ayang at openjdk.org  Wed Oct 29 19:38:48 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 29 Oct 2025 19:38:48 GMT
Subject: RFR: 8370889: G1: Inline
 G1PrepareEvacuationTask::sample_card_set_size()
In-Reply-To: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>
References: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>
Message-ID: <T10ryAV0OpRJBCKwHN3Gfa3Vxu-6xHjwQoEcfJgYJn8=.7652a737-87a2-49ca-8082-d8a1f7ee7fac@github.com>

On Wed, 29 Oct 2025 15:51:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this simple inlining of a one-liner method that is used once (discounting the check before that line that is actually repeated just a few lines below the call).
> 
> Also made the member name a bit more specific.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28046#pullrequestreview-3395777169

From duke at openjdk.org  Wed Oct 29 21:29:06 2025
From: duke at openjdk.org (duke)
Date: Wed, 29 Oct 2025 21:29:06 GMT
Subject: RFR: 8369013: Shenandoah: passive mode should support enabling
 ShenandoahCardBarrier [v2]
In-Reply-To: <kLIIvY_00AF-WOL9vM3fIg1i_itrnbJDyXHMbhuerGQ=.40637b69-7c5f-4701-8799-294ebe863a11@github.com>
References: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
 <kLIIvY_00AF-WOL9vM3fIg1i_itrnbJDyXHMbhuerGQ=.40637b69-7c5f-4701-8799-294ebe863a11@github.com>
Message-ID: <9HSBPAmwzo65uPWM6chbjDeFzY4g7UwBOsu2PgHKnGQ=.e6f5bcb4-bd42-4a01-bc9c-e82c27a9840f@github.com>

On Wed, 29 Oct 2025 01:13:53 GMT, Rui Li <duke at openjdk.org> wrote:

>> Add card barriers to passive mode to test out the price of card barriers. 
>> 
>> How this change is implemented is to instantiate the old region in passive mode - old region owns the card table so this would minimize the code change with a bit price of native memory. It does sound weird to have old gen in passive mode, but since passive mode is a just diagnostic mode, we'll go with it for the cleanliness of the change.
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move write table clean to degen

@rgithubli 
Your change (at version e6fdbc604a2d71889c820ebe8bdb9540a6aa66aa) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27966#issuecomment-3464135922

From duke at openjdk.org  Wed Oct 29 21:43:19 2025
From: duke at openjdk.org (Rui Li)
Date: Wed, 29 Oct 2025 21:43:19 GMT
Subject: Integrated: 8369013: Shenandoah: passive mode should support enabling
 ShenandoahCardBarrier
In-Reply-To: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
References: <uYd11Y6x04MMn5ckELxcB5tJwrPWkD4BkTfPjdeTgkI=.b48b5153-1648-4ebd-9ef5-d1b7b6a555c8@github.com>
Message-ID: <HstWNLLmkqioT3wkTtP0pCbqpQsVdoXWnj8YOnsMB6k=.ace60daa-7cdf-4ed4-bbb2-656713a7f644@github.com>

On Fri, 24 Oct 2025 00:18:03 GMT, Rui Li <duke at openjdk.org> wrote:

> Add card barriers to passive mode to test out the price of card barriers. 
> 
> How this change is implemented is to instantiate the old region in passive mode - old region owns the card table so this would minimize the code change with a bit price of native memory. It does sound weird to have old gen in passive mode, but since passive mode is a just diagnostic mode, we'll go with it for the cleanliness of the change.

This pull request has now been integrated.

Changeset: f3dfdfa3
Author:    Rui Li <ruiamzn at amazon.com>
Committer: Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3dfdfa3fdc97c2c850251d58f91134e0ae82240
Stats:     118 lines in 9 files changed: 105 ins; 7 del; 6 mod

8369013: Shenandoah: passive mode should support enabling ShenandoahCardBarrier

Reviewed-by: wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/27966

From xpeng at openjdk.org  Wed Oct 29 23:29:37 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 29 Oct 2025 23:29:37 GMT
Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save
 unnecessary region iteration
Message-ID: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>

To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice:
1. fast path: traverse regions between left most and right most in the partition,  and try to allocate in an affiliated region in the partition;  
2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region.

#2 can be saved if we also remember the first FREE region seem in #1.

The PR makes the code much cleaner, and and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference) 


Test:
- [x] hotspot_gc_shenandoah

-------------

Commit messages:
 - Merge branch 'openjdk:master' into collector-allocation
 - Touch up
 - Remove test 'req.is_old()' when steal an empty region from the mutator view
 - Update comment
 - Fix wrong condition when steal an empty region from the mutator view
 - Fix potential failure in young evac
 - fix and touch up
 - Fix wrong condition to find first empty region
 - Simplify ShenandoahFreeSet::allocate_for_collector for better allocation performance

Changes: https://git.openjdk.org/jdk/pull/28036/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28036&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370850
  Stats: 72 lines in 2 files changed: 16 ins; 46 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28036.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28036/head:pull/28036

PR: https://git.openjdk.org/jdk/pull/28036

From lmesnik at openjdk.org  Thu Oct 30 02:59:07 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 Oct 2025 02:59:07 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v7]
In-Reply-To: <rbmUKfMFxC1tlKHP5X3OjsHejE5obugkJQL25BzUKCA=.0299bce2-659b-484c-9f60-6703ab800c9b@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <rbmUKfMFxC1tlKHP5X3OjsHejE5obugkJQL25BzUKCA=.0299bce2-659b-484c-9f60-6703ab800c9b@github.com>
Message-ID: <IXTOlOqiKjglRsesxLc2A_fhdhnuvoO_QEOWUgLS_BQ=.37519041-c098-4051-bea6-d20757420f67@github.com>

On Wed, 29 Oct 2025 06:17:19 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> We observed the test vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java intermittent fails. since the target application intermittent OOM. The target application will try to exhaust the heap memory and then trigger garbage collection by `ClassUnloader.eatMemory()` in file test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Target.java.
>> 
>> So I think it's better to limited the max heap usage of target application. Before this PR, the physical memory usage is about 30.7GB(this depends the total free memory on the test machine), and the jtreg main action take about 11 seconds to finish; After this PR, the physical memory usage is about 126MB, and the jtreg main action take about 0.7 senonds to finish. I use below command to get the usage of physical memory.
>> 
>> Change has been verified locally, test-fix only, no risk.
>> 
>> 
>> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary try/catch and loop

Sorry, I missed first time. See my comment about `import nsk.share.ClassUnloader;` inline.

test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Target.java line 51:

> 49: 
> 50:             log.display("Provoking GC");
> 51:             WhiteBox.getWhiteBox().fullGC();

Please also remove lines
`import nsk.share.ClassUnloader;`
ssince this class is not using anymore.

-------------

Changes requested by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28011#pullrequestreview-3397245800
PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2476258933

From lmesnik at openjdk.org  Thu Oct 30 03:16:02 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 Oct 2025 03:16:02 GMT
Subject: RFR: 8369323: Fix typos in vmTestbase/.../Concurrent.java
In-Reply-To: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
References: <OAKJZlic7I8mpmBsU0hrAqtYWwjRu3DcjSLjxzxbSO4=.8a42e9c7-7b5d-4590-9d86-a3a599ab7505@github.com>
Message-ID: <eo-t8kEjYSfKoehZKYqw72jx-x_ZGYuW79wME1XaaBM=.540ebe9f-85fb-4191-9348-26ec411e0786@github.com>

On Tue, 14 Oct 2025 21:54:19 GMT, Nityanand Rai <duke at openjdk.org> wrote:

> Fix typos in debug log messages and comments in Concurrent.java

The fix looks good, please update copyright years.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27810#pullrequestreview-3397277281

From syan at openjdk.org  Thu Oct 30 03:57:21 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 30 Oct 2025 03:57:21 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v8]
In-Reply-To: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
Message-ID: <WF2WQMquEWVQzEmvLFDFTLEri9quM4TCvyGpU1MWyLU=.ca1b9440-9527-49ce-bf00-9c79b81e9cad@github.com>

> Hi all,
> 
> We observed the test vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java intermittent fails. since the target application intermittent OOM. The target application will try to exhaust the heap memory and then trigger garbage collection by `ClassUnloader.eatMemory()` in file test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Target.java.
> 
> So I think it's better to limited the max heap usage of target application. Before this PR, the physical memory usage is about 30.7GB(this depends the total free memory on the test machine), and the jtreg main action take about 11 seconds to finish; After this PR, the physical memory usage is about 126MB, and the jtreg main action take about 0.7 senonds to finish. I use below command to get the usage of physical memory.
> 
> Change has been verified locally, test-fix only, no risk.
> 
> 
> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary "import nsk.share.ClassUnloader;"

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28011/files
  - new: https://git.openjdk.org/jdk/pull/28011/files/baacc0a0..4f7c2adb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=06-07

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28011/head:pull/28011

PR: https://git.openjdk.org/jdk/pull/28011

From syan at openjdk.org  Thu Oct 30 03:57:24 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 30 Oct 2025 03:57:24 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v7]
In-Reply-To: <IXTOlOqiKjglRsesxLc2A_fhdhnuvoO_QEOWUgLS_BQ=.37519041-c098-4051-bea6-d20757420f67@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <rbmUKfMFxC1tlKHP5X3OjsHejE5obugkJQL25BzUKCA=.0299bce2-659b-484c-9f60-6703ab800c9b@github.com>
 <IXTOlOqiKjglRsesxLc2A_fhdhnuvoO_QEOWUgLS_BQ=.37519041-c098-4051-bea6-d20757420f67@github.com>
Message-ID: <jGYc0V_2cNaC_qnxd9gXMCRFJ5vUgG2xmCzGyngx-Xc=.716281ce-8e29-4d5a-ba38-c815c0f7f98e@github.com>

On Thu, 30 Oct 2025 02:53:24 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary try/catch and loop
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Target.java line 51:
> 
>> 49: 
>> 50:             log.display("Provoking GC");
>> 51:             WhiteBox.getWhiteBox().fullGC();
> 
> Please also remove lines
> `import nsk.share.ClassUnloader;`
> ssince this class is not using anymore.

Thanks for the patient reviews. The unnecessary 'import nsk.share.ClassUnloader;' has been removed from 3 files
test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Target.java
test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Target.java
test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach022/attach022Target.java

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2476333212

From lmesnik at openjdk.org  Thu Oct 30 04:44:15 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 Oct 2025 04:44:15 GMT
Subject: RFR: 8370732:
 vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java
 intermittent fails [v8]
In-Reply-To: <WF2WQMquEWVQzEmvLFDFTLEri9quM4TCvyGpU1MWyLU=.ca1b9440-9527-49ce-bf00-9c79b81e9cad@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <WF2WQMquEWVQzEmvLFDFTLEri9quM4TCvyGpU1MWyLU=.ca1b9440-9527-49ce-bf00-9c79b81e9cad@github.com>
Message-ID: <3cIAJCGPYlvgjqrARfRyCSaXbrozQXDSG1KfTNbW5P4=.ed0b1ecb-d3e6-49b1-95f9-197a3d7a2146@github.com>

On Thu, 30 Oct 2025 03:57:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> We observed the test vmTestbase/nsk/jvmti/AttachOnDemand/attach020/TestDescription.java intermittent fails. since the target application intermittent OOM. The target application will try to exhaust the heap memory and then trigger garbage collection by `ClassUnloader.eatMemory()` in file test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach020/attach020Target.java.
>> 
>> So I think it's better to limited the max heap usage of target application. Before this PR, the physical memory usage is about 30.7GB(this depends the total free memory on the test machine), and the jtreg main action take about 11 seconds to finish; After this PR, the physical memory usage is about 126MB, and the jtreg main action take about 0.7 senonds to finish. I use below command to get the usage of physical memory.
>> 
>> Change has been verified locally, test-fix only, no risk.
>> 
>> 
>> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary "import nsk.share.ClassUnloader;"

The fix looks good. Can you please also change summary of the issue and PR to corresponds the new fix.

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28011#pullrequestreview-3397419627

From syan at openjdk.org  Thu Oct 30 06:10:09 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 30 Oct 2025 06:10:09 GMT
Subject: RFR: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc
 for nsk/jvmti tests [v8]
In-Reply-To: <3cIAJCGPYlvgjqrARfRyCSaXbrozQXDSG1KfTNbW5P4=.ed0b1ecb-d3e6-49b1-95f9-197a3d7a2146@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <WF2WQMquEWVQzEmvLFDFTLEri9quM4TCvyGpU1MWyLU=.ca1b9440-9527-49ce-bf00-9c79b81e9cad@github.com>
 <3cIAJCGPYlvgjqrARfRyCSaXbrozQXDSG1KfTNbW5P4=.ed0b1ecb-d3e6-49b1-95f9-197a3d7a2146@github.com>
Message-ID: <vbs5DIeyCbizaJ6Z3GV_AS5dXuvADLKbZIE5BB7E8QQ=.4e8767ee-8ff1-4d8d-83b1-87163d433311@github.com>

On Thu, 30 Oct 2025 04:41:43 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The fix looks good. Can you please also change summary of the issue and PR to corresponds the new fix.

The issue and PR summary has been updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28011#issuecomment-3466254686

From iwalulya at openjdk.org  Thu Oct 30 06:12:06 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 30 Oct 2025 06:12:06 GMT
Subject: RFR: 8370889: G1: Inline
 G1PrepareEvacuationTask::sample_card_set_size()
In-Reply-To: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>
References: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>
Message-ID: <W90AlXGnlyYcESzqaTbhz_3jpTvn6T915LBooef4eEQ=.d267b613-b267-4f73-a7e5-bfc0199d5469@github.com>

On Wed, 29 Oct 2025 15:51:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this simple inlining of a one-liner method that is used once (discounting the check before that line that is actually repeated just a few lines below the call).
> 
> Also made the member name a bit more specific.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28046#pullrequestreview-3397571828

From tschatzl at openjdk.org  Thu Oct 30 07:38:21 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Oct 2025 07:38:21 GMT
Subject: RFR: 8370807: G1: Improve region attribute table method naming
 [v5]
In-Reply-To: <5MByrpesDIs5r_GYWIECbildQ8_zlVDlUcRAd_gkN3g=.457602c4-0d03-4ce4-92f6-e1d4fd8c4e06@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
 <5MByrpesDIs5r_GYWIECbildQ8_zlVDlUcRAd_gkN3g=.457602c4-0d03-4ce4-92f6-e1d4fd8c4e06@github.com>
Message-ID: <PJR14ElJA429F3wcIrz5ygNwKMgzEbTVjncM1IP5BKE=.c8c3e216-9c72-4ffb-be87-85d1bcdd08e2@github.com>

On Wed, 29 Oct 2025 09:33:25 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * add more verification before changing the attribute table
>
> Change looks good, but the bug-title could be updated to reflect that this is not just a change to a comment.

Thanks @kstefanj  @walulyai @albertnetymk for your reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28038#issuecomment-3466463029

From tschatzl at openjdk.org  Thu Oct 30 07:38:22 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Oct 2025 07:38:22 GMT
Subject: Integrated: 8370807: G1: Improve region attribute table method naming
In-Reply-To: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
References: <PvdE5M8qOhFG8GGJdEGIXQWlwDGgmjSFlk8w0dfrTxU=.390dfbc5-6084-4040-9844-7edc29703237@github.com>
Message-ID: <PiXhMb-0GmEUBvtz0vjzX4RKeB2yCVXestvUqL8egl0=.d1b77e15-1080-4117-bdc8-93d508ba75e3@github.com>

On Wed, 29 Oct 2025 07:50:53 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this cleanup of the region attribute registration methods.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 17fd801b
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17fd801b24162dfbac6d4e63ef5048a0fb146074
Stats:     36 lines in 6 files changed: 12 ins; 7 del; 17 mod

8370807: G1: Improve region attribute table method naming

Reviewed-by: ayang, sjohanss, iwalulya

-------------

PR: https://git.openjdk.org/jdk/pull/28038

From tschatzl at openjdk.org  Thu Oct 30 08:15:14 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Oct 2025 08:15:14 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style [v3]
In-Reply-To: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
Message-ID: <5nLXNbN9rdoo6W4UgzCgla9mibzHT-uqzXYKO6jqJkk=.63335a4f-f1f3-4177-b97f-14123849bd98@github.com>

> Hi all,
> 
>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
> 
> Testing: gha
> 
> (Please note the dependency on #28038)
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into 8370804-remset-is-tracked-style2
 - Merge branch '8370807-pinned-region-flag-not-propagated' into 8370804-remset-is-tracked-style2
 - Merge branch 'master' into 8370807-pinned-region-flag-not-propagated
 - * ayang review
 - Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
 - 8370804
   
   Hi all,
   
     please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
   
   Testing: gha
   
   Thanks,
     Thomas
 - 8370807
   
   Hi all,
   
     please review this cleanup of the region attribute registration methods.
   
   Testing: gha
   
   Thanks,
     Thomas

-------------

Changes: https://git.openjdk.org/jdk/pull/28039/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28039&range=02
  Stats: 26 lines in 6 files changed: 0 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/28039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28039/head:pull/28039

PR: https://git.openjdk.org/jdk/pull/28039

From iwalulya at openjdk.org  Thu Oct 30 08:48:28 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 30 Oct 2025 08:48:28 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style [v3]
In-Reply-To: <5nLXNbN9rdoo6W4UgzCgla9mibzHT-uqzXYKO6jqJkk=.63335a4f-f1f3-4177-b97f-14123849bd98@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
 <5nLXNbN9rdoo6W4UgzCgla9mibzHT-uqzXYKO6jqJkk=.63335a4f-f1f3-4177-b97f-14123849bd98@github.com>
Message-ID: <rCR3lVDYAuJKoeBMs8NWS0xf15QrDqpqtd6zFuNZgXI=.229d4447-2990-49dc-becc-0e457b23af97@github.com>

On Thu, 30 Oct 2025 08:15:14 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
>> 
>> Testing: gha
>> 
>> (Please note the dependency on #28038)
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into 8370804-remset-is-tracked-style2
>  - Merge branch '8370807-pinned-region-flag-not-propagated' into 8370804-remset-is-tracked-style2
>  - Merge branch 'master' into 8370807-pinned-region-flag-not-propagated
>  - * ayang review
>  - Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>  - 8370804
>    
>    Hi all,
>    
>      please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
>    
>    Testing: gha
>    
>    Thanks,
>      Thomas
>  - 8370807
>    
>    Hi all,
>    
>      please review this cleanup of the region attribute registration methods.
>    
>    Testing: gha
>    
>    Thanks,
>      Thomas

Still good!

-------------

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28039#pullrequestreview-3398069512

From tschatzl at openjdk.org  Thu Oct 30 09:21:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Oct 2025 09:21:39 GMT
Subject: RFR: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style [v3]
In-Reply-To: <rCR3lVDYAuJKoeBMs8NWS0xf15QrDqpqtd6zFuNZgXI=.229d4447-2990-49dc-becc-0e457b23af97@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
 <5nLXNbN9rdoo6W4UgzCgla9mibzHT-uqzXYKO6jqJkk=.63335a4f-f1f3-4177-b97f-14123849bd98@github.com>
 <rCR3lVDYAuJKoeBMs8NWS0xf15QrDqpqtd6zFuNZgXI=.229d4447-2990-49dc-becc-0e457b23af97@github.com>
Message-ID: <MqZu6cVGJNE1ql42kFvGLcdiyXau7NnSQ9T8z8bzbEw=.cc10856b-946f-45e8-b1ee-927919fc33d7@github.com>

On Thu, 30 Oct 2025 08:45:55 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
>> 
>>  - Merge branch 'master' into 8370804-remset-is-tracked-style2
>>  - Merge branch '8370807-pinned-region-flag-not-propagated' into 8370804-remset-is-tracked-style2
>>  - Merge branch 'master' into 8370807-pinned-region-flag-not-propagated
>>  - * ayang review
>>  - Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>>  - 8370804
>>    
>>    Hi all,
>>    
>>      please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
>>    
>>    Testing: gha
>>    
>>    Thanks,
>>      Thomas
>>  - 8370807
>>    
>>    Hi all,
>>    
>>      please review this cleanup of the region attribute registration methods.
>>    
>>    Testing: gha
>>    
>>    Thanks,
>>      Thomas
>
> Still good!

Thanks @walulyai @albertnetymk @kstefanj @fandreuz for your reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28039#issuecomment-3466849845

From tschatzl at openjdk.org  Thu Oct 30 09:25:08 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Oct 2025 09:25:08 GMT
Subject: Integrated: 8370804: G1: Make G1HeapRegionAttr::remset_is_tracked()
 conform to coding style
In-Reply-To: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
References: <wYcdaHwKfKlMZvxIQL_MSnXtHoR2OlG96h5KEljvO24=.982fa0b2-1065-4488-862a-730da49db0f4@github.com>
Message-ID: <95VfgCsWCuTW7SEqAbzwUdlbfgeHTdA32L5utLEQjQU=.3896d2f2-9e9c-430d-b830-6dd24b347b38@github.com>

On Wed, 29 Oct 2025 08:18:50 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please fix several places where the `remset_is_tracked` getter and related identifiers do not fit hotspot style, recommending the verb as first part.
> 
> Testing: gha
> 
> (Please note the dependency on #28038)
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 87e5341d
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87e5341d78d206fa9e987340861cd5f1c0858891
Stats:     26 lines in 6 files changed: 0 ins; 0 del; 26 mod

8370804: G1: Make G1HeapRegionAttr::remset_is_tracked() conform to coding style

Reviewed-by: iwalulya, sjohanss, fandreuzzi, ayang

-------------

PR: https://git.openjdk.org/jdk/pull/28039

From azafari at openjdk.org  Thu Oct 30 11:28:18 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Oct 2025 11:28:18 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v9]
In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
Message-ID: <4PACO9yakbWS0M3ciVmyJN7_FkUbm_r3kQwImqKtPzY=.c67a5a99-eff5-439c-a805-ae96226b6b7c@github.com>

> 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:

  removed redundant check of overflow.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26955/files
  - new: https://git.openjdk.org/jdk/pull/26955/files/d0300291..b21cb6ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=07-08

  Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955

PR: https://git.openjdk.org/jdk/pull/26955

From azafari at openjdk.org  Thu Oct 30 11:28:20 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Oct 2025 11:28:20 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v8]
In-Reply-To: <V_q4Y0qgXwXx4qsV7TI5yWRr-ylb9-lA9o6PxIHwSvI=.7ca20f28-39da-45dd-b191-cda9320b1b80@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <cqcQvTn_HuW6vnkLDhzL7NOzJD9n6VrnFf2ylbIrhlo=.4646b21f-0195-4884-8c7f-c1dd4d6b2526@github.com>
 <KIaL4YwJahqRS1AAnHomAh8V9ljnsNwpjFnyPS4qh-4=.39ed0a8d-69ea-436b-9281-acf8a338113f@github.com>
 <zE8nqxuIWvZ6ZelZtl0uBNeB1YV_h27xpWePneIWBy4=.19533555-4ba8-475c-9d23-3261f5f1222d@github.com>
 <V_q4Y0qgXwXx4qsV7TI5yWRr-ylb9-lA9o6PxIHwSvI=.7ca20f28-39da-45dd-b191-cda9320b1b80@github.com>
Message-ID: <umx8XMG1K30Gp16PlJt_vyoYNPKph4dfE6Q-Qja1BI4=.77046702-2836-4196-bdaf-60437c20b2dd@github.com>

On Tue, 28 Oct 2025 10:31:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> No difference other than not depends on the other conditions. The existing condition needs two more conjunctions to be true.
>> Without this change here, when we run jvm with the options as shown in this [comment](https://github.com/openjdk/jdk/pull/26955#issuecomment-3241790796 
>> ) (to make the HeapMinBaseAddress overflow) it crashes with an assertion.
>
> If they are the same then we no longer need the conditional one surely. ??

Yes, removed the redundant check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2477668213

From azafari at openjdk.org  Thu Oct 30 11:44:35 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Oct 2025 11:44:35 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <ULP4C2zdfAlLsafjiTtVynzIGrlsWCaZPl5ZHfmmyPE=.02b40dc3-8b20-4ad6-a6df-30a4d37860c9@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
 <ULP4C2zdfAlLsafjiTtVynzIGrlsWCaZPl5ZHfmmyPE=.02b40dc3-8b20-4ad6-a6df-30a4d37860c9@github.com>
Message-ID: <xmF9lzcLgkvDJG6yyKZxibd25eoYpJ4nGYYyUgWKj9g=.b638be7a-a026-496b-9058-8f4385e84315@github.com>

On Mon, 20 Oct 2025 07:34:39 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed MAX2 template parameter
>
> It seems that this PR is diverging in some (un)related changes. I suggest to define separate new RFEs per issues found here.

> Sorry @afshin-zafari but this PR has me quite confused. The code changes do not reflect the PR description. The PR description does not obviously connect to the JBS problem statement. And the code changes in the PR seem unrelated to the value of aligned_heap_base_min_address as referenced in JBS.
> 
> And the cast changes in memoryReserver.cpp seem completely unrelated.
> 
> That said, I do not know how all of these heap variables interact and relate, so you really need the GC folk to understand and approve this.

PR description is updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3467587577

From azafari at openjdk.org  Thu Oct 30 11:44:38 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Oct 2025 11:44:38 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v3]
In-Reply-To: <Dzo47Sl2gr2TX3Vi5i7i5qidhU5ECNRUXeEOaglHzoc=.89d9c9fc-4c33-470d-9296-dbf773c7518a@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <-eWIUjA4RqIgcpvFSyFxuiuganZpBqkMIdKSOVhnuMo=.79db2c26-5547-42fa-84d9-9bf5746728cf@github.com>
 <BS_Ds4kE4Orp2-841Byw0yEoVQ5OOZea_D-wXOsUS-A=.c1be85ba-b2ba-49a2-858a-e8f2e6102528@github.com>
 <Dzo47Sl2gr2TX3Vi5i7i5qidhU5ECNRUXeEOaglHzoc=.89d9c9fc-4c33-470d-9296-dbf773c7518a@github.com>
Message-ID: <1yH5ZS85JZtyQu9a_Pt9PHufQ9Vo8eNNw9jGGxnBn8Y=.03b5f93c-4cd5-419a-9d3c-e072eb69359f@github.com>

On Mon, 15 Sep 2025 08:42:36 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288:
>> 
>>> 286:   // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value.
>>> 287:   // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx.
>>> 288:   if (value + MaxHeapSize < MaxHeapSize) {// overflow
>> 
>> Can we perform the overflow check via subtraction from the max value instead? I know that unsigned types do wrap around, but at a first glance this will look wrong and make the reader stop and think.
>> 
>> Style: Space between { and //
>> 
>> 
>> if (std::numeric_limits<size_t>::max() - value < MaxHeapSize) { // overflow
>
> Using ` a < a - b` for checking overflow, does not work when `a - b` is negative and it will become a very large number when cast to unsigned.
> 
> Space added.

misunderstood. Done.

>> src/hotspot/share/memory/memoryReserver.cpp line 560:
>> 
>>> 558:   if (!FLAG_IS_DEFAULT(HeapBaseMinAddress)) {
>>> 559:     reserved = try_reserve_memory(size + noaccess_prefix, alignment, page_size, (char *)aligned_heap_base_min_address);
>>> 560:     if (reserved.base() != (char *)aligned_heap_base_min_address) { // Enforce this exact address.
>> 
>> Style: Please hug the * to the char for the casts
>
> Done.
> There are some preexisting cases like this. Should I change them too?

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2477746409
PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2477747887

From azafari at openjdk.org  Thu Oct 30 11:44:41 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Oct 2025 11:44:41 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v9]
In-Reply-To: <v4RQWWMp-Ry8HiVcTr1hNwXtm6EvnAVNuGDtvnljlDA=.3e04c473-2447-44a6-8d3a-6b477aa7e9b6@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <v4RQWWMp-Ry8HiVcTr1hNwXtm6EvnAVNuGDtvnljlDA=.3e04c473-2447-44a6-8d3a-6b477aa7e9b6@github.com>
Message-ID: <WCTTn89BmTzLRa5qJydl5LsLHsby-HmjeW6C_zH2M0M=.385a395e-6ef4-4857-a83c-7c9b5cacb9d0@github.com>

On Wed, 27 Aug 2025 16:50:57 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

>> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed redundant check of overflow.
>
> src/hotspot/share/memory/memoryReserver.cpp line 552:
> 
>> 550: 
>> 551:   char* aligned_heap_base_min_address = align_up((char*)HeapBaseMinAddress, alignment);
>> 552:   assert(aligned_heap_base_min_address != 0,"Should not be 0");
> 
> Suggestion:
> 
>   assert(aligned_heap_base_min_address != 0, "Should not be 0");

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2477744601

From ayang at openjdk.org  Thu Oct 30 11:50:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 30 Oct 2025 11:50:12 GMT
Subject: RFR: 8370943: Support heap expansion during startup in Serial and
 Parallel
Message-ID: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>

Add heap expansion logic in allocation slow-path during startup. Some asserts are relaxed to be used by java-threads and outside of safepoint.

Test: tier1-5

-------------

Commit messages:
 - pgc-expand-at-init

Changes: https://git.openjdk.org/jdk/pull/28059/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28059&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370943
  Stats: 26 lines in 4 files changed: 20 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28059.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28059/head:pull/28059

PR: https://git.openjdk.org/jdk/pull/28059

From azafari at openjdk.org  Thu Oct 30 11:51:02 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Oct 2025 11:51:02 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v10]
In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
Message-ID: <MVmRhtoye2zLOR6X-HblyU0MLOPISQ3C9f_OgqUaY6s=.3eb9d3c1-3111-4f30-aa4b-27d18962b430@github.com>

> The issue happens when the HeapMinBaseAddress option gets 0 as input value. Since this option is used as an address, then using 0 in pointer arithmetics is UB.
> The fix is using `unitptr_t` instead of `address`/`char*`, etc.  In doing that, it is found that an overflow check does not work in all cases due to checking more conditions. That overflow check is changed too. We also need to check overflow after aligning addresses and sizes of memory regions in this context. Assertions are added to check these cases.
> 
> Tests:
> linux-x64 tier1

Afshin Zafari 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 10 additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into _8351334_ubsan_nullptr_add
 - removed redundant check of overflow.
 - subtraction for checking overflow
 - fixed MAX2 template parameter
 - fixes.
 - uintptr_t -> uint64_t
 - fixes
 - lowest can be equal to highest
 - first round of fixes
 - 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26955/files
  - new: https://git.openjdk.org/jdk/pull/26955/files/b21cb6ca..5fc2b8a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=08-09

  Stats: 564568 lines in 7813 files changed: 376779 ins; 131311 del; 56478 mod
  Patch: https://git.openjdk.org/jdk/pull/26955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955

PR: https://git.openjdk.org/jdk/pull/26955

From tschatzl at openjdk.org  Thu Oct 30 11:54:57 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Oct 2025 11:54:57 GMT
Subject: RFR: 8370682: G1: Survivor regions not in young gen cset group
Message-ID: <Tyw0IJ8V_gxD9Hua68UgAx-f-7fwoANZFMHyOOydYuM=.b9fab139-f37c-4afa-aee6-fbfcc4172d10@github.com>

Hi all,

  please review this change to fix the inconsistency of survivor regions having a reference to the young gen cardset group, but the cardset group not containing these regions. That also causes some hack in full gc to remove that link separately during GC.

Basically the fix is to avoid adding the survivor regions to the young gen cardset group during gc (where at the end we would remove that link when resetting the young gen cardset), but only add them at the end after clearing the young gen cardset group. Since we already track survivor regions separately during GC for similar purposes, there is no extra complication with that.

This is made possible by GC not using the young gen cardset during evacuation for determining the need for remembered set tracking, but uses the region attribute table only (apart from some asserts that are now handled separately).

(Fwiw, so to make any newly allocated region start tracking remembered sets, just set that flag in the region attribute table; one can decide at the end of GC what to do with these regions wrt to remembered set maintenance)

Testing: gha, tier1-3

Thanks,
  Thomas

-------------

Commit messages:
 - 8370682

Changes: https://git.openjdk.org/jdk/pull/28056/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370682
  Stats: 42 lines in 4 files changed: 22 ins; 10 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/28056.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28056/head:pull/28056

PR: https://git.openjdk.org/jdk/pull/28056

From azafari at openjdk.org  Thu Oct 30 12:06:00 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Oct 2025 12:06:00 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v11]
In-Reply-To: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
Message-ID: <T6ecMU9XlEK7i0CDpMe1C8VpfFNtkK5jnQop8bKm-64=.6478ccd8-6f07-4936-98a4-ab4a1d51ff47@github.com>

> The issue happens when the HeapMinBaseAddress option gets 0 as input value. Since this option is used as an address, then using 0 in pointer arithmetics is UB.
> The fix is using `unitptr_t` instead of `address`/`char*`, etc.  In doing that, it is found that an overflow check does not work in all cases due to checking more conditions. That overflow check is changed too. We also need to check overflow after aligning addresses and sizes of memory regions in this context. Assertions are added to check these cases.
> 
> Tests:
> linux-x64 tier1

Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision:

  fix arguments.cpp for HeapMinBaseAddress type.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/26955/files
  - new: https://git.openjdk.org/jdk/pull/26955/files/5fc2b8a9..0aae9a42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26955&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/26955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26955/head:pull/26955

PR: https://git.openjdk.org/jdk/pull/26955

From azafari at openjdk.org  Thu Oct 30 12:06:07 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Oct 2025 12:06:07 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v10]
In-Reply-To: <MVmRhtoye2zLOR6X-HblyU0MLOPISQ3C9f_OgqUaY6s=.3eb9d3c1-3111-4f30-aa4b-27d18962b430@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <MVmRhtoye2zLOR6X-HblyU0MLOPISQ3C9f_OgqUaY6s=.3eb9d3c1-3111-4f30-aa4b-27d18962b430@github.com>
Message-ID: <OOv719VvAxI6qSvT-2IaMaQpNe2ws5pCXz58HdztW9E=.1c0f870f-ec13-48da-af7a-7a68062da9ac@github.com>

On Thu, 30 Oct 2025 11:51:02 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The issue happens when the HeapMinBaseAddress option gets 0 as input value. Since this option is used as an address, then using 0 in pointer arithmetics is UB.
>> The fix is using `unitptr_t` instead of `address`/`char*`, etc.  In doing that, it is found that an overflow check does not work in all cases due to checking more conditions. That overflow check is changed too. We also need to check overflow after aligning addresses and sizes of memory regions in this context. Assertions are added to check these cases.
>> 
>> Tests:
>> linux-x64 tier1
>
> Afshin Zafari 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 10 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into _8351334_ubsan_nullptr_add
>  - removed redundant check of overflow.
>  - subtraction for checking overflow
>  - fixed MAX2 template parameter
>  - fixes.
>  - uintptr_t -> uint64_t
>  - fixes
>  - lowest can be equal to highest
>  - first round of fixes
>  - 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error: applying non-zero offset 1073741824 to null pointer

> Also I think this might need to account for the changes to `Arguments::set_heap_size` being done in #27224

merged with. Thanks for referring to it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26955#issuecomment-3467660594

From azafari at openjdk.org  Thu Oct 30 12:06:10 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Thu, 30 Oct 2025 12:06:10 GMT
Subject: RFR: 8351334: [ubsan] memoryReserver.cpp:552:60: runtime error:
 applying non-zero offset 1073741824 to null pointer [v7]
In-Reply-To: <1p0PZb6EijjJFhDHDraj1Xh522GehuN9XifO-rReyMw=.ab35fbf1-a00f-4218-9780-1b38f83a0291@github.com>
References: <3p8Po-zqSc7uti36zwqJbCeyBA-OqKDV7GfROVzvB9U=.7dfb19fc-946f-4039-90a5-8d63ee421318@github.com>
 <PaZtc2hIdKh6-6rbBOzygazhvVQsI8R03tq2TwLVVO8=.ee88076b-d695-4639-a548-6a373ace65aa@github.com>
 <o7O0MNu6ATtffPBmT7ITE4GhNCvmu0YCxl-exqxBj1I=.8aebc999-430f-468a-a9e4-93e20caca650@github.com>
 <1p0PZb6EijjJFhDHDraj1Xh522GehuN9XifO-rReyMw=.ab35fbf1-a00f-4218-9780-1b38f83a0291@github.com>
Message-ID: <OOggJA_k7X5mNqzwRGFxmkiUMwSLMzyZDJhoaX28DxI=.a14ea6ed-6b65-4943-85f0-0e9f109abdda@github.com>

On Mon, 20 Oct 2025 07:33:17 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp line 288:
>> 
>>> 286:   // If an overflow happened in Arguments::set_heap_size(), MaxHeapSize will have too large a value.
>>> 287:   // Check for this by ensuring that MaxHeapSize plus the requested min base address still fit within max_uintx.
>>> 288:   if (value + MaxHeapSize < MaxHeapSize) { // overflow
>> 
>> Sorry I am struggling to see how this check differs in practice to the existing check:
>> 
>> (value > (max_uintx - MaxHeapSize))
>> 
>> Further, the comment before the new check seems to relate to the existing check.
>
> Sorry it's my mistake in reading `max - a < b` as `a - b < b` .

Applied.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/26955#discussion_r2477850829

From ayang at openjdk.org  Thu Oct 30 13:11:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 30 Oct 2025 13:11:14 GMT
Subject: RFR: 8369111: G1: Determining concurrent start uses inconsistent
 predicates
In-Reply-To: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
References: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
Message-ID: <41q6vJ9AymLclilTVtapQmG7YMYsB3LDHdklxfDGYXg=.f032028f-6b95-443a-9f21-d40ab2478f2a@github.com>

On Tue, 14 Oct 2025 08:58:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes an inconsistency between requesting a concurrent start garbage collection during humongous object allocation and then actually starting it.
> 
> I.e. in `G1CollectedHeap::attempt_allocation_humongous` we check whether the allocation would cross the IHOP threshold taking the current allocation into account, and if so, see if G1 should start a concurrent marking, eventually starting a GC pause.
> 
> That GC pause did not take the prospective allocation into account, so we could do that GC for nothing (i.e. not start a concurrent marking although we already knew that the allocation would cause one).
> 
> This, in conjunction with JDK-8368959 can cause hundreds of extra GCs for the test in the CR (without eager reclaim of humongous arrays with references); otherwise it could cause the marking starting too late.
> 
> There is a second bug in the calculation whether G1 crossed the threshold: for humongous objects it only takes the actual size into account, not the size that is needed for allocating it. The same issue existed for determining to start a concurrent mark after any other collection too.
> 
> The change also tries to unify naming of the parameter to pass the allocation size (`alloc_word_size` -> `allocation_word_size`) and the parameter order where this size is passed along in multiple related methods.
> 
> Testing: mentioned test case now behaving correctly, tier1-5
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27789#pullrequestreview-3399519691

From ayang at openjdk.org  Thu Oct 30 14:22:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 30 Oct 2025 14:22:17 GMT
Subject: RFR: 8370950: Inline CollectedHeap::fill_args_check
Message-ID: <nKFn88OulCUFdMN_EejTbKLzrvJCFdc72Rs0KobuvDU=.d79617d1-0677-4d44-8705-355c0e445c02@github.com>

Trivial inlining a method to reduce API surface.

Test: tier1

-------------

Commit messages:
 - trivial-inline

Changes: https://git.openjdk.org/jdk/pull/28061/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28061&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370950
  Stats: 11 lines in 2 files changed: 2 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28061.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28061/head:pull/28061

PR: https://git.openjdk.org/jdk/pull/28061

From fandreuzzi at openjdk.org  Thu Oct 30 14:28:24 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 30 Oct 2025 14:28:24 GMT
Subject: RFR: 8370950: Inline CollectedHeap::fill_args_check
In-Reply-To: <nKFn88OulCUFdMN_EejTbKLzrvJCFdc72Rs0KobuvDU=.d79617d1-0677-4d44-8705-355c0e445c02@github.com>
References: <nKFn88OulCUFdMN_EejTbKLzrvJCFdc72Rs0KobuvDU=.d79617d1-0677-4d44-8705-355c0e445c02@github.com>
Message-ID: <xFahwE83YzJ0uq4NoqZQvPRaraQPaz1z85vrTDSXOi4=.8f403a28-c5af-46d7-9381-e790748e1fa2@github.com>

On Thu, 30 Oct 2025 14:14:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to reduce API surface.
> 
> Test: tier1

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28061#pullrequestreview-3399924868

From fandreuzzi at openjdk.org  Thu Oct 30 14:30:29 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 30 Oct 2025 14:30:29 GMT
Subject: RFR: 8370943: Support heap expansion during startup in Serial and
 Parallel
In-Reply-To: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
References: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
Message-ID: <mZauX1l8Gj6qLGwL5PKKrDKYKAtkMEAIELPHJYj8WCk=.a6bae146-bfce-4a45-9c57-2ce584ede6d3@github.com>

On Thu, 30 Oct 2025 11:41:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add heap expansion logic in allocation slow-path during startup. Some asserts are relaxed to be used by java-threads and outside of safepoint.
> 
> Test: tier1-5

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28059#pullrequestreview-3399933794

From tschatzl at openjdk.org  Thu Oct 30 15:43:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 30 Oct 2025 15:43:45 GMT
Subject: RFR: 8370950: Inline CollectedHeap::fill_args_check
In-Reply-To: <nKFn88OulCUFdMN_EejTbKLzrvJCFdc72Rs0KobuvDU=.d79617d1-0677-4d44-8705-355c0e445c02@github.com>
References: <nKFn88OulCUFdMN_EejTbKLzrvJCFdc72Rs0KobuvDU=.d79617d1-0677-4d44-8705-355c0e445c02@github.com>
Message-ID: <aQURaEIIhO1f-Bix7C0dGR0R3Ubrv8vFsfY0zNDUtvQ=.423eedc4-fee4-4a01-8646-6e998ec62959@github.com>

On Thu, 30 Oct 2025 14:14:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to reduce API surface.
> 
> Test: tier1

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28061#pullrequestreview-3400310851

From xpeng at openjdk.org  Thu Oct 30 15:47:41 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 30 Oct 2025 15:47:41 GMT
Subject: RFR: 8370726: GenShen: Misplaced assertion that old referent is
 marked during young collection
In-Reply-To: <5L_CsIwXfAAGEIcPhVkxeBWa4CtaJ5SBDwQxQZTUg4o=.8a624a29-3c90-4b33-9467-415016a7c36d@github.com>
References: <5L_CsIwXfAAGEIcPhVkxeBWa4CtaJ5SBDwQxQZTUg4o=.8a624a29-3c90-4b33-9467-415016a7c36d@github.com>
Message-ID: <Wm5Uq0Fu9S67Y94kYjZt1zsFKszxaKaWERkPadNwGyk=.e9df6cad-ee38-4829-abfe-83ac0228ba9c@github.com>

On Tue, 28 Oct 2025 20:48:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Recently introduced assertion is too strong:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/codebuild/output/src2096/src/s3/00/src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp:332), pid=1373, tid=1375
> # Error: Marking should be complete for object 0x00000007ffc029b0 in the Old generation

Looks good, thanks! Many of our performance test pipelines failed due to this assert.

-------------

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/28026#pullrequestreview-3400332333

From kdnilsen at openjdk.org  Thu Oct 30 17:45:28 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 30 Oct 2025 17:45:28 GMT
Subject: RFR: 8370653: Fix race in CompressedClassSpaceSizeInJmapHeap.java
Message-ID: <Z9Cceh3uRrCMT9RhGRSBfKEIUNm7kfz7xoVaZNQhTkk=.27bb8fe2-2321-41ea-924e-1fcc9e3b9f2e@github.com>

Retry heap-dump request if first attempts fail (typically due to race).

-------------

Commit messages:
 - Use camel case spelling for Java variable names
 - retry failed attach in CompressedClassSpaceSizeInJmapHeap.java
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 38 more: https://git.openjdk.org/jdk/compare/910bb68e...0ccd12ae

Changes: https://git.openjdk.org/jdk/pull/28070/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28070&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370653
  Stats: 15 lines in 1 file changed: 8 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/28070.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28070/head:pull/28070

PR: https://git.openjdk.org/jdk/pull/28070

From kdnilsen at openjdk.org  Thu Oct 30 18:20:51 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 30 Oct 2025 18:20:51 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v34]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <dR-JOXnvyaJ1epqFa-hK0aLcukkTSh5Vm74xiIcxprA=.eb511150-8890-4f67-b588-39e6e1a3391c@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 with a new target base due to a merge or a rebase. The pull request now contains 156 commits:

 - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
 - reviewer feedback
 - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
 - Rework implementation of CompressedClassSpaceSizeInJmapHeap.java
 - fix errors in CompressedClassSpaceSizeInJmapHeap.java
 - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java
 - Add sleep to CompressedClassSpaceSizeInJmapHeap.java test
 - Fix up vmstructs and other infrastructure for jmap heap dump
 - After initialization, check for SoftMaxHeapSize changed by constraints enforcement
 - clamp SoftMaxHeapSize during initialization
 - ... and 146 more: https://git.openjdk.org/jdk/compare/d18e815b...657529e3

-------------

Changes: https://git.openjdk.org/jdk/pull/26867/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=33
  Stats: 3531 lines in 44 files changed: 2118 ins; 1009 del; 404 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 xpeng at openjdk.org  Thu Oct 30 18:32:58 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 30 Oct 2025 18:32:58 GMT
Subject: RFR: 8370667: GenShen: Only make assertions about region pinning
 for collected generation
In-Reply-To: <qwMPg0AlulQm41xokIJdJrHjxr6_8czjsgfRBFE0A4U=.b1d8de31-7136-4549-83c6-29b50964b2b7@github.com>
References: <qwMPg0AlulQm41xokIJdJrHjxr6_8czjsgfRBFE0A4U=.b1d8de31-7136-4549-83c6-29b50964b2b7@github.com>
Message-ID: <Q2uF73cUxH8Enxp8vo46ukcm8JbyYgHJFkJDIFwB_fo=.a6ec5e53-5746-4320-ae77-e3461e668488@github.com>

On Tue, 28 Oct 2025 20:52:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This broke recently because we expanded the scope of the assertion to check all regions. However, there are times when the pin status for a region is only updated if the region belongs to the generation being collected. This change restores the previous behavior of the assertion.

Marked as reviewed by xpeng (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28027#pullrequestreview-3401073785

From eosterlund at openjdk.org  Thu Oct 30 20:29:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 30 Oct 2025 20:29:27 GMT
Subject: RFR: 8370943: Support heap expansion during startup in Serial and
 Parallel
In-Reply-To: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
References: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
Message-ID: <ljUPEq6BeXP91wX12TFuxycllCfjRVwyDQUZOhgSlcc=.90f39c3b-3908-4a2b-a425-23127c5e079f@github.com>

On Thu, 30 Oct 2025 11:41:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add heap expansion logic in allocation slow-path during startup. Some asserts are relaxed to be used by java-threads and outside of safepoint.
> 
> Test: tier1-5

Looks good. Thanks for fixing.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28059#pullrequestreview-3401509291

From ysr at openjdk.org  Thu Oct 30 20:36:35 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 30 Oct 2025 20:36:35 GMT
Subject: RFR: 8370726: GenShen: Misplaced assertion that old referent is
 marked during young collection
In-Reply-To: <5L_CsIwXfAAGEIcPhVkxeBWa4CtaJ5SBDwQxQZTUg4o=.8a624a29-3c90-4b33-9467-415016a7c36d@github.com>
References: <5L_CsIwXfAAGEIcPhVkxeBWa4CtaJ5SBDwQxQZTUg4o=.8a624a29-3c90-4b33-9467-415016a7c36d@github.com>
Message-ID: <jtn-zMQOw8k_YQSpKBiBZ9B7kQIbHngLhk-cAu3aAnk=.ff980012-1c2b-4ad4-aa13-f05debdd26f6@github.com>

On Tue, 28 Oct 2025 20:48:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Recently introduced assertion is too strong:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/codebuild/output/src2096/src/s3/00/src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp:332), pid=1373, tid=1375
> # Error: Marking should be complete for object 0x00000007ffc029b0 in the Old generation

?

-------------

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28026#pullrequestreview-3401532511

From wkemper at openjdk.org  Thu Oct 30 20:43:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Oct 2025 20:43:35 GMT
Subject: Integrated: 8370726: GenShen: Misplaced assertion that old referent is
 marked during young collection
In-Reply-To: <5L_CsIwXfAAGEIcPhVkxeBWa4CtaJ5SBDwQxQZTUg4o=.8a624a29-3c90-4b33-9467-415016a7c36d@github.com>
References: <5L_CsIwXfAAGEIcPhVkxeBWa4CtaJ5SBDwQxQZTUg4o=.8a624a29-3c90-4b33-9467-415016a7c36d@github.com>
Message-ID: <gy6Ru7pgyIZbylnN6fH64xV-t8HC1fA3lMhas61-jJo=.0dbce1cf-113e-46e7-b841-dd006bdc8585@github.com>

On Tue, 28 Oct 2025 20:48:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Recently introduced assertion is too strong:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # Internal Error (/codebuild/output/src2096/src/s3/00/src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp:332), pid=1373, tid=1375
> # Error: Marking should be complete for object 0x00000007ffc029b0 in the Old generation

This pull request has now been integrated.

Changeset: c69e0eb2
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c69e0eb2f98dc80eaefdb399dcfe86cdab32dbd5
Stats:     27 lines in 3 files changed: 4 ins; 14 del; 9 mod

8370726: GenShen: Misplaced assertion that old referent is marked during young collection

Reviewed-by: xpeng, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/28026

From ysr at openjdk.org  Thu Oct 30 20:53:11 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 30 Oct 2025 20:53:11 GMT
Subject: RFR: 8370667: GenShen: Only make assertions about region pinning
 for collected generation
In-Reply-To: <qwMPg0AlulQm41xokIJdJrHjxr6_8czjsgfRBFE0A4U=.b1d8de31-7136-4549-83c6-29b50964b2b7@github.com>
References: <qwMPg0AlulQm41xokIJdJrHjxr6_8czjsgfRBFE0A4U=.b1d8de31-7136-4549-83c6-29b50964b2b7@github.com>
Message-ID: <g1MEo483R9JMbEJTrzt-GQewQBWSz9OPqyY1z9uOaC4=.56c0d27a-e2f6-436c-afd6-b3dc460b95b7@github.com>

On Tue, 28 Oct 2025 20:52:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This broke recently because we expanded the scope of the assertion to check all regions. However, there are times when the pin status for a region is only updated if the region belongs to the generation being collected. This change restores the previous behavior of the assertion.

Marked as reviewed by ysr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28027#pullrequestreview-3401594703

From wkemper at openjdk.org  Thu Oct 30 21:12:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Oct 2025 21:12:38 GMT
Subject: Integrated: 8370667: GenShen: Only make assertions about region
 pinning for collected generation
In-Reply-To: <qwMPg0AlulQm41xokIJdJrHjxr6_8czjsgfRBFE0A4U=.b1d8de31-7136-4549-83c6-29b50964b2b7@github.com>
References: <qwMPg0AlulQm41xokIJdJrHjxr6_8czjsgfRBFE0A4U=.b1d8de31-7136-4549-83c6-29b50964b2b7@github.com>
Message-ID: <setu0bpT_rLCLB35VgOk02Ju_DH7sj83Hk5ERyD3ji0=.7045c6d1-4e7d-40b9-b69f-677c5f0efa9b@github.com>

On Tue, 28 Oct 2025 20:52:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This broke recently because we expanded the scope of the assertion to check all regions. However, there are times when the pin status for a region is only updated if the region belongs to the generation being collected. This change restores the previous behavior of the assertion.

This pull request has now been integrated.

Changeset: c6eea8ac
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6eea8acf6eea7314a1615e5923ac7bf73e6da02
Stats:     13 lines in 4 files changed: 7 ins; 0 del; 6 mod

8370667: GenShen: Only make assertions about region pinning for collected generation

Reviewed-by: xpeng, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/28027

From ysr at openjdk.org  Thu Oct 30 23:56:03 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 30 Oct 2025 23:56:03 GMT
Subject: RFR: 8370521: GenShen: Various code cleanup related to promotion
In-Reply-To: <fLqV6-Ycz0uhdc0ayoGQj5GpWnCmD-bo6JGDfg8UELU=.3f4698f2-c32b-4454-be42-52ed6d737ba3@github.com>
References: <fLqV6-Ycz0uhdc0ayoGQj5GpWnCmD-bo6JGDfg8UELU=.3f4698f2-c32b-4454-be42-52ed6d737ba3@github.com>
Message-ID: <bUIp7WNwI6mB6Qt4a4ClIG6b-5c6WTua_7ZFScBcK1g=.4a0d1809-3579-4380-8b6c-fa5858a75cca@github.com>

On Thu, 23 Oct 2025 22:50:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Use more log tags for finer grained control over debug output. 
> * Add instrumentation for plab and cset decisions
> * Fix typos in comments and minor formatting issues
> * Rename some methods and variables for easier reading
> 
> There are no behavioral changes here. These changes were hoisted from https://github.com/openjdk/jdk/pull/27632 to facilitate its review.

Marked as reviewed by ysr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27963#pullrequestreview-3402108722

From phh at openjdk.org  Thu Oct 30 23:56:05 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 30 Oct 2025 23:56:05 GMT
Subject: RFR: 8370653: Fix race in CompressedClassSpaceSizeInJmapHeap.java
In-Reply-To: <Z9Cceh3uRrCMT9RhGRSBfKEIUNm7kfz7xoVaZNQhTkk=.27bb8fe2-2321-41ea-924e-1fcc9e3b9f2e@github.com>
References: <Z9Cceh3uRrCMT9RhGRSBfKEIUNm7kfz7xoVaZNQhTkk=.27bb8fe2-2321-41ea-924e-1fcc9e3b9f2e@github.com>
Message-ID: <-11ZLm53gvW9o-O5gBVzEVRgJaEDkFGo91Z0fBbufGI=.34955f85-f363-4075-8d68-8dee10dd87fd@github.com>

On Thu, 30 Oct 2025 17:36:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Retry heap-dump request if first attempts fail (typically due to race).

Marked as reviewed by phh (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28070#pullrequestreview-3402107410

From wkemper at openjdk.org  Thu Oct 30 23:56:06 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 30 Oct 2025 23:56:06 GMT
Subject: RFR: 8370653: Fix race in CompressedClassSpaceSizeInJmapHeap.java
In-Reply-To: <Z9Cceh3uRrCMT9RhGRSBfKEIUNm7kfz7xoVaZNQhTkk=.27bb8fe2-2321-41ea-924e-1fcc9e3b9f2e@github.com>
References: <Z9Cceh3uRrCMT9RhGRSBfKEIUNm7kfz7xoVaZNQhTkk=.27bb8fe2-2321-41ea-924e-1fcc9e3b9f2e@github.com>
Message-ID: <Y0DZBVMgx7DyKuGiJpDfAoMSyOgbzw4UOO0qf33pZn4=.6ed7560e-d71d-472a-8d70-154b5ce95bb8@github.com>

On Thu, 30 Oct 2025 17:36:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Retry heap-dump request if first attempts fail (typically due to race).

Marked as reviewed by wkemper (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28070#pullrequestreview-3402107840

From ysr at openjdk.org  Fri Oct 31 00:00:04 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 31 Oct 2025 00:00:04 GMT
Subject: RFR: 8370653: Fix race in CompressedClassSpaceSizeInJmapHeap.java
In-Reply-To: <Z9Cceh3uRrCMT9RhGRSBfKEIUNm7kfz7xoVaZNQhTkk=.27bb8fe2-2321-41ea-924e-1fcc9e3b9f2e@github.com>
References: <Z9Cceh3uRrCMT9RhGRSBfKEIUNm7kfz7xoVaZNQhTkk=.27bb8fe2-2321-41ea-924e-1fcc9e3b9f2e@github.com>
Message-ID: <rpXE-CFJN8PUehqAsyhcTIhS88NzKJW6c7HIhgrdekY=.eabd9991-a688-4184-affd-a1cdda6386e0@github.com>

On Thu, 30 Oct 2025 17:36:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Retry heap-dump request if first attempts fail (typically due to race).

Marked as reviewed by ysr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28070#pullrequestreview-3402112689

From wkemper at openjdk.org  Fri Oct 31 00:02:49 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 31 Oct 2025 00:02:49 GMT
Subject: RFR: 8370041: GenShen: Filter young pointers from thread local
 SATB buffers when only marking old [v2]
In-Reply-To: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>
References: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>
Message-ID: <ktau3Amyo9gY74RtbNAtZS2vEre4yAC3FQqH_cAyP4I=.ca04b613-a3ef-40f6-8e2e-91334a8f472b@github.com>

> When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'.
> 
> # Background
> When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things.

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 20 additional commits since the last revision:

 - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots
 - Flush SATB buffers upon entering degenerated cycle when old marking is in progress
   
   This has to happen at least once during the degenerated cycle. Doing it at the start, rather than the end, simplifies the verifier.
 - Fix typo in comment
 - Remove duplicate satb flush closure
 - Only flush satb once during degenerated cycle
 - Cleanup and comments
 - Merge remote-tracking branch 'jdk/master' into piggyback-satb-flush-on-update-roots
 - Fix assertion
 - Oops, move inline definition out of ifdef ASSERT
 - Try piggybacking satb flush on update roots
 - ... and 10 more: https://git.openjdk.org/jdk/compare/3bb543d1...01f0f976

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27983/files
  - new: https://git.openjdk.org/jdk/pull/27983/files/ec58b72f..01f0f976

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27983&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27983&range=00-01

  Stats: 43161 lines in 471 files changed: 21775 ins; 18947 del; 2439 mod
  Patch: https://git.openjdk.org/jdk/pull/27983.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27983/head:pull/27983

PR: https://git.openjdk.org/jdk/pull/27983

From wkemper at openjdk.org  Fri Oct 31 00:02:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 31 Oct 2025 00:02:50 GMT
Subject: RFR: 8370041: GenShen: Filter young pointers from thread local
 SATB buffers when only marking old
In-Reply-To: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>
References: <tKXKR3Hmi2XQNmFJUO3rmz-nad24690u3bJzJLI-Has=.9ee04857-bdc3-40d5-9531-7e54b8f75f9d@github.com>
Message-ID: <in5WCiF9KrDUAlh_2GqnSSKCz4j4L3Do9f1rijx3LD0=.a3a4c3de-5e73-465b-91ba-d65e436bf962@github.com>

On Fri, 24 Oct 2025 21:00:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When GenShen is only marking the old generation, we do not need the SATB mechanism to preserve young pointers. We currently filter these out of the SATB buffers during the final-update-refs and init-mark safepoints. This increases latency and introduces no small amount of complexity. It should be possible to instead filter out these pointers when the SATB buffers are 'compacted' before being 'completed'.
> 
> # Background
> When GenShen is marking the old generation it leaves the SATB barrier enabled. When a young collection interrupts old marking, it creates a situation where a mutator thread could overwrite a field holding a pointer into a collection set region. The SATB barrier will dutifully place this object in the SATB queue. If this pointer makes it into a mark queue, the marking thread will crash. Prior to this change, GenShen filtered out such pointers _after_ the thread local SATB buffers were completed. After this change, such pointers are filtered out _before_ the buffers are completed. This is more inline with the natural way of things.

I found an issue with the verifier that needs to be fixed before this PR is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27983#issuecomment-3457297107

From kdnilsen at openjdk.org  Fri Oct 31 00:07:19 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 31 Oct 2025 00:07:19 GMT
Subject: Integrated: 8370653: Fix race in
 CompressedClassSpaceSizeInJmapHeap.java
In-Reply-To: <Z9Cceh3uRrCMT9RhGRSBfKEIUNm7kfz7xoVaZNQhTkk=.27bb8fe2-2321-41ea-924e-1fcc9e3b9f2e@github.com>
References: <Z9Cceh3uRrCMT9RhGRSBfKEIUNm7kfz7xoVaZNQhTkk=.27bb8fe2-2321-41ea-924e-1fcc9e3b9f2e@github.com>
Message-ID: <O9J8Izc901zRk-jN5QtkiDnfG82n9Lr5_r8dbTjvako=.234ddfd4-a40d-4949-975b-212912137a9c@github.com>

On Thu, 30 Oct 2025 17:36:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Retry heap-dump request if first attempts fail (typically due to race).

This pull request has now been integrated.

Changeset: dfa04f4a
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dfa04f4aa5463de7812877553ea779da6467d373
Stats:     15 lines in 1 file changed: 8 ins; 3 del; 4 mod

8370653: Fix race in CompressedClassSpaceSizeInJmapHeap.java

Reviewed-by: phh, wkemper, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/28070

From wkemper at openjdk.org  Fri Oct 31 00:11:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 31 Oct 2025 00:11:11 GMT
Subject: Integrated: 8370521: GenShen: Various code cleanup related to
 promotion
In-Reply-To: <fLqV6-Ycz0uhdc0ayoGQj5GpWnCmD-bo6JGDfg8UELU=.3f4698f2-c32b-4454-be42-52ed6d737ba3@github.com>
References: <fLqV6-Ycz0uhdc0ayoGQj5GpWnCmD-bo6JGDfg8UELU=.3f4698f2-c32b-4454-be42-52ed6d737ba3@github.com>
Message-ID: <yXQjocXpa50tiJIo7X_TMrVnGfpXwPrmW95Ax7h8LM8=.b58c29fa-2bd0-4b76-938f-c569ea452197@github.com>

On Thu, 23 Oct 2025 22:50:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> * Use more log tags for finer grained control over debug output. 
> * Add instrumentation for plab and cset decisions
> * Fix typos in comments and minor formatting issues
> * Rename some methods and variables for easier reading
> 
> There are no behavioral changes here. These changes were hoisted from https://github.com/openjdk/jdk/pull/27632 to facilitate its review.

This pull request has now been integrated.

Changeset: 6347f10b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6347f10bf1dd3959cc1f2aba32e72ca8d9d56e82
Stats:     75 lines in 12 files changed: 18 ins; 10 del; 47 mod

8370521: GenShen: Various code cleanup related to promotion

Reviewed-by: fandreuzzi, kdnilsen, ysr

-------------

PR: https://git.openjdk.org/jdk/pull/27963

From wkemper at openjdk.org  Fri Oct 31 00:21:27 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 31 Oct 2025 00:21:27 GMT
Subject: RFR: 8314599: [GenShen] Couple adaptive tenuring and generation
 size budgeting [v7]
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: <ubdl4-Qo7pkxBWlhHeXC0JOiFgcnKqaHyVE4QxwbhHI=.fc6bd57f-527d-454a-8b51-81e9fed5d1ee@github.com>

> Notable changes:
> * Improvements to logging
> * More accurate tracking of promotion failures
> * Use shared allocation for promotions only when the size is above the maximum plab size (not the minimum size)
> * Use census information gathered during mark to size promotion reserves and old generation
> 
> With these changes, GenShen is expected to have fewer promotion failures and this is indeed the case. As a result of this, we expect less time to be spent in concurrent marking and update refs for young collections. We may also expect shorter concurrent evacuation phases because GenShen will have fewer densely packed regions stuck in the young generation. With more objects being promoted, we also expect to see longer remembered set scan times. This is generally the case across all benchmarks, but we do also see some counter-intuitive results.
> 
> Here we are comparing 20 executions (10 on x86, 10 on aarch64) of the changes in the PR (experiment) against 20 executions of the same benchmarks results from tip. This is a summary of statistically significant changes of more than 5% across all benchmarks:
> 
> 
> Concurrent Evacuation: 7 improvements, 3 regressions
> ? Best improvements: extremem-large-45g (-29.6%), neo4j-analytics (-26.9%)
> ? Worst regression: xalan (+53.7%)
> 
> Concurrent Marking: 15 improvements, 1 regression  
> ? Best improvements: hyperalloc_a2048_o4096 (-30.1%), crypto.rsa (-27.3%)
> ? Only regression: serial (+8.9%)
> 
> Concurrent Scan Remembered Set: 7 improvements, 2 regressions
> ? Best improvements: xalan (-49.4%), pmd (-49.0%), crypto.rsa (-41.8%)
> ? Worst regression: extremem-phased (+52.4%)
> 
> Concurrent Update Refs: 5 improvements, 4 regressions
> ? Best improvements: crypto.rsa (-36.4%), mnemonics (-28.4%)
> ? Worst regression: xalan (+89.4%)

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:

 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Merge tag 'jdk-26+20' into promotion-budget-improvements
   
   Added tag jdk-26+20 for changeset b5b83247
 - Proper format bytes in logs for better readability
 - Merge remote-tracking branch 'jdk/master' into promotion-budget-improvements
 - Review feedback, bug fixes
 - Fix windows build more
 - Fix windows build
 - Little cleanup
 - Fix wrong asserts
 - ... and 50 more: https://git.openjdk.org/jdk/compare/6347f10b...1d81159a

-------------

Changes: https://git.openjdk.org/jdk/pull/27632/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27632&range=06
  Stats: 245 lines in 5 files changed: 139 ins; 79 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/27632.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27632/head:pull/27632

PR: https://git.openjdk.org/jdk/pull/27632

From kdnilsen at openjdk.org  Fri Oct 31 01:09:32 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 31 Oct 2025 01:09:32 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v35]
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <UF20F354ZRHxN8MAuTjfs5fsqwV_viDwjptkrC6DSIo=.48b710da-aec0-45ed-8de4-a07fd960b346@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 with a new target base due to a merge or a rebase. The pull request now contains 157 commits:

 - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
 - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
 - reviewer feedback
 - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
 - Rework implementation of CompressedClassSpaceSizeInJmapHeap.java
 - fix errors in CompressedClassSpaceSizeInJmapHeap.java
 - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java
 - Add sleep to CompressedClassSpaceSizeInJmapHeap.java test
 - Fix up vmstructs and other infrastructure for jmap heap dump
 - After initialization, check for SoftMaxHeapSize changed by constraints enforcement
 - ... and 147 more: https://git.openjdk.org/jdk/compare/6347f10b...53af6b19

-------------

Changes: https://git.openjdk.org/jdk/pull/26867/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26867&range=34
  Stats: 3516 lines in 43 files changed: 2110 ins; 1006 del; 400 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 wkemper at openjdk.org  Fri Oct 31 01:15:09 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 31 Oct 2025 01:15:09 GMT
Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save
 unnecessary region iteration
In-Reply-To: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
References: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
Message-ID: <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com>

On Wed, 29 Oct 2025 05:29:14 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice:
> 1. fast path: traverse regions between left most and right most in the partition,  and try to allocate in an affiliated region in the partition;  
> 2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region.
> 
> 2 can be saved if we also remember the first FREE region seem in 1.
> 
> The PR makes the code much cleaner, and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference) 
> 
> 
> Test:
> - [x] hotspot_gc_shenandoah

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 779:

> 777:         return result;
> 778:       }
> 779:     } else if (free_region == nullptr && r->affiliation() == FREE &&

The logic in `can_allocate_from` is slightly different from what's here. Do we want to check that the region is `FREE` _or_ it is `trash` and we are not in concurrent weak roots?

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 901:

> 899:   }
> 900: 
> 901:   bool allow_new_region = can_allocate_in_new_region(req);

Are we losing the check here? Before this change, the region had to be `FREE` _and_ the generation affiliated with the request had to have `free_unaffiliated_regions`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2479902404
PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2479900571

From cjplummer at openjdk.org  Fri Oct 31 02:54:09 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 31 Oct 2025 02:54:09 GMT
Subject: RFR: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc
 for nsk/jvmti tests [v8]
In-Reply-To: <WF2WQMquEWVQzEmvLFDFTLEri9quM4TCvyGpU1MWyLU=.ca1b9440-9527-49ce-bf00-9c79b81e9cad@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <WF2WQMquEWVQzEmvLFDFTLEri9quM4TCvyGpU1MWyLU=.ca1b9440-9527-49ce-bf00-9c79b81e9cad@github.com>
Message-ID: <INLE8Z6wPSJQ0gMmCPaIU_0szfDMrUc7EmnZYjwNQQs=.70d9af6a-4760-4fd2-bb4e-f14455f61f08@github.com>

On Thu, 30 Oct 2025 03:57:21 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of 'ClassUnloader.eatMemory()' to provoking gc for several test/hotspot/jtreg/vmTestbase/nsk/jvmti tests, It is the fast and robust way to trigger Full GC without risks hitting OOME, and will make test run finish more quicker on machine with huge physical memory.
>> 
>> Change has been verified locally, test-fix only, no risk.
>> 
>> 
>> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary "import nsk.share.ClassUnloader;"

test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Target.java line 53:

> 51:         try {
> 52:             if (createTaggedObject()) {
> 53:                 log.display("Provoking GC");

Please leave the log message in place.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2480006915

From syan at openjdk.org  Fri Oct 31 03:04:48 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 31 Oct 2025 03:04:48 GMT
Subject: RFR: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc
 for nsk/jvmti tests [v9]
In-Reply-To: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
Message-ID: <hLdJkXUM20apkP_7lLNQPUME8kS8Drx1cPZZBvo5mVE=.37db32ec-3b52-481a-8ff9-467c30c8d675@github.com>

> Hi all,
> 
> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of 'ClassUnloader.eatMemory()' to provoking gc for several test/hotspot/jtreg/vmTestbase/nsk/jvmti tests, It is the fast and robust way to trigger Full GC without risks hitting OOME, and will make test run finish more quicker on machine with huge physical memory.
> 
> Change has been verified locally, test-fix only, no risk.
> 
> 
> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Add log.display("Provoking GC");

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28011/files
  - new: https://git.openjdk.org/jdk/pull/28011/files/4f7c2adb..0b4d40b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28011&range=07-08

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28011.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28011/head:pull/28011

PR: https://git.openjdk.org/jdk/pull/28011

From syan at openjdk.org  Fri Oct 31 03:04:48 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 31 Oct 2025 03:04:48 GMT
Subject: RFR: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc
 for nsk/jvmti tests [v9]
In-Reply-To: <INLE8Z6wPSJQ0gMmCPaIU_0szfDMrUc7EmnZYjwNQQs=.70d9af6a-4760-4fd2-bb4e-f14455f61f08@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <WF2WQMquEWVQzEmvLFDFTLEri9quM4TCvyGpU1MWyLU=.ca1b9440-9527-49ce-bf00-9c79b81e9cad@github.com>
 <INLE8Z6wPSJQ0gMmCPaIU_0szfDMrUc7EmnZYjwNQQs=.70d9af6a-4760-4fd2-bb4e-f14455f61f08@github.com>
Message-ID: <Jq8dMnA4IGKfpw2GDMHqntdaX07TndmF15X40UUeKTc=.cb6ab377-4f65-46ea-8308-f3068a0efa35@github.com>

On Fri, 31 Oct 2025 02:48:03 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add log.display("Provoking GC");
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/AttachOnDemand/attach021/attach021Target.java line 53:
> 
>> 51:         try {
>> 52:             if (createTaggedObject()) {
>> 53:                 log.display("Provoking GC");
> 
> Please leave the log message in place.

Sorry, I think it's misoperation. Fixed. I have check other log.display. Only this one was removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28011#discussion_r2480021556

From cjplummer at openjdk.org  Fri Oct 31 03:22:05 2025
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 31 Oct 2025 03:22:05 GMT
Subject: RFR: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc
 for nsk/jvmti tests [v9]
In-Reply-To: <hLdJkXUM20apkP_7lLNQPUME8kS8Drx1cPZZBvo5mVE=.37db32ec-3b52-481a-8ff9-467c30c8d675@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <hLdJkXUM20apkP_7lLNQPUME8kS8Drx1cPZZBvo5mVE=.37db32ec-3b52-481a-8ff9-467c30c8d675@github.com>
Message-ID: <ISSpFmBGpRBVNMPcx3uWDKzZgFL9j-s4K41H5X3yoFo=.d51158cc-9d55-44c0-83d1-d313b328f78b@github.com>

On Fri, 31 Oct 2025 03:04:48 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of 'ClassUnloader.eatMemory()' to provoking gc for several test/hotspot/jtreg/vmTestbase/nsk/jvmti tests, It is the fast and robust way to trigger Full GC without risks hitting OOME, and will make test run finish more quicker on machine with huge physical memory.
>> 
>> Change has been verified locally, test-fix only, no risk.
>> 
>> 
>> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add log.display("Provoking GC");

Looks good. Thanks for cleaning this up!

-------------

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28011#pullrequestreview-3402429189

From lmesnik at openjdk.org  Fri Oct 31 03:22:06 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 31 Oct 2025 03:22:06 GMT
Subject: RFR: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc
 for nsk/jvmti tests [v9]
In-Reply-To: <hLdJkXUM20apkP_7lLNQPUME8kS8Drx1cPZZBvo5mVE=.37db32ec-3b52-481a-8ff9-467c30c8d675@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <hLdJkXUM20apkP_7lLNQPUME8kS8Drx1cPZZBvo5mVE=.37db32ec-3b52-481a-8ff9-467c30c8d675@github.com>
Message-ID: <jNnChjF-Q4Y3sYhrojtaJnPFlHonHOj0bAcpsx7o9Go=.cef4b940-574c-4da2-ac46-7dba7e2f30d6@github.com>

On Fri, 31 Oct 2025 03:04:48 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of 'ClassUnloader.eatMemory()' to provoking gc for several test/hotspot/jtreg/vmTestbase/nsk/jvmti tests, It is the fast and robust way to trigger Full GC without risks hitting OOME, and will make test run finish more quicker on machine with huge physical memory.
>> 
>> Change has been verified locally, test-fix only, no risk.
>> 
>> 
>> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add log.display("Provoking GC");

Re-approving. Thanks for a nice cleanup!

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28011#pullrequestreview-3402434871

From ysr at openjdk.org  Fri Oct 31 05:09:04 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 31 Oct 2025 05:09:04 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: <j4vQKdGTAq9CfioIPRD3X0pY6V7-2wEg6ht0-k14yxY=.b10e49fd-06e9-4929-9205-87cb338d81c5@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.

Left a few comments. (In particular of what looks like a deadlock possibility in debug builds.)

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 240:

> 238:   // Return available_in assuming caller does not hold the heap lock.  In production builds, available is
> 239:   // returned without acquiring the lock.  In debug builds, the global heap lock is acquired in order to
> 240:   // enforce a consistency assert.

Can the comment be simplified to:


// Return bytes `available` in the given `partition`
// while holding the `rebuild_lock`.


Don't say anything about the heap lock in the API comment. Rather, in the part that is `ifdef ASSERT` where you take the heap lock (line ~244), say:

//  Acquire the heap lock to get a consistent
// snapshot to check assert.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 323:

> 321:   ShenandoahRegionPartitions _partitions;
> 322: 
> 323:   // This locks the rebuild process (in combination with the global heap lock)

Explain the role of this & the global heap lock vis-a-vis the rebuild process.

Also may be call it `_rebuild_lock`, rather than just `_lock`.

src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 426:

> 424: 
> 425: 
> 426:   ShenandoahRebuildLock* lock() {

`rebuild_lock()` instead?

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1158:

> 1156:     size_t young_cset_regions, old_cset_regions, first_old, last_old, num_old;
> 1157:     ShenandoahFreeSet* free_set = heap->free_set();
> 1158:     ShenandoahRebuildLocker rebuild_locker(free_set->lock());

Should you not create a scope around lines 1158 to line 1167, since you don't want to hold the rebuild lock as soon as the rebuild is done (i.e. immediately following `finish_rebuild()`)?

-------------

PR Review: https://git.openjdk.org/jdk/pull/27612#pullrequestreview-3402148589
PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2479874892
PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2479853761
PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2479854317
PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2479861263

From ysr at openjdk.org  Fri Oct 31 05:09:05 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 31 Oct 2025 05:09:05 GMT
Subject: RFR: 8369048: GenShen: Defer ShenFreeSet::available() during
 rebuild
In-Reply-To: <j4vQKdGTAq9CfioIPRD3X0pY6V7-2wEg6ht0-k14yxY=.b10e49fd-06e9-4929-9205-87cb338d81c5@github.com>
References: <_PEoOc0oWb8Vzq16-Or_hykkL4NkIrwEFgLCgCRac5U=.2c23c497-acbe-48f9-a1dc-4eb4e8f25a8d@github.com>
 <j4vQKdGTAq9CfioIPRD3X0pY6V7-2wEg6ht0-k14yxY=.b10e49fd-06e9-4929-9205-87cb338d81c5@github.com>
Message-ID: <EWPguFCFC4uJwwlQ1IR3IvrHRlRJ3REkWd-xXL4JORs=.38ca0305-b9fa-4098-9af7-67e09864af1f@github.com>

On Fri, 31 Oct 2025 00:44:11 GMT, Y. Srinivas Ramakrishna <ysr 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.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.hpp line 240:
> 
>> 238:   // Return available_in assuming caller does not hold the heap lock.  In production builds, available is
>> 239:   // returned without acquiring the lock.  In debug builds, the global heap lock is acquired in order to
>> 240:   // enforce a consistency assert.
> 
> Can the comment be simplified to:
> 
> 
> // Return bytes `available` in the given `partition`
> // while holding the `rebuild_lock`.
> 
> 
> Don't say anything about the heap lock in the API comment. Rather, in the part that is `ifdef ASSERT` where you take the heap lock (line ~244), say:
> 
> //  Acquire the heap lock to get a consistent
> // snapshot to check assert.

As I write this, I realize that in the most general case where two threads may call these API's independently in a fastdebug build, you could theoretically get into a deadlock because they attempted to acquire locks in different orders (this possibility exists -- statically -- only in the fastdebug builds).

The general MuteLocker machinery has ranked mutexes to avoid such situations through static ranking and checks while acquiring locks (in debug builds as a way of potentially catching such situations and flagging them).

With such ranking though this code would assert because the locks are acquired in different order between here and elsewhere.

In product builds you are fine because the rebuild lock acts as a "leaf lock" (in hotspot parlance). But there seems to be a definite possibility of deadlock in debug builds if/when the rebuild is attempted by one thread while another checks available and attempts to acquire the heap lock to check the assertion. You could solve it by acquiring the heap lock before calling the work method where the assertion check is done.

However, I'd be much more comfortable if we used some form of lock rank framework, unless it was utterly impossible to do so for some reason. (Here it was easy to spot the lock order inversion because it was in the code. Of course, if a debug build deadlocked you would also figure out the same, but having lock ordering gives you a quick and easy way to verify if there's potential for trouble.)

Not sure of the history of ShenandoahLock or why the parallel infra to MutexLocker was introduced (perhaps for allowing some performance/tunability), but might be worthwhile to see if we want to build lock rank checks in for robustness/maintainability.

> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1158:
> 
>> 1156:     size_t young_cset_regions, old_cset_regions, first_old, last_old, num_old;
>> 1157:     ShenandoahFreeSet* free_set = heap->free_set();
>> 1158:     ShenandoahRebuildLocker rebuild_locker(free_set->lock());
> 
> Should you not create a scope around lines 1158 to line 1167, since you don't want to hold the rebuild lock as soon as the rebuild is done (i.e. immediately following `finish_rebuild()`)?

May be it doesn't matter, since no one else is running during a full gc who needs to query `available()`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2479898169
PR Review Comment: https://git.openjdk.org/jdk/pull/27612#discussion_r2479867780

From tschatzl at openjdk.org  Fri Oct 31 06:42:11 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 31 Oct 2025 06:42:11 GMT
Subject: RFR: 8370889: G1: Inline
 G1PrepareEvacuationTask::sample_card_set_size()
In-Reply-To: <T10ryAV0OpRJBCKwHN3Gfa3Vxu-6xHjwQoEcfJgYJn8=.7652a737-87a2-49ca-8082-d8a1f7ee7fac@github.com>
References: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>
 <T10ryAV0OpRJBCKwHN3Gfa3Vxu-6xHjwQoEcfJgYJn8=.7652a737-87a2-49ca-8082-d8a1f7ee7fac@github.com>
Message-ID: <m5OY4PHgIdks0xgIVBuano9xdSK8EkJYiBzlPyJy5_Y=.9f41684e-9fdb-43ef-9e97-c83f95424d8e@github.com>

On Wed, 29 Oct 2025 19:35:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this simple inlining of a one-liner method that is used once (discounting the check before that line that is actually repeated just a few lines below the call).
>> 
>> Also made the member name a bit more specific.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @walulyai @fandreuz for your reviews

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28046#issuecomment-3471519502

From tschatzl at openjdk.org  Fri Oct 31 06:42:13 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 31 Oct 2025 06:42:13 GMT
Subject: Integrated: 8370889: G1: Inline
 G1PrepareEvacuationTask::sample_card_set_size()
In-Reply-To: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>
References: <MyHLNPE0Q76-Wxrk8px8IUPH1PDbI-kMkWXlojAYmNA=.b3140406-9fc3-4c2b-a6de-8e867a38b3d2@github.com>
Message-ID: <EXaDo77fqe0cimtGNCS7uUT8Cen0C3GlJVhOnVxK828=.733f7745-5ea4-4c7b-bfb6-a12898439e7d@github.com>

On Wed, 29 Oct 2025 15:51:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this simple inlining of a one-liner method that is used once (discounting the check before that line that is actually repeated just a few lines below the call).
> 
> Also made the member name a bit more specific.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: c47ea121
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c47ea1211189d67a0b9ef1a893dacabbc606dae5
Stats:     21 lines in 1 file changed: 6 ins; 10 del; 5 mod

8370889: G1: Inline G1PrepareEvacuationTask::sample_card_set_size()

Reviewed-by: fandreuzzi, ayang, iwalulya

-------------

PR: https://git.openjdk.org/jdk/pull/28046

From tschatzl at openjdk.org  Fri Oct 31 08:22:01 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 31 Oct 2025 08:22:01 GMT
Subject: RFR: 8370943: Support heap expansion during startup in Serial and
 Parallel
In-Reply-To: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
References: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
Message-ID: <he_gosQpUdtGRbs6_oTx9yUHvg6N0jVf_bbO6eahs-4=.3ae8fccf-9065-4043-952b-f5b8a2a9a0f3@github.com>

On Thu, 30 Oct 2025 11:41:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add heap expansion logic in allocation slow-path during startup. Some asserts are relaxed to be used by java-threads and outside of safepoint.
> 
> Test: tier1-5

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28059#pullrequestreview-3402997828

From tschatzl at openjdk.org  Fri Oct 31 08:23:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 31 Oct 2025 08:23:07 GMT
Subject: RFR: 8370774: Merge ModRefBarrierSet into CardTableBarrierSet
In-Reply-To: <4E4gACqFjlt5P5yJtCzgFFDk9GIamGuQriH4uoJX9Kc=.c9b53715-c582-4bef-8304-6d0e710cfcbd@github.com>
References: <4E4gACqFjlt5P5yJtCzgFFDk9GIamGuQriH4uoJX9Kc=.c9b53715-c582-4bef-8304-6d0e710cfcbd@github.com>
Message-ID: <eolU6ZGFZ1-NSig8AhSQk6bxCPyzlSoJZ-uEoDYA3OI=.6e75394c-413f-4ab6-8d40-81ace8b7fb3f@github.com>

On Tue, 28 Oct 2025 09:20:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Merge a class into its sole subclass.
> 
> Many files are changed in this PR, and they can be largely divided into two groups, moving content of `ModRefBarrierSet` into `CardTableBarrierSet` (`src/hotspot/share/gc/`) and platform specific moving content of `ModRefBarrierSetAssembler` into `CardTableBarrierSetAssembler` (`src/hotspot/cpu/`).
> 
> Test: tier1-5 for x64 and aarch64; GHA

Seems good.

-------------

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28013#pullrequestreview-3402999525

From ayang at openjdk.org  Fri Oct 31 08:50:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 31 Oct 2025 08:50:17 GMT
Subject: RFR: 8370950: Inline CollectedHeap::fill_args_check
In-Reply-To: <nKFn88OulCUFdMN_EejTbKLzrvJCFdc72Rs0KobuvDU=.d79617d1-0677-4d44-8705-355c0e445c02@github.com>
References: <nKFn88OulCUFdMN_EejTbKLzrvJCFdc72Rs0KobuvDU=.d79617d1-0677-4d44-8705-355c0e445c02@github.com>
Message-ID: <zuKxIoKF6JPyinSI-SAjMeqBvjsnxYpM-nY16n1NAPE=.1be669d7-8a52-4c09-b765-3b8856a70daa@github.com>

On Thu, 30 Oct 2025 14:14:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to reduce API surface.
> 
> Test: tier1

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28061#issuecomment-3471923708

From ayang at openjdk.org  Fri Oct 31 08:50:18 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 31 Oct 2025 08:50:18 GMT
Subject: Integrated: 8370950: Inline CollectedHeap::fill_args_check
In-Reply-To: <nKFn88OulCUFdMN_EejTbKLzrvJCFdc72Rs0KobuvDU=.d79617d1-0677-4d44-8705-355c0e445c02@github.com>
References: <nKFn88OulCUFdMN_EejTbKLzrvJCFdc72Rs0KobuvDU=.d79617d1-0677-4d44-8705-355c0e445c02@github.com>
Message-ID: <cDmOIrwPD3HWx4ggFCI3KlZvNukQSrxncKgNkdR4ToI=.533466de-1c34-45f5-8929-cb82e26b7161@github.com>

On Thu, 30 Oct 2025 14:14:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial inlining a method to reduce API surface.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 4913b548
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4913b548a79a981816718def38d059b5175f6f59
Stats:     11 lines in 2 files changed: 2 ins; 7 del; 2 mod

8370950: Inline CollectedHeap::fill_args_check

Reviewed-by: fandreuzzi, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/28061

From ayang at openjdk.org  Fri Oct 31 09:38:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 31 Oct 2025 09:38:16 GMT
Subject: RFR: 8371018: Remove unused CollectedHeap::fill_with_object
Message-ID: <IWyl45Dt3kYPkHNJW0eshfZ8TxwFhBXoeHDzBP8xLHs=.c8fcf107-3db4-47c8-abae-50189232e561@github.com>

Trivial removing dead code.

Test: GHA

-------------

Commit messages:
 - trivial-remove

Changes: https://git.openjdk.org/jdk/pull/28082/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28082&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371018
  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28082/head:pull/28082

PR: https://git.openjdk.org/jdk/pull/28082

From fandreuzzi at openjdk.org  Fri Oct 31 10:39:04 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 31 Oct 2025 10:39:04 GMT
Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask
In-Reply-To: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
References: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
Message-ID: <igAWgREsY02ceHwL73eVcNLB744A8BQ8PhiFZiWvGTI=.cef7e578-40e0-426d-8a06-625c331545b8@github.com>

On Wed, 15 Oct 2025 13:31:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context.
> 
> Test: tier1-5

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27822#pullrequestreview-3403614554

From jsikstro at openjdk.org  Fri Oct 31 12:06:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 31 Oct 2025 12:06:03 GMT
Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask
In-Reply-To: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
References: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
Message-ID: <NMwYVXLQ-zwPD846WRwKJTiSGFVO0mHFmRqgsCHHfGY=.b02704e9-f99b-4ffe-be32-ae7250583309@github.com>

On Wed, 15 Oct 2025 13:31:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context.
> 
> Test: tier1-5

Looks good.

src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1383:

> 1381:     _weak_proc_task(nworkers),
> 1382:     _nworkers(nworkers),
> 1383:     _code_cache_claimed(false) {

Looks weird that we're not calling the constructor for `_oop_storage_iter`, but it's fine since it only has a default-ctor anyway. Up to you if we add it.

-------------

Marked as reviewed by jsikstro (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27822#pullrequestreview-3403915379
PR Review Comment: https://git.openjdk.org/jdk/pull/27822#discussion_r2481163210

From stefank at openjdk.org  Fri Oct 31 12:21:06 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 31 Oct 2025 12:21:06 GMT
Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask
In-Reply-To: <NMwYVXLQ-zwPD846WRwKJTiSGFVO0mHFmRqgsCHHfGY=.b02704e9-f99b-4ffe-be32-ae7250583309@github.com>
References: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
 <NMwYVXLQ-zwPD846WRwKJTiSGFVO0mHFmRqgsCHHfGY=.b02704e9-f99b-4ffe-be32-ae7250583309@github.com>
Message-ID: <rkyIbPzJJ4YQ4O7ORSvUN_TQOVVLL8heth-WK4BM7S0=.c0f64928-ca3f-41b4-9ab1-0f9bcf0d65c2@github.com>

On Fri, 31 Oct 2025 11:50:14 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context.
>> 
>> Test: tier1-5
>
> src/hotspot/share/gc/parallel/psParallelCompact.cpp line 1383:
> 
>> 1381:     _weak_proc_task(nworkers),
>> 1382:     _nworkers(nworkers),
>> 1383:     _code_cache_claimed(false) {
> 
> Looks weird that we're not calling the constructor for `_oop_storage_iter`, but it's fine since it only has a default-ctor anyway. Up to you if we add it.

We should explicitly spell them out when we go over and adjust old code. We have been doing that for ZGC code, but it would be good to fix this in other GCs as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27822#discussion_r2481225615

From ayang at openjdk.org  Fri Oct 31 12:46:47 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 31 Oct 2025 12:46:47 GMT
Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask [v2]
In-Reply-To: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
References: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
Message-ID: <UU_v8xOovAyspSB1zgYRDRlLoXS0m_yCpIxYsdpWjog=.ad9ffc52-af65-4f2e-a5c1-05b02c034c7f@github.com>

> Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context.
> 
> 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 pgc-adjust-root
 - pgc-adjust-root

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27822/files
  - new: https://git.openjdk.org/jdk/pull/27822/files/eb0754eb..f5e73b4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27822&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27822&range=00-01

  Stats: 70278 lines in 1058 files changed: 38106 ins; 25697 del; 6475 mod
  Patch: https://git.openjdk.org/jdk/pull/27822.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27822/head:pull/27822

PR: https://git.openjdk.org/jdk/pull/27822

From ayang at openjdk.org  Fri Oct 31 13:33:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 31 Oct 2025 13:33:07 GMT
Subject: RFR: 8370943: Support heap expansion during startup in Serial and
 Parallel
In-Reply-To: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
References: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
Message-ID: <9ZqgrkpxjzqPEL_rfARty_UHDeUE3T6Hu2n12OgAPHA=.542d4cbc-8fb8-41d4-bc59-6f7a9e37c4f5@github.com>

On Thu, 30 Oct 2025 11:41:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add heap expansion logic in allocation slow-path during startup. Some asserts are relaxed to be used by java-threads and outside of safepoint.
> 
> Test: tier1-5

Thanks for review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28059#issuecomment-3473106521

From ayang at openjdk.org  Fri Oct 31 13:36:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 31 Oct 2025 13:36:13 GMT
Subject: Integrated: 8370943: Support heap expansion during startup in Serial
 and Parallel
In-Reply-To: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
References: <Bcg_XshdRkZlLiIHxMEIPuvJI_2qSdLF2RBbMar1pOY=.20b74fc5-563b-41b6-ae32-c8f3bdeec0e3@github.com>
Message-ID: <n9O2Zi0TnXpG01LKgrJi0MDVLn00JGBWaeBzagtuOLE=.65fd743d-cbcc-4e50-a81e-82454bc8c888@github.com>

On Thu, 30 Oct 2025 11:41:20 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Add heap expansion logic in allocation slow-path during startup. Some asserts are relaxed to be used by java-threads and outside of safepoint.
> 
> Test: tier1-5

This pull request has now been integrated.

Changeset: 67a81c47
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67a81c476f1e3c0d6aeca0d0aa2148efcb70a180
Stats:     26 lines in 4 files changed: 20 ins; 2 del; 4 mod

8370943: Support heap expansion during startup in Serial and Parallel

Reviewed-by: fandreuzzi, eosterlund, tschatzl

-------------

PR: https://git.openjdk.org/jdk/pull/28059

From jsikstro at openjdk.org  Fri Oct 31 14:33:05 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 31 Oct 2025 14:33:05 GMT
Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask [v2]
In-Reply-To: <UU_v8xOovAyspSB1zgYRDRlLoXS0m_yCpIxYsdpWjog=.ad9ffc52-af65-4f2e-a5c1-05b02c034c7f@github.com>
References: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
 <UU_v8xOovAyspSB1zgYRDRlLoXS0m_yCpIxYsdpWjog=.ad9ffc52-af65-4f2e-a5c1-05b02c034c7f@github.com>
Message-ID: <f0i4rzMoadUkeUxxH8bvCFIniHZ0TE4Z1PXw8qKyl20=.4a53605c-003e-42b7-bdfe-74edd886833c@github.com>

On Fri, 31 Oct 2025 12:46:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context.
>> 
>> 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 pgc-adjust-root
>  - pgc-adjust-root

Marked as reviewed by jsikstro (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27822#pullrequestreview-3404576736

From fandreuzzi at openjdk.org  Fri Oct 31 14:43:27 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Fri, 31 Oct 2025 14:43:27 GMT
Subject: RFR: 8369913: Parallel: Refactor PSAdjustTask [v2]
In-Reply-To: <UU_v8xOovAyspSB1zgYRDRlLoXS0m_yCpIxYsdpWjog=.ad9ffc52-af65-4f2e-a5c1-05b02c034c7f@github.com>
References: <ZbgrGTRTL03yZOguhBW9YynJBahM8Q-UPbQDd3Lhpqw=.f065229b-9a58-4679-974a-a0a673b773de@github.com>
 <UU_v8xOovAyspSB1zgYRDRlLoXS0m_yCpIxYsdpWjog=.ad9ffc52-af65-4f2e-a5c1-05b02c034c7f@github.com>
Message-ID: <BErebFdtpdGU_7__z1Gdkx6thtiz5gwnR2Gwokdh_D8=.00e4ea5a-06ab-41f1-bea1-f0fdcbd1841f@github.com>

On Fri, 31 Oct 2025 12:46:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Cleanup roots processing (adjusting/remapping) during the adjust-phase of full-gc, so that relevant roots are grouped together with some documentations. Also, the use of `SubTasksDone` is replaced with a `volatile bool`, which is more transparent in the context.
>> 
>> 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 pgc-adjust-root
>  - pgc-adjust-root

Marked as reviewed by fandreuzzi (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27822#pullrequestreview-3404616818

From xpeng at openjdk.org  Fri Oct 31 15:31:23 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 31 Oct 2025 15:31:23 GMT
Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save
 unnecessary region iteration
In-Reply-To: <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com>
References: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
 <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com>
Message-ID: <v_PT8cpuU09I4VqF1UrKa4UCiQW9M--JDwz5vhp5xd4=.7bfd96c6-e67e-4a78-9ee5-dc409b0863ec@github.com>

On Fri, 31 Oct 2025 01:10:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice:
>> 1. fast path: traverse regions between left most and right most in the partition,  and try to allocate in an affiliated region in the partition;  
>> 2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region.
>> 
>> 2 can be saved if we also remember the first FREE region seem in 1.
>> 
>> The PR makes the code much cleaner, and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference) 
>> 
>> 
>> Test:
>> - [x] hotspot_gc_shenandoah
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 901:
> 
>> 899:   }
>> 900: 
>> 901:   bool allow_new_region = can_allocate_in_new_region(req);
> 
> Are we losing the check here? Before this change, the region had to be `FREE` _and_ the generation affiliated with the request had to have `free_unaffiliated_regions`.

I was confused about this part, if we can find a FREE region in the partition, why we still need to test if the generation must have free_unaffiliated_regions, I can add can_allocate_in_new_region back to retain the original behavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2481808233

From iwalulya at openjdk.org  Fri Oct 31 15:32:31 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 31 Oct 2025 15:32:31 GMT
Subject: RFR: 8369111: G1: Determining concurrent start uses inconsistent
 predicates
In-Reply-To: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
References: <to9MC13cuXiXQgPYjiWHeDCr4msjt0D7zNxSF6I2TYI=.d87d9938-851c-45f5-8948-5496d44c6c7a@github.com>
Message-ID: <Kk4ar-9QAe5Fl5bV7nyi-XiEt3cut28rKXfs8hxtFtg=.57cf377f-c49d-425b-9025-9933dad0af87@github.com>

On Tue, 14 Oct 2025 08:58:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that fixes an inconsistency between requesting a concurrent start garbage collection during humongous object allocation and then actually starting it.
> 
> I.e. in `G1CollectedHeap::attempt_allocation_humongous` we check whether the allocation would cross the IHOP threshold taking the current allocation into account, and if so, see if G1 should start a concurrent marking, eventually starting a GC pause.
> 
> That GC pause did not take the prospective allocation into account, so we could do that GC for nothing (i.e. not start a concurrent marking although we already knew that the allocation would cause one).
> 
> This, in conjunction with JDK-8368959 can cause hundreds of extra GCs for the test in the CR (without eager reclaim of humongous arrays with references); otherwise it could cause the marking starting too late.
> 
> There is a second bug in the calculation whether G1 crossed the threshold: for humongous objects it only takes the actual size into account, not the size that is needed for allocating it. The same issue existed for determining to start a concurrent mark after any other collection too.
> 
> The change also tries to unify naming of the parameter to pass the allocation size (`alloc_word_size` -> `allocation_word_size`) and the parameter order where this size is passed along in multiple related methods.
> 
> Testing: mentioned test case now behaving correctly, tier1-5
> 
> Thanks,
>   Thomas

LGTM!

Nit:

src/hotspot/share/gc/g1/g1VMOperations.cpp line 56:

> 54:                              _gc_cause == GCCause::_wb_full_gc;
> 55:   g1h->do_full_collection(size_t(0) /* allocation_word_size */,
> 56:                           clear_all_soft_refs /* clear_all_soft_refs */,

don't see the value added by the comment for the named variable `clear_all_soft_refs`

-------------

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27789#pullrequestreview-3404793199
PR Review Comment: https://git.openjdk.org/jdk/pull/27789#discussion_r2481785749

From xpeng at openjdk.org  Fri Oct 31 15:36:54 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 31 Oct 2025 15:36:54 GMT
Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save
 unnecessary region iteration
In-Reply-To: <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com>
References: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
 <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com>
Message-ID: <sfMFR_hBfBiPmyOB-L49YH5mj3utM1q288G735Jlrqc=.9cc25fc7-b79b-4111-869a-0fe9591c9e63@github.com>

On Fri, 31 Oct 2025 01:12:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice:
>> 1. fast path: traverse regions between left most and right most in the partition,  and try to allocate in an affiliated region in the partition;  
>> 2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region.
>> 
>> 2 can be saved if we also remember the first FREE region seem in 1.
>> 
>> The PR makes the code much cleaner, and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference) 
>> 
>> 
>> Test:
>> - [x] hotspot_gc_shenandoah
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 779:
> 
>> 777:         return result;
>> 778:       }
>> 779:     } else if (free_region == nullptr && r->affiliation() == FREE &&
> 
> The logic in `can_allocate_from` is slightly different from what's here. Do we want to check that the region is `FREE` _or_ it is `trash` and we are not in concurrent weak roots?

`try_allocate_in(free_region, req, in_new_region)` returns nullptr if the region is trash and we are in in concurrent weak roots, I added the additional check to ensure try_allocate_in always succeed. The check may not be needed, I remember a FREE region can't be trash, I updated the trash/recycle related code in a while ago, I will double check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2481827416

From iwalulya at openjdk.org  Fri Oct 31 15:38:52 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 31 Oct 2025 15:38:52 GMT
Subject: RFR: 8370345: Parallel: Rework TLAB accounting in MutableNUMASpace
 [v3]
In-Reply-To: <JZlXmvc79AxZNq-kTpOFOcxq0htENPn6eTG1DJ3a0xU=.d9195708-6f44-44ca-9209-351d822c5909@github.com>
References: <TNZyPyGNiyjoB7XCGApD-9MKaVcZGQfsV3eyax5_5FY=.3d666c74-1b9b-4a95-bc92-d1c5493ba22a@github.com>
 <JZlXmvc79AxZNq-kTpOFOcxq0htENPn6eTG1DJ3a0xU=.d9195708-6f44-44ca-9209-351d822c5909@github.com>
Message-ID: <MV3iP_xdOIU52CwY07tA-teQvvv70Pyrc5YJRrac6Ig=.ccfae342-04ad-4db0-9711-e64478e4f7bb@github.com>

On Mon, 27 Oct 2025 11:36:29 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> Parallel's MutableNUMASpace is the only GC interface that uses the Thread parameter passed through the general CollectedHeap interface to tlab_capacity, tlab_used, and unsafe_max_tlab_alloc. It would be nice if Parallel's MutableNUMASpace could do without the Thread and instead find a thread-agnostic approach. By removing the need for the thread, it becomes possible to clean up the shared CollectedHeap interface, which makes it easier to read and maintain all GCs. Also, the lgrp_id that is stored in the Thread class should really have been moved to GCThreadLocalData after that concept was created, but with a thread-agnostic approach, the field can be removed entirely.
>> 
>> The current solution is not without problems. When a new allocation is made inside one of the LGRP spaces in MutableNUMASpace using cas_allocate(), the NUMA/LGRP id is polled and stored inside the Thread, and we only attempt to allocate on that LGRP. If allocation fails on the local LGRP, we do not try to allocate on any other (remote) LGRP(s). This fact is reflected in the TLAB accounting methods tlab_capacity, tlab_used, and unsafe_max_tlab_alloc, which only check how much memory is used, etc., for the LGRP matching the stored LGRP id in the Thread. This model breaks down when threads are allowed to migrate between different CPUs, and therefore also NUMA nodes, which might change the LGRP id.
>> 
>> For example, a system with two NUMA nodes gives us two LGRPs with ids 0 and 1. If a thread allocates most of its memory on LGRP 0 and then migrates to a CPU on LGRP 1, the thread will show that it allocated a significant amount of memory, but the used memory on the LGRP it is currently on could be very low. This would give a disproportionate allocation fraction. This is not a problem as the TLAB code accounts for this, but for a different reason entirely. The other way around could also be problematic. If a thread allocates very little memory on LGRP 0 and then migrates to LGRP 1, where another thread has allocated a lot of memory, the allocation fraction will be very low, when it could have a really high fraction if accounting for the used memory on its original LGRP.
>> 
>> A solution to both of these issues is to average the capacity, used, and available memory across all LGRPs for the TLAB accounting methods. This approach provides a more accurate and stable view of memory usage and availability, regardless of thread migration or imbalances in NUMA/LGRP allocation. However, th...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment on unsafe_max_tlab_alloc alignment

Marked as reviewed by iwalulya (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27935#pullrequestreview-3404864371

From iwalulya at openjdk.org  Fri Oct 31 16:53:21 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 31 Oct 2025 16:53:21 GMT
Subject: RFR: 8371018: Remove unused CollectedHeap::fill_with_object
In-Reply-To: <IWyl45Dt3kYPkHNJW0eshfZ8TxwFhBXoeHDzBP8xLHs=.c8fcf107-3db4-47c8-abae-50189232e561@github.com>
References: <IWyl45Dt3kYPkHNJW0eshfZ8TxwFhBXoeHDzBP8xLHs=.c8fcf107-3db4-47c8-abae-50189232e561@github.com>
Message-ID: <A3Ff9agNZnRJWapoE3GlcQCl-AsEJmh1OecPNJNvXyA=.b0f12bb2-736a-4e4a-9f6c-31a806ec4184@github.com>

On Fri, 31 Oct 2025 09:31:39 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.
> 
> Test: GHA

Trivial!

-------------

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28082#pullrequestreview-3405206392

From sspitsyn at openjdk.org  Fri Oct 31 20:32:10 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 31 Oct 2025 20:32:10 GMT
Subject: RFR: 8370732: Use WhiteBox.getWhiteBox().fullGC() to provoking gc
 for nsk/jvmti tests [v9]
In-Reply-To: <hLdJkXUM20apkP_7lLNQPUME8kS8Drx1cPZZBvo5mVE=.37db32ec-3b52-481a-8ff9-467c30c8d675@github.com>
References: <ifXpBcHPhAiggQdBWReqe2qR61nA6VF6zdzeREtCmGk=.1a462b19-fefd-43ee-b3a2-cbfd65af2d79@github.com>
 <hLdJkXUM20apkP_7lLNQPUME8kS8Drx1cPZZBvo5mVE=.37db32ec-3b52-481a-8ff9-467c30c8d675@github.com>
Message-ID: <CtJ1lf6KZHRdHdrMgkZU8HbbNV4IhFEyA7ScuXB7HG4=.7cc2c22d-9e84-4bbb-a976-9a09f2beef35@github.com>

On Fri, 31 Oct 2025 03:04:48 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR use `WhiteBox.getWhiteBox().fullGC()` instead of 'ClassUnloader.eatMemory()' to provoking gc for several test/hotspot/jtreg/vmTestbase/nsk/jvmti tests, It is the fast and robust way to trigger Full GC without risks hitting OOME, and will make test run finish more quicker on machine with huge physical memory.
>> 
>> Change has been verified locally, test-fix only, no risk.
>> 
>> 
>> grep VmRSS /proc/`ps -ef | grep -w java | grep vmsqe.aod.AppId | awk '{print $2}'`/status
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add log.display("Provoking GC");

Nice cleanup.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28011#pullrequestreview-3406021337

From wkemper at openjdk.org  Fri Oct 31 20:38:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 31 Oct 2025 20:38:13 GMT
Subject: RFR: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet [v35]
In-Reply-To: <UF20F354ZRHxN8MAuTjfs5fsqwV_viDwjptkrC6DSIo=.48b710da-aec0-45ed-8de4-a07fd960b346@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
 <UF20F354ZRHxN8MAuTjfs5fsqwV_viDwjptkrC6DSIo=.48b710da-aec0-45ed-8de4-a07fd960b346@github.com>
Message-ID: <TasDOZzAoCfIeA-1UHdm6aXInDPAH-iusNeM4kCOnYA=.05c74fa5-9b14-4056-94c1-879c07556610@github.com>

On Fri, 31 Oct 2025 01:09:32 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 with a new target base due to a merge or a rebase. The pull request now contains 157 commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
>  - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
>  - reviewer feedback
>  - Merge remote-tracking branch 'jdk/master' into freeset-has-authoritative-tallies
>  - Rework implementation of CompressedClassSpaceSizeInJmapHeap.java
>  - fix errors in CompressedClassSpaceSizeInJmapHeap.java
>  - Add debug instrumentation to CompressedClassSpaceSizeInJmapHeap.java
>  - Add sleep to CompressedClassSpaceSizeInJmapHeap.java test
>  - Fix up vmstructs and other infrastructure for jmap heap dump
>  - After initialization, check for SoftMaxHeapSize changed by constraints enforcement
>  - ... and 147 more: https://git.openjdk.org/jdk/compare/6347f10b...53af6b19

Marked as reviewed by wkemper (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/26867#pullrequestreview-3406038405

From xpeng at openjdk.org  Fri Oct 31 20:45:37 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 31 Oct 2025 20:45:37 GMT
Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save
 unnecessary region iteration [v2]
In-Reply-To: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
References: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
Message-ID: <i5Jc88uTHOhQdLpUTrqp8sGWbM3tXcQyb6q3sjEu1f4=.86a8a92d-221a-48e0-b58e-d8caf5860edb@github.com>

> To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice:
> 1. fast path: traverse regions between left most and right most in the partition,  and try to allocate in an affiliated region in the partition;  
> 2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region.
> 
> 2 can be saved if we also remember the first FREE region seem in 1.
> 
> The PR makes the code much cleaner, and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference) 
> 
> 
> Test:
> - [x] hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision:

 - Remove condition check for trash region
 - Address the PR review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28036/files
  - new: https://git.openjdk.org/jdk/pull/28036/files/81cd8ab0..2c73b9f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28036&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28036&range=00-01

  Stats: 31 lines in 2 files changed: 22 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28036.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28036/head:pull/28036

PR: https://git.openjdk.org/jdk/pull/28036

From wkemper at openjdk.org  Fri Oct 31 20:57:05 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 31 Oct 2025 20:57:05 GMT
Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save
 unnecessary region iteration [v2]
In-Reply-To: <v_PT8cpuU09I4VqF1UrKa4UCiQW9M--JDwz5vhp5xd4=.7bfd96c6-e67e-4a78-9ee5-dc409b0863ec@github.com>
References: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
 <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com>
 <v_PT8cpuU09I4VqF1UrKa4UCiQW9M--JDwz5vhp5xd4=.7bfd96c6-e67e-4a78-9ee5-dc409b0863ec@github.com>
Message-ID: <IaGAohsGfMN0Qj3U0ACMbVxBTcGLWlW287Cc7tasvCM=.7fdd5c35-f75a-4bc6-86a7-678a9ea3037c@github.com>

On Fri, 31 Oct 2025 15:29:05 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 901:
>> 
>>> 899:   }
>>> 900: 
>>> 901:   bool allow_new_region = can_allocate_in_new_region(req);
>> 
>> Are we losing the check here? Before this change, the region had to be `FREE` _and_ the generation affiliated with the request had to have `free_unaffiliated_regions`.
>
> I was confused about this part, if we can find a FREE region in the partition, why we still need to test if the generation must have free_unaffiliated_regions, I can add can_allocate_in_new_region back to retain the original behavior.

The young and old collector reserves both have `FREE` regions, but we need to make sure we don't exceed the reserves for one or the other.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2482658205

From xpeng at openjdk.org  Fri Oct 31 21:03:22 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 31 Oct 2025 21:03:22 GMT
Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save
 unnecessary region iteration [v2]
In-Reply-To: <IaGAohsGfMN0Qj3U0ACMbVxBTcGLWlW287Cc7tasvCM=.7fdd5c35-f75a-4bc6-86a7-678a9ea3037c@github.com>
References: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
 <7KjxoZ7UQ9LugnCVgBT6moBrQEfxmPNBXrvyWXD-MQ8=.37907346-c252-4daf-b7bb-9d0f89291753@github.com>
 <v_PT8cpuU09I4VqF1UrKa4UCiQW9M--JDwz5vhp5xd4=.7bfd96c6-e67e-4a78-9ee5-dc409b0863ec@github.com>
 <IaGAohsGfMN0Qj3U0ACMbVxBTcGLWlW287Cc7tasvCM=.7fdd5c35-f75a-4bc6-86a7-678a9ea3037c@github.com>
Message-ID: <GT0M7uQbpIrLl44HjXgX_HSCyzJfTkOg5Ia24tRhDBk=.f383da61-021a-4a90-bf60-d1bda921d764@github.com>

On Fri, 31 Oct 2025 20:54:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I was confused about this part, if we can find a FREE region in the partition, why we still need to test if the generation must have free_unaffiliated_regions, I can add can_allocate_in_new_region back to retain the original behavior.
>
> The young and old collector reserves both have `FREE` regions, but we need to make sure we don't exceed the reserves for one or the other.

I have added the can_allocate_in_new_region check back, it should have same behavior now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28036#discussion_r2482669646

From kdnilsen at openjdk.org  Fri Oct 31 21:05:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 31 Oct 2025 21:05:22 GMT
Subject: Integrated: 8365880: Shenandoah: Unify memory usage accounting in
 ShenandoahFreeSet
In-Reply-To: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
References: <PEf3EJ1un1L9hh5sGoKm1Q3EubQMCKimO8_tQJbMliU=.3ef99071-8eb6-41fc-8523-6af4f76421f0@github.com>
Message-ID: <RKGVMmVdJrugGTzaX7lG_fBNADt2hUlETqscB8I6K4c=.d67e9670-5d56-4819-b9e0-6ad4a8c22a2e@github.com>

On Wed, 20 Aug 2025 19:17:48 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.

This pull request has now been integrated.

Changeset: ec059c0e
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec059c0e85bc612f430269d9e110dc7ecbdce342
Stats:     3516 lines in 43 files changed: 2110 ins; 1006 del; 400 mod

8365880: Shenandoah: Unify memory usage accounting in ShenandoahFreeSet

Reviewed-by: wkemper

-------------

PR: https://git.openjdk.org/jdk/pull/26867

From xpeng at openjdk.org  Fri Oct 31 22:09:18 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 31 Oct 2025 22:09:18 GMT
Subject: RFR: 8370850: Shenandoah: Simplify collector allocation to save
 unnecessary region iteration [v3]
In-Reply-To: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
References: <l93OF9LbVlio6SM2p7TaCNUJUxFe8xp0aubrmCa4YOQ=.902c2a53-1409-43cd-ab88-f9ee3f3b9632@github.com>
Message-ID: <SpeN-wKsxBfkVwPaP9sJ_KXowtg2Datny42EPOVFa8s=.a4b48167-a5cc-4f40-a310-2793fa7f4ab0@github.com>

> To allocate an object in Collector/OldCollector partition, current implementation may traverse the regions in the partition twice:
> 1. fast path: traverse regions between left most and right most in the partition,  and try to allocate in an affiliated region in the partition;  
> 2. if fails in fast path, traverse regions between left most empty and right most empty in the partition, and try try to allocate in a FREE region.
> 
> 2 can be saved if we also remember the first FREE region seem in 1.
> 
> The PR makes the code much cleaner, and more efficient(although the performance impact may not be measurable, I have run some dacapo benchmarks and didn't see meaningful difference) 
> 
> 
> Test:
> - [x] hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Remove can_allocate_in_new_region
 - Merge remote-tracking branch 'origin/master' into collector-allocation
 - Remove condition check for trash region
 - Address the PR review comments
 - Merge branch 'openjdk:master' into collector-allocation
 - Touch up
 - Remove test 'req.is_old()' when steal an empty region from the mutator view
 - Update comment
 - Fix wrong condition when steal an empty region from the mutator view
 - Fix potential failure in young evac
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ec059c0e...8e01d691

-------------

Changes: https://git.openjdk.org/jdk/pull/28036/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28036&range=02
  Stats: 77 lines in 2 files changed: 18 ins; 45 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/28036.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28036/head:pull/28036

PR: https://git.openjdk.org/jdk/pull/28036