From gli at openjdk.org  Sun Jun  1 10:12:40 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 1 Jun 2025 10:12:40 GMT
Subject: RFR: 8357109: Parallel: Fix typo in YoungedGeneration [v2]
In-Reply-To: <s8v9po_XfEf038hw5WDUb--kqFIGdxdEI5ZZ9kLJx_0=.8e38a43f-e856-42c3-9a5f-b5b766ccd53e@github.com>
References: <s8v9po_XfEf038hw5WDUb--kqFIGdxdEI5ZZ9kLJx_0=.8e38a43f-e856-42c3-9a5f-b5b766ccd53e@github.com>
Message-ID: <3JZIyCzFMXfn_7g7FORSt1srEMcidEAs00cj9y2dwhY=.dd1109a4-ed4c-4528-a697-b78d6bf45b4f@github.com>

> Hi all,
> 
> This trivial patch fixes two typos. Thanks for your review.
> 
> Best Regards,
> -- Guoxiong

Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:

  Revise copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25436/files
  - new: https://git.openjdk.org/jdk/pull/25436/files/ff23136c..d603eb18

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

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

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

From gli at openjdk.org  Sun Jun  1 10:18:57 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 1 Jun 2025 10:18:57 GMT
Subject: RFR: 8357109: Parallel: Fix typo in YoungedGeneration [v2]
In-Reply-To: <jYRb6b9o-0aGDczb5P--gQ3VGyluzfUj-tX3FhDhPkY=.4255320f-dc09-45a8-8289-d18ab74d8f06@github.com>
References: <s8v9po_XfEf038hw5WDUb--kqFIGdxdEI5ZZ9kLJx_0=.8e38a43f-e856-42c3-9a5f-b5b766ccd53e@github.com>
 <QZfuAoNOI59Hi4hfaMwFj9E8kf8P-qCZtrL0AshQPxs=.a1744df8-03bf-4cd0-bb41-5f8fb16ada33@github.com>
 <jYRb6b9o-0aGDczb5P--gQ3VGyluzfUj-tX3FhDhPkY=.4255320f-dc09-45a8-8289-d18ab74d8f06@github.com>
Message-ID: <8hWiiTfSsLKoazXrNNTKIJwoqKdyCelZf1IQICC5ooQ=.48afd154-b570-4a0c-91d8-2c5f7e5f8fcf@github.com>

On Tue, 27 May 2025 08:16:46 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gc_globals.hpp line 365:
>> 
>>> 363:                                                                             \
>>> 364:   product(uint, YoungGenerationSizeSupplement, 80,                          \
>>> 365:           "Supplement to YoungedGenerationSizeIncrement used at startup")   \
>> 
>> Should we update the copyright year to 2025
>
> It's up to you.

Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25436#discussion_r2118990108

From ayang at openjdk.org  Mon Jun  2 07:03:54 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 2 Jun 2025 07:03:54 GMT
Subject: RFR: 8357109: Parallel: Fix typo in YoungedGeneration [v2]
In-Reply-To: <3JZIyCzFMXfn_7g7FORSt1srEMcidEAs00cj9y2dwhY=.dd1109a4-ed4c-4528-a697-b78d6bf45b4f@github.com>
References: <s8v9po_XfEf038hw5WDUb--kqFIGdxdEI5ZZ9kLJx_0=.8e38a43f-e856-42c3-9a5f-b5b766ccd53e@github.com>
 <3JZIyCzFMXfn_7g7FORSt1srEMcidEAs00cj9y2dwhY=.dd1109a4-ed4c-4528-a697-b78d6bf45b4f@github.com>
Message-ID: <HAx_qN-EN9LX-9T_NWQTdB2EorBIVbx3JWlWHevQhuY=.02c7fdc8-6ee0-4d52-bdf5-a644f94a4407@github.com>

On Sun, 1 Jun 2025 10:12:40 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This trivial patch fixes two typos. Thanks for your review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise copyright year

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25436#pullrequestreview-2887027150

From ayang at openjdk.org  Mon Jun  2 07:08:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 2 Jun 2025 07:08:50 GMT
Subject: RFR: 8334759: gc/g1/TestMixedGCLiveThreshold.java fails on Windows
 with JTREG_TEST_THREAD_FACTORY=Virtual due to extra memory allocation
In-Reply-To: <qtCaj7RmMG_VXZ2LvYnHIAxG5MYv1UAQM4gjlvlLpdA=.ce7771d5-b151-481e-8937-a3a5378fea16@github.com>
References: <qtCaj7RmMG_VXZ2LvYnHIAxG5MYv1UAQM4gjlvlLpdA=.ce7771d5-b151-481e-8937-a3a5378fea16@github.com>
Message-ID: <RUwDQ5M5cC1X4jeA6asxIFSlqBSvBO7O_1kxRqh0mew=.a9de29c6-2e0e-4dcf-892d-09b108c7c0f1@github.com>

On Wed, 28 May 2025 09:25:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that "fixes" the `TestMixedGCLiveThreshold.java` test by requiring the thread factory used for these tests to not use virtual threads instead of platform threads.
> 
> That adds some additional memory consumption, and since the test is about testing G1 reaction due to particular known memory consumption, it can fail.
> 
> The fix is to add the appropriate `@requires` tag that has been introduced in jtreg 7.5.1 (which is current default/requirement for builds, https://bugs.openjdk.org/browse/JDK-8334759).
> 
> Testing: verified that the test is not run if the virtual thread test thread factory is used.
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25486#pullrequestreview-2887040919

From tschatzl at openjdk.org  Mon Jun  2 07:41:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 2 Jun 2025 07:41:52 GMT
Subject: RFR: 8357944: Remove unused CollectedHeap::is_maximal_no_gc
In-Reply-To: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>
References: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>
Message-ID: <2QWPYqes70JwJ-5k9C91yuFeLb-aVFKClOgyovWLFwY=.8faa61a4-a9f5-4a75-83fb-2cde568d71a0@github.com>

On Wed, 28 May 2025 07:17:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removing effectively dead code/API for all GCs except G1.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25482#pullrequestreview-2887146273

From iwalulya at openjdk.org  Mon Jun  2 08:02:01 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 2 Jun 2025 08:02:01 GMT
Subject: RFR: 8334759: gc/g1/TestMixedGCLiveThreshold.java fails on Windows
 with JTREG_TEST_THREAD_FACTORY=Virtual due to extra memory allocation
In-Reply-To: <qtCaj7RmMG_VXZ2LvYnHIAxG5MYv1UAQM4gjlvlLpdA=.ce7771d5-b151-481e-8937-a3a5378fea16@github.com>
References: <qtCaj7RmMG_VXZ2LvYnHIAxG5MYv1UAQM4gjlvlLpdA=.ce7771d5-b151-481e-8937-a3a5378fea16@github.com>
Message-ID: <kQvKlId8vmmbDPpKg_zSOFVaL2VQPBHxC8yLi3rP01o=.9b8e0531-91d3-4e89-8946-899bea7d5ad9@github.com>

On Wed, 28 May 2025 09:25:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that "fixes" the `TestMixedGCLiveThreshold.java` test by requiring the thread factory used for these tests to not use virtual threads instead of platform threads.
> 
> That adds some additional memory consumption, and since the test is about testing G1 reaction due to particular known memory consumption, it can fail.
> 
> The fix is to add the appropriate `@requires` tag that has been introduced in jtreg 7.5.1 (which is current default/requirement for builds, https://bugs.openjdk.org/browse/JDK-8334759).
> 
> Testing: verified that the test is not run if the virtual thread test thread factory is used.
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25486#pullrequestreview-2887203907

From tschatzl at openjdk.org  Mon Jun  2 08:02:02 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 2 Jun 2025 08:02:02 GMT
Subject: RFR: 8334759: gc/g1/TestMixedGCLiveThreshold.java fails on Windows
 with JTREG_TEST_THREAD_FACTORY=Virtual due to extra memory allocation
In-Reply-To: <RUwDQ5M5cC1X4jeA6asxIFSlqBSvBO7O_1kxRqh0mew=.a9de29c6-2e0e-4dcf-892d-09b108c7c0f1@github.com>
References: <qtCaj7RmMG_VXZ2LvYnHIAxG5MYv1UAQM4gjlvlLpdA=.ce7771d5-b151-481e-8937-a3a5378fea16@github.com>
 <RUwDQ5M5cC1X4jeA6asxIFSlqBSvBO7O_1kxRqh0mew=.a9de29c6-2e0e-4dcf-892d-09b108c7c0f1@github.com>
Message-ID: <rW8229AhsJuv2onTQ6mMrbsyW8K0_S3SGqs3DsyHmM0=.d8cb6224-22d9-4e4d-a795-2eb716f0c4a7@github.com>

On Mon, 2 Jun 2025 07:06:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that "fixes" the `TestMixedGCLiveThreshold.java` test by requiring the thread factory used for these tests to not use virtual threads instead of platform threads.
>> 
>> That adds some additional memory consumption, and since the test is about testing G1 reaction due to particular known memory consumption, it can fail.
>> 
>> The fix is to add the appropriate `@requires` tag that has been introduced in jtreg 7.5.1 (which is current default/requirement for builds, https://bugs.openjdk.org/browse/JDK-8334759).
>> 
>> Testing: verified that the test is not run if the virtual thread test thread factory is used.
>> 
>> Thanks,
>>   Thomas
>
> Marked as reviewed by ayang (Reviewer).

Thanks @albertnetymk @walulyai for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/25486#issuecomment-2929300941

From tschatzl at openjdk.org  Mon Jun  2 08:02:02 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 2 Jun 2025 08:02:02 GMT
Subject: Integrated: 8334759: gc/g1/TestMixedGCLiveThreshold.java fails on
 Windows with JTREG_TEST_THREAD_FACTORY=Virtual due to extra memory allocation
In-Reply-To: <qtCaj7RmMG_VXZ2LvYnHIAxG5MYv1UAQM4gjlvlLpdA=.ce7771d5-b151-481e-8937-a3a5378fea16@github.com>
References: <qtCaj7RmMG_VXZ2LvYnHIAxG5MYv1UAQM4gjlvlLpdA=.ce7771d5-b151-481e-8937-a3a5378fea16@github.com>
Message-ID: <uqnpXUTOFLA83x6VG5BIwi8gBMsG3Km75Z6tZQN4V18=.6f592ce9-b414-4ac6-91c7-52d6781c394e@github.com>

On Wed, 28 May 2025 09:25:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that "fixes" the `TestMixedGCLiveThreshold.java` test by requiring the thread factory used for these tests to not use virtual threads instead of platform threads.
> 
> That adds some additional memory consumption, and since the test is about testing G1 reaction due to particular known memory consumption, it can fail.
> 
> The fix is to add the appropriate `@requires` tag that has been introduced in jtreg 7.5.1 (which is current default/requirement for builds, https://bugs.openjdk.org/browse/JDK-8334759).
> 
> Testing: verified that the test is not run if the virtual thread test thread factory is used.
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 3f59bfd2
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3f59bfd2e1b35e10fe736e2fa6886cff74ecd35d
Stats:     8 lines in 2 files changed: 3 ins; 5 del; 0 mod

8334759: gc/g1/TestMixedGCLiveThreshold.java fails on Windows with JTREG_TEST_THREAD_FACTORY=Virtual due to extra memory allocation

Reviewed-by: ayang, iwalulya

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

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

From eosterlund at openjdk.org  Mon Jun  2 08:25:06 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 08:25:06 GMT
Subject: RFR: 8357954: G1: No SATB barriers applied for runtime IN_NATIVE
 atomics
Message-ID: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>

OopHandle has had atomic xchg/cmpxchg operations added to it. Yet, the G1 access API backend doesn't really support that; there is no SATB barrier.

Fortunately the only use of OopHandle::xchg so far is appending to the pending list, which didn't need SATB barriers because young generation reference processing only adds young objects that the old gen doesn't care much about, and the old gen reference processor doesn't care about its own References that it publishes, because it's done after marking.

And fortunately the only use of OopHandle::cmpxchg so far is manipulating a lock-free list of virtual threads to unblock in JVM_TakeVirtualThreadListToUnblock. Since the virtual threads are blocked, they are externally kept alive.

But it's starting to feel quite scary, so let's be proactive and add the support to G1 before something inevitably blows up. This patch adds the missing SATB keep-alive code for G1 IN_NATIVE oop atomics.

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

Commit messages:
 - 8357954: G1: No SATB barriers applied for runtime IN_NATIVE atomics

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

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

From ayang at openjdk.org  Mon Jun  2 08:28:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 2 Jun 2025 08:28:04 GMT
Subject: RFR: 8357944: Remove unused CollectedHeap::is_maximal_no_gc
In-Reply-To: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>
References: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>
Message-ID: <zbUFbZsduQ2QjjQWednY0GdE4qDDn4pjWo-Q59pWmFc=.0bfa503d-8bdb-467f-925a-8558dc6c2f08@github.com>

On Wed, 28 May 2025 07:17:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removing effectively dead code/API for all GCs except G1.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25482#issuecomment-2929388616

From ayang at openjdk.org  Mon Jun  2 08:28:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 2 Jun 2025 08:28:04 GMT
Subject: Integrated: 8357944: Remove unused CollectedHeap::is_maximal_no_gc
In-Reply-To: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>
References: <hsK4SlLg6hpAsW06ZvUlke7CsgbpSsGpYNL6uyI4YGc=.68fe5690-b1d4-457d-8ab1-faffd90edba2@github.com>
Message-ID: <wRCS8nUGfPm4tf4IrJfcSzkIhlDn4Kd_Jgi6QtI10ss=.b9597b49-c30f-4418-a048-44a7abb2bb1c@github.com>

On Wed, 28 May 2025 07:17:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Removing effectively dead code/API for all GCs except G1.

This pull request has now been integrated.

Changeset: 64183062
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6418306211be47063a9b06bad8003dee1d81570c
Stats:     51 lines in 12 files changed: 0 ins; 50 del; 1 mod

8357944: Remove unused CollectedHeap::is_maximal_no_gc

Reviewed-by: jsikstro, tschatzl

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

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

From shade at openjdk.org  Mon Jun  2 08:43:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Jun 2025 08:43:54 GMT
Subject: RFR: 8357954: G1: No SATB barriers applied for runtime IN_NATIVE
 atomics
In-Reply-To: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
References: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
Message-ID: <8ZSEttcbi1yB9e6SWiwWt4yvA3d5gIgGyXK7QRRBUhA=.52d4158c-186a-4716-8f3b-b98af205160d@github.com>

On Mon, 2 Jun 2025 08:19:48 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> OopHandle has had atomic xchg/cmpxchg operations added to it. Yet, the G1 access API backend doesn't really support that; there is no SATB barrier.
> 
> Fortunately the only use of OopHandle::xchg so far is appending to the pending list, which didn't need SATB barriers because young generation reference processing only adds young objects that the old gen doesn't care much about, and the old gen reference processor doesn't care about its own References that it publishes, because it's done after marking.
> 
> And fortunately the only use of OopHandle::cmpxchg so far is manipulating a lock-free list of virtual threads to unblock in JVM_TakeVirtualThreadListToUnblock. Since the virtual threads are blocked, they are externally kept alive.
> 
> But it's starting to feel quite scary, so let's be proactive and add the support to G1 before something inevitably blows up. This patch adds the missing SATB keep-alive code for G1 IN_NATIVE oop atomics.

Looks reasonable. AFAICS, only G1 has this gap, and both Shenandoah and Z already hook this up in their respective barrier sets. Correct?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25576#pullrequestreview-2887356715

From gli at openjdk.org  Mon Jun  2 08:49:57 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 2 Jun 2025 08:49:57 GMT
Subject: RFR: 8357109: Parallel: Fix typo in YoungedGeneration [v2]
In-Reply-To: <3JZIyCzFMXfn_7g7FORSt1srEMcidEAs00cj9y2dwhY=.dd1109a4-ed4c-4528-a697-b78d6bf45b4f@github.com>
References: <s8v9po_XfEf038hw5WDUb--kqFIGdxdEI5ZZ9kLJx_0=.8e38a43f-e856-42c3-9a5f-b5b766ccd53e@github.com>
 <3JZIyCzFMXfn_7g7FORSt1srEMcidEAs00cj9y2dwhY=.dd1109a4-ed4c-4528-a697-b78d6bf45b4f@github.com>
Message-ID: <CoGlmv7FGKr0eXdYQi17Xh2bgiwm4leMMsDBEDEYV8U=.419b7d36-3ce2-4541-87eb-7588778fb41c@github.com>

On Sun, 1 Jun 2025 10:12:40 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> This trivial patch fixes two typos. Thanks for your review.
>> 
>> Best Regards,
>> -- Guoxiong
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revise copyright year

Thanks for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25436#issuecomment-2929490665

From gli at openjdk.org  Mon Jun  2 08:49:57 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Mon, 2 Jun 2025 08:49:57 GMT
Subject: Integrated: 8357109: Parallel: Fix typo in YoungedGeneration
In-Reply-To: <s8v9po_XfEf038hw5WDUb--kqFIGdxdEI5ZZ9kLJx_0=.8e38a43f-e856-42c3-9a5f-b5b766ccd53e@github.com>
References: <s8v9po_XfEf038hw5WDUb--kqFIGdxdEI5ZZ9kLJx_0=.8e38a43f-e856-42c3-9a5f-b5b766ccd53e@github.com>
Message-ID: <PAuTRM__QGse7bq6P5zPIi3sLMGyrGmqPL9ZqU4BlIM=.1baeaabb-87cf-4caf-8d5b-4b596355d8f4@github.com>

On Sun, 25 May 2025 09:02:03 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> This trivial patch fixes two typos. Thanks for your review.
> 
> Best Regards,
> -- Guoxiong

This pull request has now been integrated.

Changeset: a9e7a74d
Author:    Guoxiong Li <gli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a9e7a74d00fe1c8d3179392738bb15d8e3508b3a
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8357109: Parallel: Fix typo in YoungedGeneration

Reviewed-by: ayang, zgu, tschatzl

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

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

From kbarrett at openjdk.org  Mon Jun  2 09:11:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 2 Jun 2025 09:11:55 GMT
Subject: RFR: 8357954: G1: No SATB barriers applied for runtime IN_NATIVE
 atomics
In-Reply-To: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
References: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
Message-ID: <PsixrwJoLagfzNfAR2N6h69eU8sgLo0A3I9XkSNQ4fo=.2c808bd9-7a9a-4963-9770-9672ac6ba1c5@github.com>

On Mon, 2 Jun 2025 08:19:48 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> OopHandle has had atomic xchg/cmpxchg operations added to it. Yet, the G1 access API backend doesn't really support that; there is no SATB barrier.
> 
> Fortunately the only use of OopHandle::xchg so far is appending to the pending list, which didn't need SATB barriers because young generation reference processing only adds young objects that the old gen doesn't care much about, and the old gen reference processor doesn't care about its own References that it publishes, because it's done after marking.
> 
> And fortunately the only use of OopHandle::cmpxchg so far is manipulating a lock-free list of virtual threads to unblock in JVM_TakeVirtualThreadListToUnblock. Since the virtual threads are blocked, they are externally kept alive.
> 
> But it's starting to feel quite scary, so let's be proactive and add the support to G1 before something inevitably blows up. This patch adds the missing SATB keep-alive code for G1 IN_NATIVE oop atomics.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25576#pullrequestreview-2887452053

From ayang at openjdk.org  Mon Jun  2 09:39:25 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 2 Jun 2025 09:39:25 GMT
Subject: RFR: 8358313: G1: Refactor G1CollectedHeap::is_maximal_no_gc
Message-ID: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>

Simple changing of a method name and return-type to be more consistent with the surrounding code.

Test: tier1

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

Commit messages:
 - g1-rename

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

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

From jsikstro at openjdk.org  Mon Jun  2 09:43:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 2 Jun 2025 09:43:03 GMT
Subject: RFR: 8356880: Backoff in ZLiveMap::reset spin-loop
Message-ID: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>

Hello,

This RFE addresses contention in ZLiveMap::reset caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167). The contention is noticeable on (Linux) aarch64, where the Atomic::load_acquire in the spin-loop is slower than on other platforms.

To reduce spinning, and in turn the number of calls to Atomic::load_acquire, I suggest we introduce a backoff via a SpinYield to allow some time for the thread responsible for resetting to finish. The SpinYield always sleeps for 1?s, which should be enough time for an average malloc call to finish. The requirement for low latency is not as strict when it's only GC threads waiting for each other, and the livemap is only allocated once per page, so always sleeping should be reasonable.

The regression caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167) was observed on SPECjvm2008-LU.small on linux-aarch64. The performance is noticeably better on linux-aarch64 when applying the patch to jdk-25+15 (which included [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167)). However, the performance is neutral when applying the patch to mainline now. With this in mind I think we still want to address the contention this way.

* Currently running through tier 1-4

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

Commit messages:
 - 8356880: Backoff in ZLiveMap::reset spin-loop

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

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

From jsikstro at openjdk.org  Mon Jun  2 09:45:50 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 2 Jun 2025 09:45:50 GMT
Subject: RFR: 8358313: G1: Refactor G1CollectedHeap::is_maximal_no_gc
In-Reply-To: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>
References: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>
Message-ID: <xNzrxN8A6-V1naQFKC7iJq3tyy6_PSpV3Vj8bAySa1k=.3ca1f5c2-d5f6-4e31-a33c-4239de2ff870@github.com>

On Mon, 2 Jun 2025 09:33:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple changing of a method name and return-type to be more consistent with the surrounding code.
> 
> Test: tier1

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1034:

> 1032: 
> 1033:   if (expanded_by == 0) {
> 1034:     assert(num_inactive_regions() == 0, "Should be no regions left, available: %u", _hrm.num_inactive_regions());

Maybe?

Suggestion:

    assert(num_inactive_regions() == 0, "Should be no regions left, available: %u", num_inactive_regions());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25579#discussion_r2120604646

From ayang at openjdk.org  Mon Jun  2 09:56:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 2 Jun 2025 09:56:06 GMT
Subject: RFR: 8358313: G1: Refactor G1CollectedHeap::is_maximal_no_gc [v2]
In-Reply-To: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>
References: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>
Message-ID: <MZR7s_V3YrlvdFBUTF2QGo-koVwr3g_Z5xG4kLkIeiU=.e5220b8c-6ff2-47bd-9104-c752312437ab@github.com>

> Simple changing of a method name and return-type to be more consistent with the surrounding code.
> 
> Test: tier1

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

  Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
  
  Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25579/files
  - new: https://git.openjdk.org/jdk/pull/25579/files/ed245efe..68367e1b

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

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

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

From jsikstro at openjdk.org  Mon Jun  2 09:56:06 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 2 Jun 2025 09:56:06 GMT
Subject: RFR: 8358313: G1: Refactor G1CollectedHeap::is_maximal_no_gc [v2]
In-Reply-To: <MZR7s_V3YrlvdFBUTF2QGo-koVwr3g_Z5xG4kLkIeiU=.e5220b8c-6ff2-47bd-9104-c752312437ab@github.com>
References: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>
 <MZR7s_V3YrlvdFBUTF2QGo-koVwr3g_Z5xG4kLkIeiU=.e5220b8c-6ff2-47bd-9104-c752312437ab@github.com>
Message-ID: <d88UTZ_QSRjcLXG4YhniwzG7u2Vh-sQKyWqY6gpGyK8=.08216cb4-1d0e-46e8-a49f-be82bbc2ce75@github.com>

On Mon, 2 Jun 2025 09:53:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple changing of a method name and return-type to be more consistent with the surrounding code.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

Marked as reviewed by jsikstro (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25579#pullrequestreview-2887606907

From tschatzl at openjdk.org  Mon Jun  2 09:56:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 2 Jun 2025 09:56:53 GMT
Subject: RFR: 8357954: G1: No SATB barriers applied for runtime IN_NATIVE
 atomics
In-Reply-To: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
References: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
Message-ID: <ywHVdlzwPI7tp6Gx5Vc7TGTrHvLfx7WiC_9yAoEw4e0=.0374a4b6-29ea-4c98-ad9a-14d5458a6661@github.com>

On Mon, 2 Jun 2025 08:19:48 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> OopHandle has had atomic xchg/cmpxchg operations added to it. Yet, the G1 access API backend doesn't really support that; there is no SATB barrier.
> 
> Fortunately the only use of OopHandle::xchg so far is appending to the pending list, which didn't need SATB barriers because young generation reference processing only adds young objects that the old gen doesn't care much about, and the old gen reference processor doesn't care about its own References that it publishes, because it's done after marking.
> 
> And fortunately the only use of OopHandle::cmpxchg so far is manipulating a lock-free list of virtual threads to unblock in JVM_TakeVirtualThreadListToUnblock. Since the virtual threads are blocked, they are externally kept alive.
> 
> But it's starting to feel quite scary, so let's be proactive and add the support to G1 before something inevitably blows up. This patch adds the missing SATB keep-alive code for G1 IN_NATIVE oop atomics.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25576#pullrequestreview-2887612023

From stefank at openjdk.org  Mon Jun  2 10:04:50 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 2 Jun 2025 10:04:50 GMT
Subject: RFR: 8356880: Backoff in ZLiveMap::reset spin-loop
In-Reply-To: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
References: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
Message-ID: <csiEvENcxfsCfjcaH1XpWR9VV9D4tBxxcbla_lYqXjw=.02cb9a21-e658-455c-babb-012aedce8c30@github.com>

On Mon, 2 Jun 2025 09:39:15 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE addresses contention in ZLiveMap::reset caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167). The contention is noticeable on (Linux) aarch64, where the Atomic::load_acquire in the spin-loop is slower than on other platforms.
> 
> To reduce spinning, and in turn the number of calls to Atomic::load_acquire, I suggest we introduce a backoff via a SpinYield to allow some time for the thread responsible for resetting to finish. The SpinYield always sleeps for 1?s, which should be enough time for an average malloc call to finish. The requirement for low latency is not as strict when it's only GC threads waiting for each other, and the livemap is only allocated once per page, so always sleeping should be reasonable.
> 
> The regression caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167) was observed on SPECjvm2008-LU.small on linux-aarch64. The performance is noticeably better on linux-aarch64 when applying the patch to jdk-25+15 (which included [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167)). However, the performance is neutral when applying the patch to mainline now. With this in mind I think we still want to address the contention this way.
> 
> * Currently running through tier 1-4

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25580#pullrequestreview-2887642071

From tschatzl at openjdk.org  Mon Jun  2 10:10:52 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 2 Jun 2025 10:10:52 GMT
Subject: RFR: 8358313: G1: Refactor G1CollectedHeap::is_maximal_no_gc [v2]
In-Reply-To: <MZR7s_V3YrlvdFBUTF2QGo-koVwr3g_Z5xG4kLkIeiU=.e5220b8c-6ff2-47bd-9104-c752312437ab@github.com>
References: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>
 <MZR7s_V3YrlvdFBUTF2QGo-koVwr3g_Z5xG4kLkIeiU=.e5220b8c-6ff2-47bd-9104-c752312437ab@github.com>
Message-ID: <Fv-0WffCEXv1o2RSMSgrNTr0mK5JEHF2bcMYs5x0MXg=.871f6390-3173-4f2c-ab86-f4ab1ff3406e@github.com>

On Mon, 2 Jun 2025 09:56:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple changing of a method name and return-type to be more consistent with the surrounding code.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25579#pullrequestreview-2887664805

From eosterlund at openjdk.org  Mon Jun  2 10:10:52 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 10:10:52 GMT
Subject: RFR: 8357954: G1: No SATB barriers applied for runtime IN_NATIVE
 atomics
In-Reply-To: <8ZSEttcbi1yB9e6SWiwWt4yvA3d5gIgGyXK7QRRBUhA=.52d4158c-186a-4716-8f3b-b98af205160d@github.com>
References: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
 <8ZSEttcbi1yB9e6SWiwWt4yvA3d5gIgGyXK7QRRBUhA=.52d4158c-186a-4716-8f3b-b98af205160d@github.com>
Message-ID: <U2m9Mg9YIvpBnLZdzb0pxtEkEvkv37QmNzH5RBRm6mM=.9a3fc191-1b5f-40b9-beb2-de8261aa48b7@github.com>

On Mon, 2 Jun 2025 08:41:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks reasonable. AFAICS, only G1 has this gap, and both Shenandoah and Z already hook this up in their respective barrier sets. Correct?

Yes it looked that way to me as well. I actually thought this was missing in ZGC too, but apparently we were more proactive than I thought there. Phew!

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

PR Comment: https://git.openjdk.org/jdk/pull/25576#issuecomment-2929819263

From eosterlund at openjdk.org  Mon Jun  2 10:10:53 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 10:10:53 GMT
Subject: RFR: 8357954: G1: No SATB barriers applied for runtime IN_NATIVE
 atomics
In-Reply-To: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
References: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
Message-ID: <AC6izlTrgb0iLQML-Sto_UP5fLIfefBIIyMDKJXMSto=.baa0a58f-1f6b-4050-b929-65225a8c3a0f@github.com>

On Mon, 2 Jun 2025 08:19:48 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> OopHandle has had atomic xchg/cmpxchg operations added to it. Yet, the G1 access API backend doesn't really support that; there is no SATB barrier.
> 
> Fortunately the only use of OopHandle::xchg so far is appending to the pending list, which didn't need SATB barriers because young generation reference processing only adds young objects that the old gen doesn't care much about, and the old gen reference processor doesn't care about its own References that it publishes, because it's done after marking.
> 
> And fortunately the only use of OopHandle::cmpxchg so far is manipulating a lock-free list of virtual threads to unblock in JVM_TakeVirtualThreadListToUnblock. Since the virtual threads are blocked, they are externally kept alive.
> 
> But it's starting to feel quite scary, so let's be proactive and add the support to G1 before something inevitably blows up. This patch adds the missing SATB keep-alive code for G1 IN_NATIVE oop atomics.

Thanks for the reviews everyone!

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

PR Comment: https://git.openjdk.org/jdk/pull/25576#issuecomment-2929820955

From ayang at openjdk.org  Mon Jun  2 10:51:06 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 2 Jun 2025 10:51:06 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v9]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <-mRIrbyrBpxq1lZ2tfcxIuxRLh5lcoURlM-woAXM45k=.7c152a76-e34f-42ba-b9a7-323102b19371@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - merge
 - merge-fix
 - merge
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - ... and 2 more: https://git.openjdk.org/jdk/compare/83cb0c6d...08bc74e1

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=08
  Stats: 4375 lines in 31 files changed: 522 ins; 3454 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From aboldtch at openjdk.org  Mon Jun  2 11:58:09 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 2 Jun 2025 11:58:09 GMT
Subject: RFR: 8356716: ZGC: Cleanup Uncommit Logic [v7]
In-Reply-To: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
References: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
Message-ID: <kz5KjmtLbaCNklEMm9OJZj7fUOW14IpkHKUBgmuW--A=.38ebe52f-2d33-405a-8602-f7637973d33b@github.com>

> [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) required changing the way ZGC handle memory uncommitting (returning physical memory to the OS). Previously ZGC tracked how recently used memory was on a ZPage level. [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) did away with the ZPage abstraction for unused memory. But because of this ZGC does not have a convenient way of tracking the usage of a specific memory range. Instead [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) opted to keep a watermark in the cache unused mapped memory, to keep track of the amount of memory that was not used within the last ZUncommitDelay, and use this when deciding how much to uncommit.
> 
> Because this measurement is not as granular as previously, and because uncommitting memory is something we want to do conservatively, as a response to low memory utilization, [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) was written with the intent to spread out the uncommitting over some time interval.
> 
> The actual implementation in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) has a few issues which this RFE tries to address:
>   * Missing wait, the uncommitting is not actually spread out, but happens all at once.
>   * Reactivity, if the process starts using memory that was below the previous watermark, uncommitting should stop.
>   * Structure, the current implementation has a lot of different dependencies and has state spread out over multiple classes. Refactor to keep the logic contained to the ZUncommitter, and provide better named facilitating functions on the ZPartition and ZMappedCache. And make the lifecycle of ZUncommitter more explicit.
>   * Events, overhaul the JFR uncommit events to be sent (and track the time for) a chunk of uncommits without any waits.
> 
> An alternative discussed has been to do uncommitting based on GC triggers rather than a periodically. So rather than using ZUncommitDelay, we could have our proactive GCs actually trigger and track uncommitting. This might be a future RFE, but it was not attempted here as it would change user facing APIs. [JDK-8329758](https://bugs.openjdk.org/browse/JDK-8329758) will more than likely overhaul the uncommit triggers as well, and the whole concept of ZUncommitDelay and having to tune how to uncommit will go away.

Axel Boldt-Christmas has updated the pull request incrementally with one additional commit since the last revision:

  Rename uncommit_watermark to min_size_watermark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25198/files
  - new: https://git.openjdk.org/jdk/pull/25198/files/59aaac66..0b3f4739

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

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

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

From aboldtch at openjdk.org  Mon Jun  2 12:26:08 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 2 Jun 2025 12:26:08 GMT
Subject: RFR: 8356716: ZGC: Cleanup Uncommit Logic [v8]
In-Reply-To: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
References: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
Message-ID: <l7j50kL-5gfk9Amwk32NxpBsNE9Kv8R3lUdktArM4lA=.f24fd0b6-4b17-4fad-8dad-6d3b62e7590a@github.com>

> [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) required changing the way ZGC handle memory uncommitting (returning physical memory to the OS). Previously ZGC tracked how recently used memory was on a ZPage level. [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) did away with the ZPage abstraction for unused memory. But because of this ZGC does not have a convenient way of tracking the usage of a specific memory range. Instead [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) opted to keep a watermark in the cache unused mapped memory, to keep track of the amount of memory that was not used within the last ZUncommitDelay, and use this when deciding how much to uncommit.
> 
> Because this measurement is not as granular as previously, and because uncommitting memory is something we want to do conservatively, as a response to low memory utilization, [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) was written with the intent to spread out the uncommitting over some time interval.
> 
> The actual implementation in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) has a few issues which this RFE tries to address:
>   * Missing wait, the uncommitting is not actually spread out, but happens all at once.
>   * Reactivity, if the process starts using memory that was below the previous watermark, uncommitting should stop.
>   * Structure, the current implementation has a lot of different dependencies and has state spread out over multiple classes. Refactor to keep the logic contained to the ZUncommitter, and provide better named facilitating functions on the ZPartition and ZMappedCache. And make the lifecycle of ZUncommitter more explicit.
>   * Events, overhaul the JFR uncommit events to be sent (and track the time for) a chunk of uncommits without any waits.
> 
> An alternative discussed has been to do uncommitting based on GC triggers rather than a periodically. So rather than using ZUncommitDelay, we could have our proactive GCs actually trigger and track uncommitting. This might be a future RFE, but it was not attempted here as it would change user facing APIs. [JDK-8329758](https://bugs.openjdk.org/browse/JDK-8329758) will more than likely overhaul the uncommit triggers as well, and the whole concept of ZUncommitDelay and having to tune how to uncommit will go away.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8356716
 - Extract update_statistics
 - Rename uncommit_watermark to min_size_watermark
 - Reduce the amount of should_continue checks
 - Update src/hotspot/share/gc/z/zUncommitter.cpp
   
   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>
 - Avoid excessive logging if ZUncommitDelay == 0
 - Move uncommit logic from MappedCache to Uncommitter + cleanup and comment
 - Better cycle activate / deactivate scoping
 - Remove newline
 - Cleanup time logging
 - ... and 19 more: https://git.openjdk.org/jdk/compare/c22af0c2...c8b2ab8b

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

Changes: https://git.openjdk.org/jdk/pull/25198/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25198&range=07
  Stats: 501 lines in 8 files changed: 362 ins; 111 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/25198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25198/head:pull/25198

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

From eosterlund at openjdk.org  Mon Jun  2 12:26:08 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 12:26:08 GMT
Subject: RFR: 8356716: ZGC: Cleanup Uncommit Logic [v8]
In-Reply-To: <l7j50kL-5gfk9Amwk32NxpBsNE9Kv8R3lUdktArM4lA=.f24fd0b6-4b17-4fad-8dad-6d3b62e7590a@github.com>
References: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
 <l7j50kL-5gfk9Amwk32NxpBsNE9Kv8R3lUdktArM4lA=.f24fd0b6-4b17-4fad-8dad-6d3b62e7590a@github.com>
Message-ID: <F9pZ4pUppgXBgTXiS2n0gyGXKNBB6UjTIH1cqiwV65U=.f905d47f-7f2f-493c-87d6-80b8732dfcbe@github.com>

On Mon, 2 Jun 2025 12:23:06 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) required changing the way ZGC handle memory uncommitting (returning physical memory to the OS). Previously ZGC tracked how recently used memory was on a ZPage level. [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) did away with the ZPage abstraction for unused memory. But because of this ZGC does not have a convenient way of tracking the usage of a specific memory range. Instead [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) opted to keep a watermark in the cache unused mapped memory, to keep track of the amount of memory that was not used within the last ZUncommitDelay, and use this when deciding how much to uncommit.
>> 
>> Because this measurement is not as granular as previously, and because uncommitting memory is something we want to do conservatively, as a response to low memory utilization, [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) was written with the intent to spread out the uncommitting over some time interval.
>> 
>> The actual implementation in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) has a few issues which this RFE tries to address:
>>   * Missing wait, the uncommitting is not actually spread out, but happens all at once.
>>   * Reactivity, if the process starts using memory that was below the previous watermark, uncommitting should stop.
>>   * Structure, the current implementation has a lot of different dependencies and has state spread out over multiple classes. Refactor to keep the logic contained to the ZUncommitter, and provide better named facilitating functions on the ZPartition and ZMappedCache. And make the lifecycle of ZUncommitter more explicit.
>>   * Events, overhaul the JFR uncommit events to be sent (and track the time for) a chunk of uncommits without any waits.
>> 
>> An alternative discussed has been to do uncommitting based on GC triggers rather than a periodically. So rather than using ZUncommitDelay, we could have our proactive GCs actually trigger and track uncommitting. This might be a future RFE, but it was not attempted here as it would change user facing APIs. [JDK-8329758](https://bugs.openjdk.org/browse/JDK-8329758) will more than likely overhaul the uncommit triggers as well, and the whole concept of ZUncommitDelay and having to tune how to uncommit will go away.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8356716
>  - Extract update_statistics
>  - Rename uncommit_watermark to min_size_watermark
>  - Reduce the amount of should_continue checks
>  - Update src/hotspot/share/gc/z/zUncommitter.cpp
>    
>    Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>
>  - Avoid excessive logging if ZUncommitDelay == 0
>  - Move uncommit logic from MappedCache to Uncommitter + cleanup and comment
>  - Better cycle activate / deactivate scoping
>  - Remove newline
>  - Cleanup time logging
>  - ... and 19 more: https://git.openjdk.org/jdk/compare/c22af0c2...c8b2ab8b

Looks good with the latest update.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25198#pullrequestreview-2888149294

From eosterlund at openjdk.org  Mon Jun  2 13:12:53 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 2 Jun 2025 13:12:53 GMT
Subject: RFR: 8356880: ZGC: Backoff in ZLiveMap::reset spin-loop
In-Reply-To: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
References: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
Message-ID: <UUm5o5-VARu4eExQZTnFD5thWRrttQmNRfrHNz_p4So=.e930c6bf-a73d-439b-8311-5af7c2534f61@github.com>

On Mon, 2 Jun 2025 09:39:15 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE addresses contention in ZLiveMap::reset caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167). The contention is noticeable on (Linux) aarch64, where the Atomic::load_acquire in the spin-loop is slower than on other platforms.
> 
> To reduce spinning, and in turn the number of calls to Atomic::load_acquire, I suggest we introduce a backoff via a SpinYield to allow some time for the thread responsible for resetting to finish. The SpinYield always sleeps for 1?s, which should be enough time for an average malloc call to finish. The requirement for low latency is not as strict when it's only GC threads waiting for each other, and the livemap is only allocated once per page, so always sleeping should be reasonable.
> 
> The regression caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167) was observed on SPECjvm2008-LU.small on linux-aarch64. The performance is noticeably better on linux-aarch64 when applying the patch to jdk-25+15 (which included [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167)). However, the performance is neutral when applying the patch to mainline now. With this in mind I think we still want to address the contention this way.
> 
> * Currently running through tier 1-4

Good stuff.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25580#pullrequestreview-2888341102

From wkemper at openjdk.org  Mon Jun  2 16:51:34 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 2 Jun 2025 16:51:34 GMT
Subject: Integrated: 8358102: GenShen: Age tables could be seeded with
 cumulative values
Message-ID: <HScMXAilfZgm_U51aJShwPC7lNSKFGhOgBA3FvPawU8=.bf63b9ef-9265-41f2-a369-8f25dd515e0d@github.com>

When dynamic tenuring threshold is disabled, or the age census is configured to be computed during evacuation, the first cohort is seeded with the cumulative counts, rather than the current cycle's counts. This is not the default configuration so this is not an urgent issue.

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

Commit messages:
 - Use census data from current cycle, rather than cumulative values

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

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

From ysr at openjdk.org  Mon Jun  2 16:51:34 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 2 Jun 2025 16:51:34 GMT
Subject: Integrated: 8358102: GenShen: Age tables could be seeded with
 cumulative values
In-Reply-To: <HScMXAilfZgm_U51aJShwPC7lNSKFGhOgBA3FvPawU8=.bf63b9ef-9265-41f2-a369-8f25dd515e0d@github.com>
References: <HScMXAilfZgm_U51aJShwPC7lNSKFGhOgBA3FvPawU8=.bf63b9ef-9265-41f2-a369-8f25dd515e0d@github.com>
Message-ID: <2QwNjBKqo7q-vwQGJpyIJPc5RsEAwzqzBmZk1erJ9yE=.f3be64f5-3937-48e2-abd0-aea71a6e4081@github.com>

On Fri, 30 May 2025 01:25:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When dynamic tenuring threshold is disabled, or the age census is configured to be computed during evacuation, the first cohort is seeded with the cumulative counts, rather than the current cycle's counts. This is not the default configuration so this is not an urgent issue.

LGTM. Thanks for finding and fixing the issue.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25535#pullrequestreview-2881868083

From wkemper at openjdk.org  Mon Jun  2 16:51:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 2 Jun 2025 16:51:35 GMT
Subject: Integrated: 8358102: GenShen: Age tables could be seeded with
 cumulative values
In-Reply-To: <HScMXAilfZgm_U51aJShwPC7lNSKFGhOgBA3FvPawU8=.bf63b9ef-9265-41f2-a369-8f25dd515e0d@github.com>
References: <HScMXAilfZgm_U51aJShwPC7lNSKFGhOgBA3FvPawU8=.bf63b9ef-9265-41f2-a369-8f25dd515e0d@github.com>
Message-ID: <bjWAOHiwWaPZZ-jMu12GvRuS8KEV7NhBLvxwkgwyZqY=.75cf8175-1af5-4309-8915-15b5a27f1bf2@github.com>

On Fri, 30 May 2025 01:25:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When dynamic tenuring threshold is disabled, or the age census is configured to be computed during evacuation, the first cohort is seeded with the cumulative counts, rather than the current cycle's counts. This is not the default configuration so this is not an urgent issue.

This pull request has now been integrated.

Changeset: 99a4b22a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99a4b22ae7dc2755df1780cc7d74c5d6e3cd4cd4
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358102: GenShen: Age tables could be seeded with cumulative values

Reviewed-by: ysr

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

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

From duke at openjdk.org  Mon Jun  2 20:59:00 2025
From: duke at openjdk.org (duke)
Date: Mon, 2 Jun 2025 20:59:00 GMT
Subject: Withdrawn: 8348278: Trim InitialRAMPercentage to improve startup in
 default modes
In-Reply-To: <iA5-e4hKspjLBJAniBWfSl6A57zlBVUC5cMSsWY-ack=.29cab729-0abc-4a10-8050-a119d95860ff@github.com>
References: <iA5-e4hKspjLBJAniBWfSl6A57zlBVUC5cMSsWY-ack=.29cab729-0abc-4a10-8050-a119d95860ff@github.com>
Message-ID: <qNaGujLOJMl7tSy1xzwyBCXf06Rqc8VuE9g8JHjNuJE=.63d7dd8e-08fb-4404-9854-8c3cad222823@github.com>

On Thu, 23 Jan 2025 11:27:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See bug for discussion. This is the code change, which is simple. What is not simple is deciding what the new value should be. The change would probably require CSR, which I can file after we agree on the value.
> 
> I think cutting to 0.2% of RAM size gets us into good sweet spot:
>  - On huge 1024G machine, this yields 2G initial heap
>  - On reasonably sized 128G machine, this gives 256M initial heap
>  - On smaller 1G container, this gives 2M initial heap
> 
> Additional testing:
>  - [x] Linux AArch64 server fastdebug, `all`

This pull request has been closed without being integrated.

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

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

From aboldtch at openjdk.org  Tue Jun  3 05:24:03 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 3 Jun 2025 05:24:03 GMT
Subject: RFR: 8356716: ZGC: Cleanup Uncommit Logic [v9]
In-Reply-To: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
References: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
Message-ID: <v8u6013RIbIES-g9rF1nTWaHPCscQ9xA2968KYe38DA=.aa16fa5b-d12e-4074-9f8c-daf01e9147c4@github.com>

> [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) required changing the way ZGC handle memory uncommitting (returning physical memory to the OS). Previously ZGC tracked how recently used memory was on a ZPage level. [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) did away with the ZPage abstraction for unused memory. But because of this ZGC does not have a convenient way of tracking the usage of a specific memory range. Instead [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) opted to keep a watermark in the cache unused mapped memory, to keep track of the amount of memory that was not used within the last ZUncommitDelay, and use this when deciding how much to uncommit.
> 
> Because this measurement is not as granular as previously, and because uncommitting memory is something we want to do conservatively, as a response to low memory utilization, [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) was written with the intent to spread out the uncommitting over some time interval.
> 
> The actual implementation in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) has a few issues which this RFE tries to address:
>   * Missing wait, the uncommitting is not actually spread out, but happens all at once.
>   * Reactivity, if the process starts using memory that was below the previous watermark, uncommitting should stop.
>   * Structure, the current implementation has a lot of different dependencies and has state spread out over multiple classes. Refactor to keep the logic contained to the ZUncommitter, and provide better named facilitating functions on the ZPartition and ZMappedCache. And make the lifecycle of ZUncommitter more explicit.
>   * Events, overhaul the JFR uncommit events to be sent (and track the time for) a chunk of uncommits without any waits.
> 
> An alternative discussed has been to do uncommitting based on GC triggers rather than a periodically. So rather than using ZUncommitDelay, we could have our proactive GCs actually trigger and track uncommitting. This might be a future RFE, but it was not attempted here as it would change user facing APIs. [JDK-8329758](https://bugs.openjdk.org/browse/JDK-8329758) will more than likely overhaul the uncommit triggers as well, and the whole concept of ZUncommitDelay and having to tune how to uncommit will go away.

Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:

 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8356716
 - Check termination before deactivate
 - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8356716
 - Extract update_statistics
 - Rename uncommit_watermark to min_size_watermark
 - Reduce the amount of should_continue checks
 - Update src/hotspot/share/gc/z/zUncommitter.cpp
   
   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>
 - Avoid excessive logging if ZUncommitDelay == 0
 - Move uncommit logic from MappedCache to Uncommitter + cleanup and comment
 - Better cycle activate / deactivate scoping
 - ... and 21 more: https://git.openjdk.org/jdk/compare/832c5b06...9ae37064

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

Changes: https://git.openjdk.org/jdk/pull/25198/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25198&range=08
  Stats: 506 lines in 8 files changed: 367 ins; 111 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/25198.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25198/head:pull/25198

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

From aboldtch at openjdk.org  Tue Jun  3 06:19:53 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 3 Jun 2025 06:19:53 GMT
Subject: RFR: 8356880: ZGC: Backoff in ZLiveMap::reset spin-loop
In-Reply-To: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
References: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
Message-ID: <1Ck--R66Q-6qtu5juSkT_F1LGfTAMwtzFbGjcoGaQPw=.1340306e-f119-45b1-bdd0-663f53ed73d5@github.com>

On Mon, 2 Jun 2025 09:39:15 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE addresses contention in ZLiveMap::reset caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167). The contention is noticeable on (Linux) aarch64, where the Atomic::load_acquire in the spin-loop is slower than on other platforms.
> 
> To reduce spinning, and in turn the number of calls to Atomic::load_acquire, I suggest we introduce a backoff via a SpinYield to allow some time for the thread responsible for resetting to finish. The SpinYield always sleeps for 1?s, which should be enough time for an average malloc call to finish. The requirement for low latency is not as strict when it's only GC threads waiting for each other, and the livemap is only allocated once per page, so always sleeping should be reasonable.
> 
> The regression caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167) was observed on SPECjvm2008-LU.small on linux-aarch64. The performance is noticeably better on linux-aarch64 when applying the patch to jdk-25+15 (which included [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167)). However, the performance is neutral when applying the patch to mainline now. With this in mind I think we still want to address the contention this way.
> 
> * Oracle's tier 1-4

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25580#pullrequestreview-2890840990

From eosterlund at openjdk.org  Tue Jun  3 07:22:55 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 3 Jun 2025 07:22:55 GMT
Subject: RFR: 8356716: ZGC: Cleanup Uncommit Logic [v9]
In-Reply-To: <v8u6013RIbIES-g9rF1nTWaHPCscQ9xA2968KYe38DA=.aa16fa5b-d12e-4074-9f8c-daf01e9147c4@github.com>
References: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
 <v8u6013RIbIES-g9rF1nTWaHPCscQ9xA2968KYe38DA=.aa16fa5b-d12e-4074-9f8c-daf01e9147c4@github.com>
Message-ID: <ABSyHP4J9XduNGwPzvhUetH4zJTUHamMA8j6b_irtMU=.aa50d81a-c4fa-4477-8d79-f9cbb2cf94be@github.com>

On Tue, 3 Jun 2025 05:24:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) required changing the way ZGC handle memory uncommitting (returning physical memory to the OS). Previously ZGC tracked how recently used memory was on a ZPage level. [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) did away with the ZPage abstraction for unused memory. But because of this ZGC does not have a convenient way of tracking the usage of a specific memory range. Instead [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) opted to keep a watermark in the cache unused mapped memory, to keep track of the amount of memory that was not used within the last ZUncommitDelay, and use this when deciding how much to uncommit.
>> 
>> Because this measurement is not as granular as previously, and because uncommitting memory is something we want to do conservatively, as a response to low memory utilization, [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) was written with the intent to spread out the uncommitting over some time interval.
>> 
>> The actual implementation in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) has a few issues which this RFE tries to address:
>>   * Missing wait, the uncommitting is not actually spread out, but happens all at once.
>>   * Reactivity, if the process starts using memory that was below the previous watermark, uncommitting should stop.
>>   * Structure, the current implementation has a lot of different dependencies and has state spread out over multiple classes. Refactor to keep the logic contained to the ZUncommitter, and provide better named facilitating functions on the ZPartition and ZMappedCache. And make the lifecycle of ZUncommitter more explicit.
>>   * Events, overhaul the JFR uncommit events to be sent (and track the time for) a chunk of uncommits without any waits.
>> 
>> An alternative discussed has been to do uncommitting based on GC triggers rather than a periodically. So rather than using ZUncommitDelay, we could have our proactive GCs actually trigger and track uncommitting. This might be a future RFE, but it was not attempted here as it would change user facing APIs. [JDK-8329758](https://bugs.openjdk.org/browse/JDK-8329758) will more than likely overhaul the uncommit triggers as well, and the whole concept of ZUncommitDelay and having to tune how to uncommit will go away.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8356716
>  - Check termination before deactivate
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8356716
>  - Extract update_statistics
>  - Rename uncommit_watermark to min_size_watermark
>  - Reduce the amount of should_continue checks
>  - Update src/hotspot/share/gc/z/zUncommitter.cpp
>    
>    Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>
>  - Avoid excessive logging if ZUncommitDelay == 0
>  - Move uncommit logic from MappedCache to Uncommitter + cleanup and comment
>  - Better cycle activate / deactivate scoping
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/832c5b06...9ae37064

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25198#pullrequestreview-2891035578

From ayang at openjdk.org  Tue Jun  3 07:28:56 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 3 Jun 2025 07:28:56 GMT
Subject: RFR: 8358313: G1: Refactor G1CollectedHeap::is_maximal_no_gc [v2]
In-Reply-To: <MZR7s_V3YrlvdFBUTF2QGo-koVwr3g_Z5xG4kLkIeiU=.e5220b8c-6ff2-47bd-9104-c752312437ab@github.com>
References: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>
 <MZR7s_V3YrlvdFBUTF2QGo-koVwr3g_Z5xG4kLkIeiU=.e5220b8c-6ff2-47bd-9104-c752312437ab@github.com>
Message-ID: <zTn0VcdULsLe6lurTaOiPfFI8DYzIrLA25dNbU0IrRQ=.fa698f33-29ab-436a-82a1-6d732dff88f8@github.com>

On Mon, 2 Jun 2025 09:56:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple changing of a method name and return-type to be more consistent with the surrounding code.
>> 
>> Test: tier1
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1CollectedHeap.cpp
>   
>   Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25579#issuecomment-2933877436

From ayang at openjdk.org  Tue Jun  3 07:28:57 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 3 Jun 2025 07:28:57 GMT
Subject: Integrated: 8358313: G1: Refactor G1CollectedHeap::is_maximal_no_gc
In-Reply-To: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>
References: <cFt6nqlF92YwpvjsT6Sy5858TN8qvt2ZjQKiRWmfNdY=.6f14a51b-eb78-488d-a496-15da8c754b53@github.com>
Message-ID: <G2ssdJjjUs4pV78suqT75WxHsfKdo_5khmfeROPxizw=.db4f482d-9436-467f-9a7d-72147b21c309@github.com>

On Mon, 2 Jun 2025 09:33:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple changing of a method name and return-type to be more consistent with the surrounding code.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: dbf562c7
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbf562c72502ab8da96eb130ff8222bba66c72cc
Stats:     10 lines in 2 files changed: 3 ins; 4 del; 3 mod

8358313: G1: Refactor G1CollectedHeap::is_maximal_no_gc

Reviewed-by: jsikstro, tschatzl

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

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

From ayang at openjdk.org  Tue Jun  3 09:15:02 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 3 Jun 2025 09:15:02 GMT
Subject: RFR: 8358483: G1: Remove G1HeapRegionManager::num_available_regions
Message-ID: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>

Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.

Test: tier1

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

Commit messages:
 - g1-move-api

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

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

From aboldtch at openjdk.org  Tue Jun  3 09:39:01 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 3 Jun 2025 09:39:01 GMT
Subject: RFR: 8356716: ZGC: Cleanup Uncommit Logic [v9]
In-Reply-To: <v8u6013RIbIES-g9rF1nTWaHPCscQ9xA2968KYe38DA=.aa16fa5b-d12e-4074-9f8c-daf01e9147c4@github.com>
References: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
 <v8u6013RIbIES-g9rF1nTWaHPCscQ9xA2968KYe38DA=.aa16fa5b-d12e-4074-9f8c-daf01e9147c4@github.com>
Message-ID: <jx3HA8ornZGfUqYzOuP3KaU3FmMl8_3eCZyzWZUcvSY=.170f6f0c-8777-4316-b01b-1c84ad2885cc@github.com>

On Tue, 3 Jun 2025 05:24:03 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) required changing the way ZGC handle memory uncommitting (returning physical memory to the OS). Previously ZGC tracked how recently used memory was on a ZPage level. [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) did away with the ZPage abstraction for unused memory. But because of this ZGC does not have a convenient way of tracking the usage of a specific memory range. Instead [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) opted to keep a watermark in the cache unused mapped memory, to keep track of the amount of memory that was not used within the last ZUncommitDelay, and use this when deciding how much to uncommit.
>> 
>> Because this measurement is not as granular as previously, and because uncommitting memory is something we want to do conservatively, as a response to low memory utilization, [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) was written with the intent to spread out the uncommitting over some time interval.
>> 
>> The actual implementation in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) has a few issues which this RFE tries to address:
>>   * Missing wait, the uncommitting is not actually spread out, but happens all at once.
>>   * Reactivity, if the process starts using memory that was below the previous watermark, uncommitting should stop.
>>   * Structure, the current implementation has a lot of different dependencies and has state spread out over multiple classes. Refactor to keep the logic contained to the ZUncommitter, and provide better named facilitating functions on the ZPartition and ZMappedCache. And make the lifecycle of ZUncommitter more explicit.
>>   * Events, overhaul the JFR uncommit events to be sent (and track the time for) a chunk of uncommits without any waits.
>> 
>> An alternative discussed has been to do uncommitting based on GC triggers rather than a periodically. So rather than using ZUncommitDelay, we could have our proactive GCs actually trigger and track uncommitting. This might be a future RFE, but it was not attempted here as it would change user facing APIs. [JDK-8329758](https://bugs.openjdk.org/browse/JDK-8329758) will more than likely overhaul the uncommit triggers as well, and the whole concept of ZUncommitDelay and having to tune how to uncommit will go away.
>
> Axel Boldt-Christmas has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8356716
>  - Check termination before deactivate
>  - Merge remote-tracking branch 'upstream_jdk/master' into JDK-8356716
>  - Extract update_statistics
>  - Rename uncommit_watermark to min_size_watermark
>  - Reduce the amount of should_continue checks
>  - Update src/hotspot/share/gc/z/zUncommitter.cpp
>    
>    Co-authored-by: Joel Sikstr?m <joel.sikstrom at oracle.com>
>  - Avoid excessive logging if ZUncommitDelay == 0
>  - Move uncommit logic from MappedCache to Uncommitter + cleanup and comment
>  - Better cycle activate / deactivate scoping
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/832c5b06...9ae37064

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25198#issuecomment-2934371330

From aboldtch at openjdk.org  Tue Jun  3 09:39:02 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 3 Jun 2025 09:39:02 GMT
Subject: Integrated: 8356716: ZGC: Cleanup Uncommit Logic
In-Reply-To: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
References: <9T7g6nawhKvvp8dfTlqmGvUtwIqPY9rqiXv3r246mrQ=.2e56f850-71ab-4d88-b5bb-7dd3c3e2b8a3@github.com>
Message-ID: <9oUEI6E0-CndDSJUD9mfTkpxmAKQKVzY7cCj9uh0RCQ=.7edd1cd3-717a-491c-948b-30ceefcf04eb@github.com>

On Tue, 13 May 2025 05:57:33 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) required changing the way ZGC handle memory uncommitting (returning physical memory to the OS). Previously ZGC tracked how recently used memory was on a ZPage level. [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) did away with the ZPage abstraction for unused memory. But because of this ZGC does not have a convenient way of tracking the usage of a specific memory range. Instead [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) opted to keep a watermark in the cache unused mapped memory, to keep track of the amount of memory that was not used within the last ZUncommitDelay, and use this when deciding how much to uncommit.
> 
> Because this measurement is not as granular as previously, and because uncommitting memory is something we want to do conservatively, as a response to low memory utilization, [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) was written with the intent to spread out the uncommitting over some time interval.
> 
> The actual implementation in [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441) has a few issues which this RFE tries to address:
>   * Missing wait, the uncommitting is not actually spread out, but happens all at once.
>   * Reactivity, if the process starts using memory that was below the previous watermark, uncommitting should stop.
>   * Structure, the current implementation has a lot of different dependencies and has state spread out over multiple classes. Refactor to keep the logic contained to the ZUncommitter, and provide better named facilitating functions on the ZPartition and ZMappedCache. And make the lifecycle of ZUncommitter more explicit.
>   * Events, overhaul the JFR uncommit events to be sent (and track the time for) a chunk of uncommits without any waits.
> 
> An alternative discussed has been to do uncommitting based on GC triggers rather than a periodically. So rather than using ZUncommitDelay, we could have our proactive GCs actually trigger and track uncommitting. This might be a future RFE, but it was not attempted here as it would change user facing APIs. [JDK-8329758](https://bugs.openjdk.org/browse/JDK-8329758) will more than likely overhaul the uncommit triggers as well, and the whole concept of ZUncommitDelay and having to tune how to uncommit will go away.

This pull request has now been integrated.

Changeset: def7355c
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/def7355cc97c7099dd04778a7dd7fd4ba5a7a630
Stats:     506 lines in 8 files changed: 367 ins; 111 del; 28 mod

8356716: ZGC: Cleanup Uncommit Logic

Reviewed-by: eosterlund, jsikstro

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

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

From jsikstro at openjdk.org  Tue Jun  3 11:45:06 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 3 Jun 2025 11:45:06 GMT
Subject: RFR: 8356880: ZGC: Backoff in ZLiveMap::reset spin-loop
In-Reply-To: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
References: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
Message-ID: <XjUOr1Cl5tFUZZnoSt23AtdzTOWPf2nbLBt187z81nE=.cac89c7f-8f76-41bb-9fa7-54c52a6d1352@github.com>

On Mon, 2 Jun 2025 09:39:15 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE addresses contention in ZLiveMap::reset caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167). The contention is noticeable on (Linux) aarch64, where the Atomic::load_acquire in the spin-loop is slower than on other platforms.
> 
> To reduce spinning, and in turn the number of calls to Atomic::load_acquire, I suggest we introduce a backoff via a SpinYield to allow some time for the thread responsible for resetting to finish. The SpinYield always sleeps for 1?s, which should be enough time for an average malloc call to finish. The requirement for low latency is not as strict when it's only GC threads waiting for each other, and the livemap is only allocated once per page, so always sleeping should be reasonable.
> 
> The regression caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167) was observed on SPECjvm2008-LU.small on linux-aarch64. The performance is noticeably better on linux-aarch64 when applying the patch to jdk-25+15 (which included [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167)). However, the performance is neutral when applying the patch to mainline now. With this in mind I think we still want to address the contention this way.
> 
> * Oracle's tier 1-4

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25580#issuecomment-2934838795

From jsikstro at openjdk.org  Tue Jun  3 11:45:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 3 Jun 2025 11:45:07 GMT
Subject: Integrated: 8356880: ZGC: Backoff in ZLiveMap::reset spin-loop
In-Reply-To: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
References: <H7tkOBPmsPavF1SSNXxZfAkjeLysc9mw7bsDc_ryLPs=.54f55406-d5e0-4960-acb2-f752ef311a88@github.com>
Message-ID: <Z02zlkRN7PVxscczQlsQULW7xfk0nuRJJR0bl1nTRBA=.80e8f016-f9f5-45c9-a75c-58bab5a7c951@github.com>

On Mon, 2 Jun 2025 09:39:15 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE addresses contention in ZLiveMap::reset caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167). The contention is noticeable on (Linux) aarch64, where the Atomic::load_acquire in the spin-loop is slower than on other platforms.
> 
> To reduce spinning, and in turn the number of calls to Atomic::load_acquire, I suggest we introduce a backoff via a SpinYield to allow some time for the thread responsible for resetting to finish. The SpinYield always sleeps for 1?s, which should be enough time for an average malloc call to finish. The requirement for low latency is not as strict when it's only GC threads waiting for each other, and the livemap is only allocated once per page, so always sleeping should be reasonable.
> 
> The regression caused by [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167) was observed on SPECjvm2008-LU.small on linux-aarch64. The performance is noticeably better on linux-aarch64 when applying the patch to jdk-25+15 (which included [JDK-8351167](https://bugs.openjdk.org/browse/JDK-8351167)). However, the performance is neutral when applying the patch to mainline now. With this in mind I think we still want to address the contention this way.
> 
> * Oracle's tier 1-4

This pull request has now been integrated.

Changeset: 78a392aa
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78a392aa3b0cda52cfacfa15250fa61010519424
Stats:     33 lines in 1 file changed: 11 ins; 0 del; 22 mod

8356880: ZGC: Backoff in ZLiveMap::reset spin-loop

Reviewed-by: stefank, eosterlund, aboldtch

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

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

From eosterlund at openjdk.org  Tue Jun  3 14:31:01 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 3 Jun 2025 14:31:01 GMT
Subject: Integrated: 8357954: G1: No SATB barriers applied for runtime
 IN_NATIVE atomics
In-Reply-To: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
References: <x-fXJUqG8E4NPIpKUZ38nyKhUhru_85bbnbbBRtvT0Y=.86bd219b-a956-4ee6-a574-84b2a093c0a2@github.com>
Message-ID: <YWiyNLvUfYlEsGJ63huYBLAlBzAn6W2UQN_Y8iL9wjM=.794b4f9d-3e5d-44c3-aecb-4d9535c8be58@github.com>

On Mon, 2 Jun 2025 08:19:48 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> OopHandle has had atomic xchg/cmpxchg operations added to it. Yet, the G1 access API backend doesn't really support that; there is no SATB barrier.
> 
> Fortunately the only use of OopHandle::xchg so far is appending to the pending list, which didn't need SATB barriers because young generation reference processing only adds young objects that the old gen doesn't care much about, and the old gen reference processor doesn't care about its own References that it publishes, because it's done after marking.
> 
> And fortunately the only use of OopHandle::cmpxchg so far is manipulating a lock-free list of virtual threads to unblock in JVM_TakeVirtualThreadListToUnblock. Since the virtual threads are blocked, they are externally kept alive.
> 
> But it's starting to feel quite scary, so let's be proactive and add the support to G1 before something inevitably blows up. This patch adds the missing SATB keep-alive code for G1 IN_NATIVE oop atomics.

This pull request has now been integrated.

Changeset: d3f54dae
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3f54dae30e377b9fb4aaa06bc123b71de444a74
Stats:     27 lines in 2 files changed: 27 ins; 0 del; 0 mod

8357954: G1: No SATB barriers applied for runtime IN_NATIVE atomics

Reviewed-by: shade, kbarrett, tschatzl

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

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

From ayang at openjdk.org  Wed Jun  4 09:11:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 4 Jun 2025 09:11:04 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v10]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <wQPxmGNk9EpxXZh8P8rKHSd56WNYcjCDLjC4WSUqImc=.c341f3cc-ff9b-426c-a9dd-257f969cc81d@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - merge
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - review
 - ... and 4 more: https://git.openjdk.org/jdk/compare/ab235000...72645267

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=09
  Stats: 4373 lines in 31 files changed: 522 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From kevinw at openjdk.org  Wed Jun  4 09:31:19 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 4 Jun 2025 09:31:19 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v10]
In-Reply-To: <wQPxmGNk9EpxXZh8P8rKHSd56WNYcjCDLjC4WSUqImc=.c341f3cc-ff9b-426c-a9dd-257f969cc81d@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <wQPxmGNk9EpxXZh8P8rKHSd56WNYcjCDLjC4WSUqImc=.c341f3cc-ff9b-426c-a9dd-257f969cc81d@github.com>
Message-ID: <xDv3NkgKarq8jdrvU9k0HEmq6AMctX555bzW3B5HHoo=.b6f7bd9f-ec98-40d7-afc6-0aea7b389037@github.com>

On Wed, 4 Jun 2025 09:11:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - revert-aliases
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - merge-fix
>  - merge
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/ab235000...72645267

Thanks for the aliasmap update, looks good.

I think alias sun.gc.policy.boundaryMoved is removed here as it's already redundant, the rest all match with the counter being removed in the change.

There is a case for removing those old e.g. 1.4.1 aliases separately, in a future change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25000#issuecomment-2939297086

From sjohanss at openjdk.org  Wed Jun  4 11:27:24 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 4 Jun 2025 11:27:24 GMT
Subject: RFR: 8357053: ZGC: Improved utility for ZPageAge [v5]
In-Reply-To: <1OVBoguoS9JYxlamI1Ag5nbBWgl9YTXvzVD38J7BD9c=.47f93b60-0b67-4786-9706-cec318260c2b@github.com>
References: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
 <1OVBoguoS9JYxlamI1Ag5nbBWgl9YTXvzVD38J7BD9c=.47f93b60-0b67-4786-9706-cec318260c2b@github.com>
Message-ID: <j90u_NHeh25wCgGlEeXDWbnnV0M6EaQlSfPwB0QiB14=.4353a2be-8c3d-45f1-9cc9-f1fda374a574@github.com>

On Fri, 30 May 2025 08:14:34 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> This RFE improves utility for converting to/from, iterating over and defining structures that are indexed using the `ZPageAge` type.
>> 
>> Converting to/from ZPageAge and its underlying type (uint8_t, often just uint) is currently done via using static_cast. This works fine because sane values are converted in all use cases. However, to make conversion safer (and also more readable), I propose we add a `to_zpageage` and a corresponding `untype` that checks that the conversion is valid. Such conversion methods should be used instead of calling `static_cast<uint/ZPageAge>`.
>> 
>> We currently define a value called `ZPageAgeMax`, which is defined as `static_cast<uint>(ZPageAge::old)`. The majority of places that use this value actualy use `ZPageAgeMax + 1`, which is equivalent to the number of ages. Instead, I propose we define and use a value that represents the number of possible ages, called `ZPageAgeCount`.
>> 
>> Lastly, to make iterating over ages more accessible, I propose we create an intreface of enum iterators of ZPageAge. This will also create a foundation for generating values that require a ZPageAge in the future. Since the end of the enum iterators are exclusive, I've opted to use the following value as end for the iterators:
>> 
>> constexpr ZPageAge ZPageAgeLastPlusOne = static_cast<ZPageAge>(ZPageAgeCount);
>> 
>> 
>> I see us using either this or a sentinel/dummy value at the end of the enum class, but I prefer having a value similar to `ZPageAgeLastPlusOne` over a dummy value.
>> 
>> Testing:
>> * Oracle's tier 1-4
>> * GHA
>
> 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 11 commits:
> 
>  - Merge branch 'master' into JDK-8357053_zpageage_utility
>  - Remove redundant access specifier
>  - Include order
>  - Style fix :)
>  - Added operator+/- for ZPageAge
>  - Fix include order in enumIterator.hpp
>  - Use T instead of EnumType
>  - Use ENUMERATOR_RANGE instead of ENUMERATOR_VALUE_RANGE
>  - Copyright years
>  - Simplify untype(ZPageAge age)
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/07f5b762...3243a67a

Looks really nice. As discussed offline, adding a gtest to make sure that the ranges cover the expected ages could be an additional nice addition.

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

Marked as reviewed by sjohanss (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25251#pullrequestreview-2896350248

From jsikstro at openjdk.org  Wed Jun  4 11:52:33 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 4 Jun 2025 11:52:33 GMT
Subject: RFR: 8357053: ZGC: Improved utility for ZPageAge [v6]
In-Reply-To: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
References: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
Message-ID: <Pn9mXwYEECmAmU6xjbCamWbXfbveECyCRzlQHkZIOtc=.d10ba6c9-9f13-4358-b81b-c9e7c2f853e0@github.com>

> Hello,
> 
> This RFE improves utility for converting to/from, iterating over and defining structures that are indexed using the `ZPageAge` type.
> 
> Converting to/from ZPageAge and its underlying type (uint8_t, often just uint) is currently done via using static_cast. This works fine because sane values are converted in all use cases. However, to make conversion safer (and also more readable), I propose we add a `to_zpageage` and a corresponding `untype` that checks that the conversion is valid. Such conversion methods should be used instead of calling `static_cast<uint/ZPageAge>`.
> 
> We currently define a value called `ZPageAgeMax`, which is defined as `static_cast<uint>(ZPageAge::old)`. The majority of places that use this value actualy use `ZPageAgeMax + 1`, which is equivalent to the number of ages. Instead, I propose we define and use a value that represents the number of possible ages, called `ZPageAgeCount`.
> 
> Lastly, to make iterating over ages more accessible, I propose we create an intreface of enum iterators of ZPageAge. This will also create a foundation for generating values that require a ZPageAge in the future. Since the end of the enum iterators are exclusive, I've opted to use the following value as end for the iterators:
> 
> constexpr ZPageAge ZPageAgeLastPlusOne = static_cast<ZPageAge>(ZPageAgeCount);
> 
> 
> I see us using either this or a sentinel/dummy value at the end of the enum class, but I prefer having a value similar to `ZPageAgeLastPlusOne` over a dummy value.
> 
> Testing:
> * Oracle's tier 1-4
> * GHA

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

 - ZPageAgeRange iterators gtest
 - checkedCast include

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25251/files
  - new: https://git.openjdk.org/jdk/pull/25251/files/3243a67a..653b4015

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

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

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

From jsikstro at openjdk.org  Wed Jun  4 11:58:02 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 4 Jun 2025 11:58:02 GMT
Subject: RFR: 8357053: ZGC: Improved utility for ZPageAge [v7]
In-Reply-To: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
References: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
Message-ID: <nWT7yhurYhZbHTgLHdEDxVtTSsWXbRdYyPLOJAHUJ6k=.0ee4cfcc-6b40-4f7b-ac15-4abc1967fca6@github.com>

> Hello,
> 
> This RFE improves utility for converting to/from, iterating over and defining structures that are indexed using the `ZPageAge` type.
> 
> Converting to/from ZPageAge and its underlying type (uint8_t, often just uint) is currently done via using static_cast. This works fine because sane values are converted in all use cases. However, to make conversion safer (and also more readable), I propose we add a `to_zpageage` and a corresponding `untype` that checks that the conversion is valid. Such conversion methods should be used instead of calling `static_cast<uint/ZPageAge>`.
> 
> We currently define a value called `ZPageAgeMax`, which is defined as `static_cast<uint>(ZPageAge::old)`. The majority of places that use this value actualy use `ZPageAgeMax + 1`, which is equivalent to the number of ages. Instead, I propose we define and use a value that represents the number of possible ages, called `ZPageAgeCount`.
> 
> Lastly, to make iterating over ages more accessible, I propose we create an intreface of enum iterators of ZPageAge. This will also create a foundation for generating values that require a ZPageAge in the future. Since the end of the enum iterators are exclusive, I've opted to use the following value as end for the iterators:
> 
> constexpr ZPageAge ZPageAgeLastPlusOne = static_cast<ZPageAge>(ZPageAgeCount);
> 
> 
> I see us using either this or a sentinel/dummy value at the end of the enum class, but I prefer having a value similar to `ZPageAgeLastPlusOne` over a dummy value.
> 
> Testing:
> * Oracle's tier 1-4
> * GHA

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

  Fix include format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25251/files
  - new: https://git.openjdk.org/jdk/pull/25251/files/653b4015..81428965

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

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

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

From sjohanss at openjdk.org  Wed Jun  4 12:03:21 2025
From: sjohanss at openjdk.org (Stefan Johansson)
Date: Wed, 4 Jun 2025 12:03:21 GMT
Subject: RFR: 8357053: ZGC: Improved utility for ZPageAge [v7]
In-Reply-To: <nWT7yhurYhZbHTgLHdEDxVtTSsWXbRdYyPLOJAHUJ6k=.0ee4cfcc-6b40-4f7b-ac15-4abc1967fca6@github.com>
References: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
 <nWT7yhurYhZbHTgLHdEDxVtTSsWXbRdYyPLOJAHUJ6k=.0ee4cfcc-6b40-4f7b-ac15-4abc1967fca6@github.com>
Message-ID: <gk_9Y7NL78QbTij6D9E2ZWFvgpD9-K4vAcAFD1uI7Co=.de3507eb-4d8d-44f4-ab51-539bc2721154@github.com>

On Wed, 4 Jun 2025 11:58:02 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> This RFE improves utility for converting to/from, iterating over and defining structures that are indexed using the `ZPageAge` type.
>> 
>> Converting to/from ZPageAge and its underlying type (uint8_t, often just uint) is currently done via using static_cast. This works fine because sane values are converted in all use cases. However, to make conversion safer (and also more readable), I propose we add a `to_zpageage` and a corresponding `untype` that checks that the conversion is valid. Such conversion methods should be used instead of calling `static_cast<uint/ZPageAge>`.
>> 
>> We currently define a value called `ZPageAgeMax`, which is defined as `static_cast<uint>(ZPageAge::old)`. The majority of places that use this value actualy use `ZPageAgeMax + 1`, which is equivalent to the number of ages. Instead, I propose we define and use a value that represents the number of possible ages, called `ZPageAgeCount`.
>> 
>> Lastly, to make iterating over ages more accessible, I propose we create an intreface of enum iterators of ZPageAge. This will also create a foundation for generating values that require a ZPageAge in the future. Since the end of the enum iterators are exclusive, I've opted to use the following value as end for the iterators:
>> 
>> constexpr ZPageAge ZPageAgeLastPlusOne = static_cast<ZPageAge>(ZPageAgeCount);
>> 
>> 
>> I see us using either this or a sentinel/dummy value at the end of the enum class, but I prefer having a value similar to `ZPageAgeLastPlusOne` over a dummy value.
>> 
>> Testing:
>> * Oracle's tier 1-4
>> * GHA
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix include format

Marked as reviewed by sjohanss (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25251#pullrequestreview-2896460809

From iwalulya at openjdk.org  Wed Jun  4 13:46:49 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 4 Jun 2025 13:46:49 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
Message-ID: <wapZubk6ap_j1vtGBHDOTaQWOCFfTeUat6HOMbYXq2s=.c67059b6-edf7-469b-b068-bd312450bd58@github.com>

On Tue, 3 Jun 2025 09:10:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
> 
> Test: tier1

I would advocate for moving more APIs into `G1HeapRegionManager` instead of adding more to `G1CollectedHeap`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2940101833

From iwalulya at openjdk.org  Wed Jun  4 13:51:57 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 4 Jun 2025 13:51:57 GMT
Subject: RFR: 8358294: Remove unnecessary GenAlignment
In-Reply-To: <i_uMl0YdxEjg4Qjs8GuNOVhRRJTAY4uFx52guCmxS3o=.aa817c34-8586-4fbf-83ed-cf22f5df3b23@github.com>
References: <i_uMl0YdxEjg4Qjs8GuNOVhRRJTAY4uFx52guCmxS3o=.aa817c34-8586-4fbf-83ed-cf22f5df3b23@github.com>
Message-ID: <Mg2mrZfw7_OSTgfLW5sEmFyLiWACJtaKd3X3wkQB2jc=.869ab71d-5e27-442d-8407-5a68edfa6181@github.com>

On Mon, 2 Jun 2025 08:36:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple replacement of `GenAlignment` with `SpaceAlignment`, because they always have the same value. Removing the former to reduce complexity.
> 
> Test: tier1-3

LGTM!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25577#pullrequestreview-2896822028

From stefank at openjdk.org  Wed Jun  4 14:59:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 4 Jun 2025 14:59:00 GMT
Subject: RFR: 8357443: ZGC: Optimize old page iteration in remap remembered
 phase [v2]
In-Reply-To: <BiDuiVqO9Bk2GIfGnIi01tthkrLWNWqRm75q17pl1sk=.a5800a36-57f0-4fe6-8338-d9af08065278@github.com>
References: <d0Dwccxt8gZ3Kdyz-SBi6Vy_zAkbPwyWVgxWbXiLx7U=.d8a9ff80-2a37-4db4-b631-705480e8272f@github.com>
 <BiDuiVqO9Bk2GIfGnIi01tthkrLWNWqRm75q17pl1sk=.a5800a36-57f0-4fe6-8338-d9af08065278@github.com>
Message-ID: <MxOTp71GiJ92yD2sn0lB9vEzltZWKYtoeBPZvQ13xLE=.fd98b0da-7d92-487e-8f57-6b27fd337390@github.com>

On Wed, 21 May 2025 12:45:09 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Before starting the relocation phase of a major collection we remap all pointers into the young generation so that we can disambiguate when an oop has bad bits for both the young generation and the old generation. See comment in remap_young_roots.
>> 
>> One part of this is requires us to visit all old pages. To parallelize that part we have a class that distribute indices to the page table to the GC worker threads (See ZIndexDistributor).
>> 
>> While looking into a potential, minor performance regression on Windows I noticed that the usage of constexpr in ZIndexDistributorClaimTree wasn't giving us the inlining we hoped for, which caused a noticeable worse performance on Windows compared to the other platforms. I created a patch for this that gave us the expected inlining. See https://github.com/openjdk/jdk/compare/master...stefank:jdk:8357443_zgc_optimize_remap_remembered
>> 
>> While thinking about this a bit more I realized that we could use the "found old" optimization that we already use for the remset scanning. This finds the old pages without scanning the entire page table. This gives a significant enough boost that I propose that we do that instead. 
>> 
>> This mainly lowers the Major Collection times when you run a GC without any significant amount of objects in the old generation. So, most likely mostly important for micro benchmarks and small workloads.
>> 
>> The below is the average time (ms) of the Concurrent Remap Roots phase from only running `System.gc()` 50 times before and after this PR.
>> 
>> 
>> 4 GB MaxHeapSize
>>                     Original       Patch
>> Default threads
>> 
>> mac:                0.27812        0.0507
>> win:                0.9485         0.10452
>> linux-x64:          0.53858        0.092
>> linux-x64 NUMA:     0.89974        0.15452
>> linux-aarch64:      0.32574        0.15832
>> 
>> 4 threads
>> 
>> mac:                0.19112        0.04916
>> win:                0.83346        0.08796
>> linux-x64:          0.57692        0.09526
>> linux-x64 NUMA:     1.23684        0.17008
>> linux-aarch64:      0.334          0.21918
>> 
>> 1 thread:
>> 
>> mac:                0.19678        0.0589
>> win:                1.96496        0.09928
>> linux-x64:          1.00788        0.1381
>> linux-x64 NUMA:     2.77312        0.21134
>> linux-aarch64:      0.63696        0.31286
>> 
>> 
>> The second set of data is from using the extreme end of the supported heap size. This mimics how we previously used to have a large page table even for smaller heap size ...
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Axel Boldt-Christmas <xmas1915 at gmail.com>

We decided to leave the ZIndexDistributor infrastructure in-place including the small additional extension to the page table. We might make some change in JDK 26, or later, to convert the distributor to work over the extended range internally but only hand out indices in the requested range. That way we could get rid of the current over head and still keep the current implementation.

I've merged locally and run that true a large set of our testing so I'm going integrate this now.

Thanks for all the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25345#issuecomment-2940362856

From stefank at openjdk.org  Wed Jun  4 14:59:03 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 4 Jun 2025 14:59:03 GMT
Subject: Integrated: 8357443: ZGC: Optimize old page iteration in remap
 remembered phase
In-Reply-To: <d0Dwccxt8gZ3Kdyz-SBi6Vy_zAkbPwyWVgxWbXiLx7U=.d8a9ff80-2a37-4db4-b631-705480e8272f@github.com>
References: <d0Dwccxt8gZ3Kdyz-SBi6Vy_zAkbPwyWVgxWbXiLx7U=.d8a9ff80-2a37-4db4-b631-705480e8272f@github.com>
Message-ID: <HI04GM9ZBs7aUdNLEFdUo_3doG_njALtDrU55YAuCus=.23ccf91d-db82-482c-8a90-c53f6308bd38@github.com>

On Wed, 21 May 2025 09:49:52 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Before starting the relocation phase of a major collection we remap all pointers into the young generation so that we can disambiguate when an oop has bad bits for both the young generation and the old generation. See comment in remap_young_roots.
> 
> One part of this is requires us to visit all old pages. To parallelize that part we have a class that distribute indices to the page table to the GC worker threads (See ZIndexDistributor).
> 
> While looking into a potential, minor performance regression on Windows I noticed that the usage of constexpr in ZIndexDistributorClaimTree wasn't giving us the inlining we hoped for, which caused a noticeable worse performance on Windows compared to the other platforms. I created a patch for this that gave us the expected inlining. See https://github.com/openjdk/jdk/compare/master...stefank:jdk:8357443_zgc_optimize_remap_remembered
> 
> While thinking about this a bit more I realized that we could use the "found old" optimization that we already use for the remset scanning. This finds the old pages without scanning the entire page table. This gives a significant enough boost that I propose that we do that instead. 
> 
> This mainly lowers the Major Collection times when you run a GC without any significant amount of objects in the old generation. So, most likely mostly important for micro benchmarks and small workloads.
> 
> The below is the average time (ms) of the Concurrent Remap Roots phase from only running `System.gc()` 50 times before and after this PR.
> 
> 
> 4 GB MaxHeapSize
>                     Original       Patch
> Default threads
> 
> mac:                0.27812        0.0507
> win:                0.9485         0.10452
> linux-x64:          0.53858        0.092
> linux-x64 NUMA:     0.89974        0.15452
> linux-aarch64:      0.32574        0.15832
> 
> 4 threads
> 
> mac:                0.19112        0.04916
> win:                0.83346        0.08796
> linux-x64:          0.57692        0.09526
> linux-x64 NUMA:     1.23684        0.17008
> linux-aarch64:      0.334          0.21918
> 
> 1 thread:
> 
> mac:                0.19678        0.0589
> win:                1.96496        0.09928
> linux-x64:          1.00788        0.1381
> linux-x64 NUMA:     2.77312        0.21134
> linux-aarch64:      0.63696        0.31286
> 
> 
> The second set of data is from using the extreme end of the supported heap size. This mimics how we previously used to have a large page table even for smaller heap size (we don't do that anymore for JDK 25). It shows a quite significant difference, bu...

This pull request has now been integrated.

Changeset: c9092164
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c90921644643bc731cab4c014a5144a74e670df1
Stats:     107 lines in 4 files changed: 49 ins; 14 del; 44 mod

8357443: ZGC: Optimize old page iteration in remap remembered phase

Reviewed-by: aboldtch, eosterlund

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

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

From stefank at openjdk.org  Wed Jun  4 15:01:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 4 Jun 2025 15:01:54 GMT
Subject: RFR: 8357533: ZGC: ZIndexDistributorClaimTree functions not
 inlined on Windows
In-Reply-To: <XeJkFPL45Aixq3YzlJjsQrNR_l2OmKew53Tw1tgyY6M=.76a49afc-c1ad-4fa5-9141-dea321a2d705@github.com>
References: <XeJkFPL45Aixq3YzlJjsQrNR_l2OmKew53Tw1tgyY6M=.76a49afc-c1ad-4fa5-9141-dea321a2d705@github.com>
Message-ID: <DG9dkywWdjabWrTdENKZl-CrD0bZFlU3wAlFlF9biuI=.081714f0-040c-4b33-81ee-898881079d8a@github.com>

On Thu, 22 May 2025 08:07:36 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> While investigating a minor performance regression in a System.gc() microbenchmark I saw that the Concurrent Remap Roots phase took a significant portion of the GC cycle time.
> 
> It turns out that even though we use constexpr we don't get the inlining of the the functions as we expected and this results in a noticeable performance loss.
> 
> When running System.gc() with on old GC worker thread with a 16TB max heap size we spend around 300 ms just iterating over the page table and its indices via ZIndexDistributorClaimTree. If the inlining is fixed this drops down to ~70 ms, which is similar to what we see on Linux and MacOS.
> 
> We already have a patch out to remove the last usage of the ZIndexDistributor mechanism in https://github.com/openjdk/jdk/pull/25345, but ZIndexDistributor has less restrictions and is easier to use so we might want to keep it around (with fixed performance) so that it can be used for prototyping and maybe future features.
> 
> Noteworthy in the patch is the following function:
> 
>   static constexpr int level_multiplier(int level) {
>     assert(level < ClaimLevels, "Must be");
>     constexpr int array[ClaimLevels]{16, 16, 16};
>     return array[level];
>   }
> 
> 
> When the last statement is changed to:
> 
>     constexpr int result = array[level];
>     return result;
> 
> 
> The MS compiler complains that the expression is not a constant. And if we get the correct inlining the warning goes away.
> 
> To get the required inlining I've changed the `level` parameter to be a template parameter and restructured the code to use template specialization instead of if-statements. This required some finagling with template classes to get partial specialization to work.
> 
> Some other changes in the patch:
> * Limited includes of zIndexDistributor.inline.hpp
> * Extracted the atomic inc into zfetch_then_inc for easier evaluation of the performance impact of our Atomic implementation vs relaxed std::atomic vs non-atomic updates.
> * Hid the logging under a compile-time define. The logging is useful when changing/debugging this code, but otherwise it is not.

Given that we have replaced the last actively used instance of this class, this is not urgent to get integrated into JDK 25. It also adds even more complexity to a already somewhat complex class. If we start to use C++ 17 we might be able to leverage if constexpr and thereby lower the extra complexity that this patch adds via template specializations. Let's postpone this PR and see if we get to C++ 17 soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25385#issuecomment-2940374196

From vromero at openjdk.org  Wed Jun  4 21:06:03 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Jun 2025 21:06:03 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of JavacTask::call
Message-ID: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>

Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.

TIA

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

Commit messages:
 - 8341778: Some javac tests ignore the result of task.call()

Changes: https://git.openjdk.org/jdk/pull/25645/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341778
  Stats: 136 lines in 33 files changed: 88 ins; 1 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/25645.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25645/head:pull/25645

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

From sangheki at openjdk.org  Wed Jun  4 23:23:50 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Wed, 4 Jun 2025 23:23:50 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <wapZubk6ap_j1vtGBHDOTaQWOCFfTeUat6HOMbYXq2s=.c67059b6-edf7-469b-b068-bd312450bd58@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <wapZubk6ap_j1vtGBHDOTaQWOCFfTeUat6HOMbYXq2s=.c67059b6-edf7-469b-b068-bd312450bd58@github.com>
Message-ID: <aZ1LGy5Xqkeo7mLY1gtdbo4715g02v4jBNZvbMYsCbs=.c3205db6-3633-43de-a12f-e2f3090a5db3@github.com>

On Wed, 4 Jun 2025 13:44:25 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
>> 
>> Test: tier1
>
> I would advocate for moving more APIs into `G1HeapRegionManager` instead of adding more to `G1CollectedHeap`.

I agree with @walulyai .
Adding convenient APIs on `G1CollectedHeap` is a matter of preference. But I dislike removing a basic API from `G1HeapRegionManager`. Maybe we disagree whether `num_available_regions() ` is a basic API or not?

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2941904091

From shade at openjdk.org  Thu Jun  5 06:20:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jun 2025 06:20:52 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

Looks good, but I have question about hunks that are not about wrapping `call()`-s. Those look like fixing the actual test bugs?

test/langtools/tools/javac/T6361619.java line 53:

> 51:         final PrintWriter out = new PrintWriter(System.err, true);
> 52: 
> 53:         Iterable<String> flags = Arrays.asList("--add-exports", "jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED",

Why `--add-exports`? Did this test actually failed without us noticing?

test/langtools/tools/javac/api/8007344/Test.java line 79:

> 77:     }
> 78: 
> 79:     static final List<String> OPTIONS = List.of(

Same question here...

test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 37:

> 35: public class SOEDeeplyNestedBlocksTest {
> 36: 
> 37:     static final int NESTING_DEPTH = 500;

Same question here.

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

PR Review: https://git.openjdk.org/jdk/pull/25645#pullrequestreview-2898988500
PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128026868
PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128036046
PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128036600

From duke at openjdk.org  Thu Jun  5 08:45:53 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 5 Jun 2025 08:45:53 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
Message-ID: <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>

On Thu, 5 Jun 2025 06:17:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
>> 
>> TIA
>
> test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 37:
> 
>> 35: public class SOEDeeplyNestedBlocksTest {
>> 36: 
>> 37:     static final int NESTING_DEPTH = 500;
> 
> Same question here.

With a NESTING_DEPTH of 1000 javac will run into a StackOverflowError, but it still completes and task.call() returns false. Using 500 javac can compile without error. Not sure what this test wants to prove. If it wants to show that javac can complete without throwing an SOE then it should keep depth 1000 and test that task.call() returns false.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128289861

From ayang at openjdk.org  Thu Jun  5 08:52:52 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 5 Jun 2025 08:52:52 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
Message-ID: <-3JWAPvOxgq-OUPynZ2MxBRPeawcS5kw2u--Ylvfpho=.80f5c2fc-daac-48c6-9d74-debfc1557d6b@github.com>

On Tue, 3 Jun 2025 09:10:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
> 
> Test: tier1

> Perhaps we disagree on whether `num_available_regions()` should be considered a basic API.

Thank you for the term; I was having a difficult time finding an accurate word for it. Since its implementation involves calculations based on other counters, I tend to view it as a "compound" API -- better suited at the level of the owner of `G1HeapRegionManager` rather than being part of its core interface. Hence, the suggestion in this PR.

(There are other "compound" APIs, e.g. `uint num_used_regions() const { return num_committed_regions() - num_free_regions(); }`, which I think also belongs to `G1CollectedHeap`.)

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2943305990

From vromero at openjdk.org  Thu Jun  5 13:36:53 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Jun 2025 13:36:53 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
Message-ID: <s_N1iZWcuOYjZcizoH25T0-do9ofLtPP2PIzN7l6Rn8=.24911151-5c9c-4efb-b16a-1f0ab93aa26b@github.com>

On Thu, 5 Jun 2025 06:09:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
>> 
>> TIA
>
> test/langtools/tools/javac/T6361619.java line 53:
> 
>> 51:         final PrintWriter out = new PrintWriter(System.err, true);
>> 52: 
>> 53:         Iterable<String> flags = Arrays.asList("--add-exports", "jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED",
> 
> Why `--add-exports`? Did this test actually failed without us noticing?

correct

> test/langtools/tools/javac/api/8007344/Test.java line 79:
> 
>> 77:     }
>> 78: 
>> 79:     static final List<String> OPTIONS = List.of(
> 
> Same question here...

same answer here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128873770
PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128874248

From vromero at openjdk.org  Thu Jun  5 13:40:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Jun 2025 13:40:50 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
 <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>
Message-ID: <2pqPINy6ZfLEKR0ekTYpnb6wE4LjD33XpwNHyfyihSQ=.706552b9-4cdf-459f-ac05-d44f8d4de0fb@github.com>

On Thu, 5 Jun 2025 08:43:04 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> test/langtools/tools/javac/patterns/SOEDeeplyNestedBlocksTest.java line 37:
>> 
>>> 35: public class SOEDeeplyNestedBlocksTest {
>>> 36: 
>>> 37:     static final int NESTING_DEPTH = 500;
>> 
>> Same question here.
>
> With a NESTING_DEPTH of 1000 javac will run into a StackOverflowError, but it still completes and task.call() returns false. Using 500 javac can compile without error. Not sure what this test wants to prove. If it wants to show that javac can complete without throwing an SOE then it should keep depth 1000 and test that task.call() returns false.

yes this one was failing quietly, this test is stressing a code that was modified due to pattern matching. It is testing that javac can deal with deeply nested code without throwing SOE. 1000 depth was too much and the test was quietly failing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2128881821

From shade at openjdk.org  Thu Jun  5 14:47:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jun 2025 14:47:53 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <smC66b1OtFEnSnoWRJz7SmNgdh-aweN-d9E98pWr_ws=.89cd6dd5-5ac1-44dc-9efa-c5114a9660c3@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25645#pullrequestreview-2900652359

From shade at openjdk.org  Thu Jun  5 14:57:52 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Jun 2025 14:57:52 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <qtVEVdzBqtyzn-FhvBPObmqZoV78pLBeesLy_onMI0o=.75d2b39a-5764-4b13-a161-7aa5709c6e92@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

I believe we are still not in RDP1? Do you want to get it in JDK 25? Put `Fix-Versions: 25` into the bug and integrate, if so.

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

PR Comment: https://git.openjdk.org/jdk/pull/25645#issuecomment-2944885496

From duke at openjdk.org  Thu Jun  5 15:33:07 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Thu, 5 Jun 2025 15:33:07 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <2pqPINy6ZfLEKR0ekTYpnb6wE4LjD33XpwNHyfyihSQ=.706552b9-4cdf-459f-ac05-d44f8d4de0fb@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
 <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>
 <2pqPINy6ZfLEKR0ekTYpnb6wE4LjD33XpwNHyfyihSQ=.706552b9-4cdf-459f-ac05-d44f8d4de0fb@github.com>
Message-ID: <psJrCA9Drc8jxurvsmYlMAp7fbzswjCpzuqAhVbmqjY=.e0c8f601-7a79-4a7f-934d-d283f3c7e55c@github.com>

On Thu, 5 Jun 2025 13:38:08 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> It is testing that javac can deal with deeply nested code without throwing SOE.

The current summary `Javac fails with StackOverflowError when compiling deeply nested synchronized blocks` is confusing and I don't know how it relates to your statement. Does it describe a bug or does it state the purpose of the test? Anyway, why not test with nesting levels of 500 and 1000, assert that task.call() returns true (500) and false (1000), but in the later case does not panic and terminate with a SOE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2129132057

From vromero at openjdk.org  Thu Jun  5 15:46:55 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Jun 2025 15:46:55 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <qtVEVdzBqtyzn-FhvBPObmqZoV78pLBeesLy_onMI0o=.75d2b39a-5764-4b13-a161-7aa5709c6e92@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <qtVEVdzBqtyzn-FhvBPObmqZoV78pLBeesLy_onMI0o=.75d2b39a-5764-4b13-a161-7aa5709c6e92@github.com>
Message-ID: <ELd5ZJQjxyktNWTvuvX9A1dlqoBw4ten8RXZcX9ghF4=.8434c8dc-bd45-424b-89ab-ed589378d855@github.com>

On Thu, 5 Jun 2025 14:55:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I believe we are still not in RDP1? Do you want to get it in JDK 25? Put `Fix-Versions: 25` into the bug and integrate, if so.

I prefer to wait until 26, this is not a high priority issue

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

PR Comment: https://git.openjdk.org/jdk/pull/25645#issuecomment-2945037398

From kvn at openjdk.org  Thu Jun  5 15:50:52 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 5 Jun 2025 15:50:52 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <zdd_y_bOXb3iSCYx5cfH62GrC_VX4HoVA5rmXeP4TiI=.a1e9a5fd-0618-41e1-a4d5-1386947f2ed5@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

Tests P1-P5 can be fixed during RDP1 and RDP2: https://openjdk.org/jeps/3#rdp-2

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

PR Comment: https://git.openjdk.org/jdk/pull/25645#issuecomment-2945058626

From vromero at openjdk.org  Thu Jun  5 17:00:50 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 5 Jun 2025 17:00:50 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <psJrCA9Drc8jxurvsmYlMAp7fbzswjCpzuqAhVbmqjY=.e0c8f601-7a79-4a7f-934d-d283f3c7e55c@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
 <Xy9h4x6NoMh-gluj4lAI3y2cbilN7yo6TxwXr95nYcc=.8c7cde0a-01b1-4d81-b66c-699983a97d92@github.com>
 <k0qxka0WLTfqJExQTHpG6-1WvLc1t5StBbL6z73DDqQ=.3f8edd92-d86f-4b7d-bb72-721823a54954@github.com>
 <2pqPINy6ZfLEKR0ekTYpnb6wE4LjD33XpwNHyfyihSQ=.706552b9-4cdf-459f-ac05-d44f8d4de0fb@github.com>
 <psJrCA9Drc8jxurvsmYlMAp7fbzswjCpzuqAhVbmqjY=.e0c8f601-7a79-4a7f-934d-d283f3c7e55c@github.com>
Message-ID: <imSAmt4PvkDKbw9KD6B9TEP4ysPjif1ezOS2Su6_yqQ=.e6e74503-9b04-41ff-9658-b07e21d3aad4@github.com>

On Thu, 5 Jun 2025 15:30:30 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> yes this one was failing quietly, this test is stressing a code that was modified due to pattern matching. It is testing that javac can deal with deeply nested code without throwing SOE. 1000 depth was too much and the test was quietly failing
>
>> It is testing that javac can deal with deeply nested code without throwing SOE.
> 
> The current summary `Javac fails with StackOverflowError when compiling deeply nested synchronized blocks` is confusing and I don't know how it relates to your statement. Does it describe a bug or does it state the purpose of the test? Anyway, why not test with nesting levels of 500 and 1000, assert that task.call() returns true (500) and false (1000), but in the later case does not panic and terminate with a SOE.

the original version of the test was included as part of the fix for [1] as you can see in the related PR [2] method com.sun.tools.javac.jvm.Gen::visitBlock was being visiting every block assuming that every one of them had pattern matching expressions in it. This implied a visitBlock with a higher number of local variables even for 90-98% of blocks that didn't have any pattern matching in them. So the test is checking that javac is not failing with SOE while generating code for a method with deeply nested blocks. Testing that javac will produce SOE after a given threshold is passed adds no information as there always be resource limit for any process. This is why I don't see the value of having a test that passes that threshold, which by the way could move over time and then we will need to go back and fix the test. While on the other hand having a test that will keep javac in check, as in being able to still compile without issues a nested enough code, seems more valuable to me.

[1] https://bugs.openjdk.org/browse/JDK-8322992
[2] https://github.com/openjdk/jdk/pull/18832

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25645#discussion_r2129342988

From vromero at openjdk.org  Fri Jun  6 14:14:56 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 6 Jun 2025 14:14:56 GMT
Subject: RFR: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <y6J0-1CWYt8Q48BL5g8plhbKxTCPBSjvUt3Olrkhd_s=.4594fff1-7b4c-4850-95f9-55f7aff92ea7@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

thanks for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/25645#issuecomment-2949388176

From vromero at openjdk.org  Fri Jun  6 14:14:57 2025
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 6 Jun 2025 14:14:57 GMT
Subject: Integrated: 8341778: Some javac tests ignore the result of
 JavacTask::call
In-Reply-To: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
References: <oVx3Ta9gXWblZKT2FlFvvOQWhoT_xKceQh4Wsyf5XOs=.c1ab5fdb-ae2f-49d3-8c60-6497fcbe33e4@github.com>
Message-ID: <jvckILM3CMCuJfcEoSbR9ASnJ5w9YecYkKz-tF5DvrA=.b4cee1d2-b5b1-4fa7-b7b7-41dca24fe01b@github.com>

On Wed, 4 Jun 2025 21:02:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Several tests are ignoring the result of invoking com.sun.source.util.JavacTask::call which returns a `Boolean`. This implies that tests could seem to pass when in reality they are silently failing. This PR is fixing this issue by checking, in all applicable cases the result of the invocation.
> 
> TIA

This pull request has now been integrated.

Changeset: 8adb052b
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8adb052b46f90e8a0605cfc5ddc667acb7c61952
Stats:     136 lines in 33 files changed: 88 ins; 1 del; 47 mod

8341778: Some javac tests ignore the result of JavacTask::call

Reviewed-by: shade

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

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

From sangheki at openjdk.org  Fri Jun  6 16:58:51 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Fri, 6 Jun 2025 16:58:51 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <-3JWAPvOxgq-OUPynZ2MxBRPeawcS5kw2u--Ylvfpho=.80f5c2fc-daac-48c6-9d74-debfc1557d6b@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <-3JWAPvOxgq-OUPynZ2MxBRPeawcS5kw2u--Ylvfpho=.80f5c2fc-daac-48c6-9d74-debfc1557d6b@github.com>
Message-ID: <MoeMgs8ze0nTgfxi4LUFc_JDovmTOJ5WNJklVHMWdSU=.c874e7d1-9695-44cd-9512-be135371684b@github.com>

On Thu, 5 Jun 2025 08:50:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
>> 
>> Test: tier1
>
>> Perhaps we disagree on whether `num_available_regions()` should be considered a basic API.
> 
> Thank you for the term; I was having a difficult time finding an accurate word for it. Since its implementation involves calculations based on other counters, I tend to view it as a "compound" API -- better suited at the level of the owner of `G1HeapRegionManager` rather than being part of its core interface. Hence, the suggestion in this PR.
> 
> (There are other "compound" APIs, e.g. `uint num_used_regions() const { return num_committed_regions() - num_free_regions(); }`, which I think also belongs to `G1CollectedHeap`.)

I like the term 'compound' API, but still I cannot fully agree with you, @albertnetymk. e.g. if there is other user of `G1HeapRegionManager`, the new one also needs to implement such compound API again.
I do not want to block you if others agree with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2949872087

From iwalulya at openjdk.org  Sat Jun  7 08:29:50 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Sat, 7 Jun 2025 08:29:50 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
Message-ID: <-fZ7LKXeyExJMNfv23F2OyYUca0deHxra59DDa2hhlo=.3252fd09-365d-4efc-ab84-9821d53725bc@github.com>

On Tue, 3 Jun 2025 09:10:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
> 
> Test: tier1

Is there any benefit to implementing these helper functions for `_hrm` in `G1CollectedHeap` instead of having callers directly call the methods in  `_hrm` through an accesser `G1CollectedHeap::hrm()`? I see  thatwe implement many helper functions that just call similarly named methods on `_hrm`.

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2952155570

From rcastanedalo at openjdk.org  Mon Jun  9 06:26:02 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 9 Jun 2025 06:26:02 GMT
Subject: RFR: 8345067: C2: enable implicit null checks for ZGC reads [v6]
In-Reply-To: <PY3Iz0lf3R7dmuZIBIJjUoSaGyvsGozbdTmqhb88hDk=.837c1b64-e316-4cc3-b316-68aaab1f0e16@github.com>
References: <7hA9KtNbFc-SIekCv7cz2iZHgZY84B-6R4tV83brIEs=.ebc8186c-a645-4215-86cd-836f9cb5e916@github.com>
 <PY3Iz0lf3R7dmuZIBIJjUoSaGyvsGozbdTmqhb88hDk=.837c1b64-e316-4cc3-b316-68aaab1f0e16@github.com>
Message-ID: <U275NnVa4byuEqxBMrZTmVjJPEfr8K3a61bybkWHDpU=.3ccd9a8a-f5fb-4f4a-9ab9-d565d6034736@github.com>

On Tue, 27 May 2025 07:46:43 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

>> Currently, C2 cannot exploit late-expanded GC memory accesses as implicit null checks because of their use of temporary operands (`MachTemp`), which prevents `PhaseCFG::implicit_null_check` from [hoisting the memory accesses to the test basic block](https://github.com/openjdk/jdk/blob/f88c1c6ff86b8f29a71647e46136b6432bb67619/src/hotspot/share/opto/lcm.cpp#L319-L335).
>> 
>> This changeset extends the scope of the implicit null check optimization so that it can exploit ZGC object loads. It introduces a platform-dependent predicate (`MachNode::is_late_expanded_null_check_candidate`) to mark late-expanded instructions that emit a suitable memory access as a first instruction as candidates, and extends the optimization to recognize and hoist candidate memory accesses that use temporary operands:
>> 
>> ![example](https://github.com/user-attachments/assets/b5f9bbc8-d75d-4cf3-841e-73db3dbae753)
>> 
>> ZGC object loads are marked as late-expanded null-check candidates unconditionally on all ZGC-supported platforms except on aarch64, where only loads that do not require an initial `lea` instruction (due to [address legitimization](https://github.com/openjdk/jdk/blob/ddd07b107e814ec846579a66d4f2005b7db9bb2f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L132-L144)) are marked as candidates. Fortunately, most aarch64 loads seen in practice use small offsets and can be marked as candidates.
>> 
>> Exploiting ZGC loads increases the effectiveness of the implicit null check optimization (percent of explicit null checks turned into implicit ones at compile time) by around 10% in the DaCapo23 benchmarks. This results in slight performance improvements (in the 1-2% range) in a few DaCapo and SPECjvm2008 benchmarks and an overall slight improvement across Renaissance benchmarks.
>> 
>> #### Testing
>> - tier1-5, compiler stress test (linux-x64, macosx-x64, windows-x64, linux-aarch64, macosx-aarch64; release and debug mode).
>
> Roberto Casta?eda Lozano has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Include address mode test in 'legitimize_address'
>  - Excluded IR checks for testLoadVolatile on PPC64

Thanks everyone for reviewing and testing!

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

PR Comment: https://git.openjdk.org/jdk/pull/25066#issuecomment-2954772006

From rcastanedalo at openjdk.org  Mon Jun  9 06:26:03 2025
From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano)
Date: Mon, 9 Jun 2025 06:26:03 GMT
Subject: Integrated: 8345067: C2: enable implicit null checks for ZGC reads
In-Reply-To: <7hA9KtNbFc-SIekCv7cz2iZHgZY84B-6R4tV83brIEs=.ebc8186c-a645-4215-86cd-836f9cb5e916@github.com>
References: <7hA9KtNbFc-SIekCv7cz2iZHgZY84B-6R4tV83brIEs=.ebc8186c-a645-4215-86cd-836f9cb5e916@github.com>
Message-ID: <dJ1WKVq75hqWpq6EUwwFZ9jcoBUpf52MFlw62dMVB4Y=.1e2aa2c3-31d2-476c-8565-55c03b8be7f3@github.com>

On Tue, 6 May 2025 13:28:28 GMT, Roberto Casta?eda Lozano <rcastanedalo at openjdk.org> wrote:

> Currently, C2 cannot exploit late-expanded GC memory accesses as implicit null checks because of their use of temporary operands (`MachTemp`), which prevents `PhaseCFG::implicit_null_check` from [hoisting the memory accesses to the test basic block](https://github.com/openjdk/jdk/blob/f88c1c6ff86b8f29a71647e46136b6432bb67619/src/hotspot/share/opto/lcm.cpp#L319-L335).
> 
> This changeset extends the scope of the implicit null check optimization so that it can exploit ZGC object loads. It introduces a platform-dependent predicate (`MachNode::is_late_expanded_null_check_candidate`) to mark late-expanded instructions that emit a suitable memory access as a first instruction as candidates, and extends the optimization to recognize and hoist candidate memory accesses that use temporary operands:
> 
> ![example](https://github.com/user-attachments/assets/b5f9bbc8-d75d-4cf3-841e-73db3dbae753)
> 
> ZGC object loads are marked as late-expanded null-check candidates unconditionally on all ZGC-supported platforms except on aarch64, where only loads that do not require an initial `lea` instruction (due to [address legitimization](https://github.com/openjdk/jdk/blob/ddd07b107e814ec846579a66d4f2005b7db9bb2f/src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp#L132-L144)) are marked as candidates. Fortunately, most aarch64 loads seen in practice use small offsets and can be marked as candidates.
> 
> Exploiting ZGC loads increases the effectiveness of the implicit null check optimization (percent of explicit null checks turned into implicit ones at compile time) by around 10% in the DaCapo23 benchmarks. This results in slight performance improvements (in the 1-2% range) in a few DaCapo and SPECjvm2008 benchmarks and an overall slight improvement across Renaissance benchmarks.
> 
> #### Testing
> - tier1-5, compiler stress test (linux-x64, macosx-x64, windows-x64, linux-aarch64, macosx-aarch64; release and debug mode).

This pull request has now been integrated.

Changeset: 91f12600
Author:    Roberto Casta?eda Lozano <rcastanedalo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91f12600d2b188ca98c5c575a34b85f5835399a0
Stats:     401 lines in 16 files changed: 347 ins; 38 del; 16 mod

8345067: C2: enable implicit null checks for ZGC reads

Reviewed-by: aboldtch, kvn, epeter

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

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

From jsikstro at openjdk.org  Mon Jun  9 09:06:49 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 9 Jun 2025 09:06:49 GMT
Subject: RFR: 8357053: ZGC: Improved utility for ZPageAge [v8]
In-Reply-To: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
References: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
Message-ID: <BatYns9Ud53xcEnro4Oplre63C82cnOKjFpAtoVtdYw=.0cf3437a-6dca-4912-bbcb-ea1250346682@github.com>

> Hello,
> 
> This RFE improves utility for converting to/from, iterating over and defining structures that are indexed using the `ZPageAge` type.
> 
> Converting to/from ZPageAge and its underlying type (uint8_t, often just uint) is currently done via using static_cast. This works fine because sane values are converted in all use cases. However, to make conversion safer (and also more readable), I propose we add a `to_zpageage` and a corresponding `untype` that checks that the conversion is valid. Such conversion methods should be used instead of calling `static_cast<uint/ZPageAge>`.
> 
> We currently define a value called `ZPageAgeMax`, which is defined as `static_cast<uint>(ZPageAge::old)`. The majority of places that use this value actualy use `ZPageAgeMax + 1`, which is equivalent to the number of ages. Instead, I propose we define and use a value that represents the number of possible ages, called `ZPageAgeCount`.
> 
> Lastly, to make iterating over ages more accessible, I propose we create an intreface of enum iterators of ZPageAge. This will also create a foundation for generating values that require a ZPageAge in the future. Since the end of the enum iterators are exclusive, I've opted to use the following value as end for the iterators:
> 
> constexpr ZPageAge ZPageAgeLastPlusOne = static_cast<ZPageAge>(ZPageAgeCount);
> 
> 
> I see us using either this or a sentinel/dummy value at the end of the enum class, but I prefer having a value similar to `ZPageAgeLastPlusOne` over a dummy value.
> 
> Testing:
> * Oracle's tier 1-4
> * GHA

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 15 commits:

 - Merge branch 'master' into JDK-8357053_zpageage_utility
 - Fix include format
 - ZPageAgeRange iterators gtest
 - checkedCast include
 - Merge branch 'master' into JDK-8357053_zpageage_utility
 - Remove redundant access specifier
 - Include order
 - Style fix :)
 - Added operator+/- for ZPageAge
 - Fix include order in enumIterator.hpp
 - ... and 5 more: https://git.openjdk.org/jdk/compare/52338c94...575593ff

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

Changes: https://git.openjdk.org/jdk/pull/25251/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25251&range=07
  Stats: 200 lines in 14 files changed: 142 ins; 9 del; 49 mod
  Patch: https://git.openjdk.org/jdk/pull/25251.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25251/head:pull/25251

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

From jsikstro at openjdk.org  Mon Jun  9 09:06:50 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 9 Jun 2025 09:06:50 GMT
Subject: RFR: 8357053: ZGC: Improved utility for ZPageAge [v7]
In-Reply-To: <nWT7yhurYhZbHTgLHdEDxVtTSsWXbRdYyPLOJAHUJ6k=.0ee4cfcc-6b40-4f7b-ac15-4abc1967fca6@github.com>
References: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
 <nWT7yhurYhZbHTgLHdEDxVtTSsWXbRdYyPLOJAHUJ6k=.0ee4cfcc-6b40-4f7b-ac15-4abc1967fca6@github.com>
Message-ID: <BktGm8mFjDyfy3l3Ufwd7r_EG1ROtLAKOdSVuksCbUs=.d909e572-aa0d-4225-bceb-51335bea97a4@github.com>

On Wed, 4 Jun 2025 11:58:02 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> This RFE improves utility for converting to/from, iterating over and defining structures that are indexed using the `ZPageAge` type.
>> 
>> Converting to/from ZPageAge and its underlying type (uint8_t, often just uint) is currently done via using static_cast. This works fine because sane values are converted in all use cases. However, to make conversion safer (and also more readable), I propose we add a `to_zpageage` and a corresponding `untype` that checks that the conversion is valid. Such conversion methods should be used instead of calling `static_cast<uint/ZPageAge>`.
>> 
>> We currently define a value called `ZPageAgeMax`, which is defined as `static_cast<uint>(ZPageAge::old)`. The majority of places that use this value actualy use `ZPageAgeMax + 1`, which is equivalent to the number of ages. Instead, I propose we define and use a value that represents the number of possible ages, called `ZPageAgeCount`.
>> 
>> Lastly, to make iterating over ages more accessible, I propose we create an intreface of enum iterators of ZPageAge. This will also create a foundation for generating values that require a ZPageAge in the future. Since the end of the enum iterators are exclusive, I've opted to use the following value as end for the iterators:
>> 
>> constexpr ZPageAge ZPageAgeLastPlusOne = static_cast<ZPageAge>(ZPageAgeCount);
>> 
>> 
>> I see us using either this or a sentinel/dummy value at the end of the enum class, but I prefer having a value similar to `ZPageAgeLastPlusOne` over a dummy value.
>> 
>> Testing:
>> * Oracle's tier 1-4
>> * GHA
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix include format

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25251#issuecomment-2955146716

From jsikstro at openjdk.org  Mon Jun  9 09:06:51 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 9 Jun 2025 09:06:51 GMT
Subject: Integrated: 8357053: ZGC: Improved utility for ZPageAge
In-Reply-To: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
References: <T412oAu8Oxl6EJ7Wy7H-lJLvy9KVI9YF-cAMHWJ5iE4=.44a012bf-2599-4131-9811-3a5c01e68c37@github.com>
Message-ID: <k946wpG-T2T6DJ_QLWoUZwlmTcXeRIhT6Cyz_Z3RMBY=.f1440a15-c236-4e82-9644-4b15021a431b@github.com>

On Thu, 15 May 2025 13:59:29 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This RFE improves utility for converting to/from, iterating over and defining structures that are indexed using the `ZPageAge` type.
> 
> Converting to/from ZPageAge and its underlying type (uint8_t, often just uint) is currently done via using static_cast. This works fine because sane values are converted in all use cases. However, to make conversion safer (and also more readable), I propose we add a `to_zpageage` and a corresponding `untype` that checks that the conversion is valid. Such conversion methods should be used instead of calling `static_cast<uint/ZPageAge>`.
> 
> We currently define a value called `ZPageAgeMax`, which is defined as `static_cast<uint>(ZPageAge::old)`. The majority of places that use this value actualy use `ZPageAgeMax + 1`, which is equivalent to the number of ages. Instead, I propose we define and use a value that represents the number of possible ages, called `ZPageAgeCount`.
> 
> Lastly, to make iterating over ages more accessible, I propose we create an intreface of enum iterators of ZPageAge. This will also create a foundation for generating values that require a ZPageAge in the future. Since the end of the enum iterators are exclusive, I've opted to use the following value as end for the iterators:
> 
> constexpr ZPageAge ZPageAgeLastPlusOne = static_cast<ZPageAge>(ZPageAgeCount);
> 
> 
> I see us using either this or a sentinel/dummy value at the end of the enum class, but I prefer having a value similar to `ZPageAgeLastPlusOne` over a dummy value.
> 
> Testing:
> * Oracle's tier 1-4
> * GHA

This pull request has now been integrated.

Changeset: 1c72b350
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c72b350e417bd210dc6b66eba5afe0e3bc6306c
Stats:     200 lines in 14 files changed: 142 ins; 9 del; 49 mod

8357053: ZGC: Improved utility for ZPageAge

Co-authored-by: Axel Boldt-Christmas <aboldtch at openjdk.org>
Reviewed-by: sjohanss, stefank

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

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

From jsikstro at openjdk.org  Mon Jun  9 11:49:33 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 9 Jun 2025 11:49:33 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator
Message-ID: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>

Hello,

The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.

The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.

Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.

`ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.

`_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.

Testing:
* Oracle's tier 1-5

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

Commit messages:
 - 8358586: ZGC: Combine ZAllocator and ZObjectAllocator

Changes: https://git.openjdk.org/jdk/pull/25693/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25693&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8358586
  Stats: 363 lines in 12 files changed: 93 ins; 245 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/25693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25693/head:pull/25693

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

From kdnilsen at openjdk.org  Mon Jun  9 22:20:53 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 9 Jun 2025 22:20:53 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old [v3]
In-Reply-To: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
Message-ID: <oi5MtBcJNw6Og2K67C-_Pewmh91GBqp_K2aBWemPsQ0=.da5b47a3-5a3d-4a47-bdc3-1427aeb17ef3@github.com>

> Genshen independently reserves memory to hold evacuations into young and old generations.  We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young).
> 
> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle.  In this case, we can share the young collector reserves with the old generation.  This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity.
> 
> The following spreadsheet snapshots highlight the benefits of this change.  In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time).  This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young.  This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC.  In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive.  The total number of GC cycles decreases significantly.
> 
> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a)
> 
> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles.  By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles.  This reduces CPU load.  The impact on response times is not as significant as with the 6G heap size.  We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100.
> 
> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f)
> 
> At 8G heap size, the GC is not at all stressed.  We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100.
> 
> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c)
> 
> The command line for these comparisons follows:
> 
> 
>             ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \
>                 -XX:+Unlock...

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

  Fix assert_bounds() assertions when old_trash_not_in_bounds

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25357/files
  - new: https://git.openjdk.org/jdk/pull/25357/files/ae8c83c9..8ec6ea06

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

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

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

From ayang at openjdk.org  Tue Jun 10 08:40:14 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 10 Jun 2025 08:40:14 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v11]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <jXLMPtHTtErCCKB-y3II7TaNFSiv-h7saOS2McZH54w=.9f5ca2c5-3ca5-4fc3-9b01-528efb33c5ad@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - merge
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - ... and 6 more: https://git.openjdk.org/jdk/compare/7c9c8ba3...3a0502c3

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=10
  Stats: 4373 lines in 31 files changed: 522 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From tschatzl at openjdk.org  Tue Jun 10 13:16:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 10 Jun 2025 13:16:31 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
Message-ID: <n3nJ2iTkVfAQEr1rVEhFbc7fv5g8RH203XwAXBpDeDI=.4c12b70b-71d2-4872-a6b8-25290a94e529@github.com>

On Tue, 3 Jun 2025 09:10:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
> 
> Test: tier1

I think the idea of this change is okay; the change does not add additional API, just removes one from `G1HeapRegionManager`. Keeping the `G1HeapRegionManager` interface minimal is desirable.

The question rather seems to be who should implement that early exit in `G1HeapRegionManager::find_contiguous_allow_expand()`: foregoing the question whether putting this into `G1CollectedHeap` is better for now, but if one needs `num_available_regions` in `G1HeapRegionManager` anyway, it seems better to keep it there and just forward it to `G1CollectedHeap` instead of code duplication.

Trying to answer the question about the right place for that optimization: To mirror other code like `allocate_humongous()` which also has the special casing to avoid some expensive operation in `G1HeapRegionManager`, I would tend to keep the check there, and so my preference would be to keep the code as is. That special-casing does not fit in the suggested location too imo.
The expected outcome of the call to `expand_and_allocate_humongous`is some expensive memory operation too.

The situation for `num_used_regions()` is different, there is no benefit in having it in `G1HeapRegionManager` afaics, apart from maybe interface completeness.

> Is there any benefit to implementing these helper functions for _hrm in G1CollectedHeap instead of having callers directly call the methods in _hrm through an accesser G1CollectedHeap::hrm()? I see that we implement many helper functions that just call similarly named methods on _hrm.

In general though, I think we should not expose `G1HeapRegionManager` to other classes via the suggested `hrm()` getter because imo the region management (getting information about them, iteration) seems to be fairly central to the heap. `G1HeapRegionManager`to me is an integral part of the `CollectedHeap`, and only factored out into an extra class for convenience.

E.g. just like getting information about survivor/eden/old region numbers (e.g. `eden_regions_count()`), it would be a hassle to make everyone call different classes (e.g. `G1EdenRegions` for the example) to get such basic heap information.

What might improve the interface would be moving lots of these trivial forwarding/compound methods into the respective `.inline.hpp` file.

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2959220545

From tschatzl at openjdk.org  Tue Jun 10 13:33:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 10 Jun 2025 13:33:27 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v39]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <dbgVIxaLhZIz3-6qkuM7QOnBwh7k88E00pCXejUGzrE=.68761112-3f5e-4ca0-9d89-d2aa912c021f@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 55 commits:

 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - * indentation fix
 - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - ... and 45 more: https://git.openjdk.org/jdk/compare/0582bd29...c07a73db

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=38
  Stats: 7085 lines in 111 files changed: 2568 ins; 3599 del; 918 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

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

From tschatzl at openjdk.org  Tue Jun 10 13:35:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 10 Jun 2025 13:35:28 GMT
Subject: RFR: 8358294: Remove unnecessary GenAlignment
In-Reply-To: <i_uMl0YdxEjg4Qjs8GuNOVhRRJTAY4uFx52guCmxS3o=.aa817c34-8586-4fbf-83ed-cf22f5df3b23@github.com>
References: <i_uMl0YdxEjg4Qjs8GuNOVhRRJTAY4uFx52guCmxS3o=.aa817c34-8586-4fbf-83ed-cf22f5df3b23@github.com>
Message-ID: <b6eyJl2T9FK_JmPoDCZPLVZVSraqzESd8rPxlvoDxCA=.1413e2a8-ee47-4f74-91cc-8e3ba289c2a6@github.com>

On Mon, 2 Jun 2025 08:36:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple replacement of `GenAlignment` with `SpaceAlignment`, because they always have the same value. Removing the former to reduce complexity.
> 
> Test: tier1-3

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25577#pullrequestreview-2913607949

From iwalulya at openjdk.org  Tue Jun 10 14:46:30 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 10 Jun 2025 14:46:30 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <n3nJ2iTkVfAQEr1rVEhFbc7fv5g8RH203XwAXBpDeDI=.4c12b70b-71d2-4872-a6b8-25290a94e529@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <n3nJ2iTkVfAQEr1rVEhFbc7fv5g8RH203XwAXBpDeDI=.4c12b70b-71d2-4872-a6b8-25290a94e529@github.com>
Message-ID: <ffZQ9QMxv5J-iJFtV0rI8RHrYNHgA_jxmwnuOLe8Pak=.aa5c8c22-d0a5-4dd6-a63c-a7ddb603bd07@github.com>

On Tue, 10 Jun 2025 13:14:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> In general though, I think we should not expose G1HeapRegionManager to other classes via the suggested hrm() getter because imo the region management (getting information about them, iteration) seems to be fairly central to the heap. G1HeapRegionManagerto me is an integral part of the CollectedHeap, and only factored out into an extra class for convenience.

If this is the general approach, then it is fine by me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2959538317

From ayang at openjdk.org  Tue Jun 10 17:47:47 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 10 Jun 2025 17:47:47 GMT
Subject: RFR: 8358294: Remove unnecessary GenAlignment [v2]
In-Reply-To: <i_uMl0YdxEjg4Qjs8GuNOVhRRJTAY4uFx52guCmxS3o=.aa817c34-8586-4fbf-83ed-cf22f5df3b23@github.com>
References: <i_uMl0YdxEjg4Qjs8GuNOVhRRJTAY4uFx52guCmxS3o=.aa817c34-8586-4fbf-83ed-cf22f5df3b23@github.com>
Message-ID: <IZnNRGaXTEnFWtgihTl2HBdrgUiWDFo9siX_sjUrRSs=.7e3d67fb-82f6-4fd0-9d03-e4d59f9c4724@github.com>

> Simple replacement of `GenAlignment` with `SpaceAlignment`, because they always have the same value. Removing the former to reduce complexity.
> 
> 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 two additional commits since the last revision:

 - Merge branch 'master' into remove-gen-alignment
 - remove-gen-alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25577/files
  - new: https://git.openjdk.org/jdk/pull/25577/files/987f3d51..d21a02e3

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

  Stats: 29666 lines in 802 files changed: 23009 ins; 4069 del; 2588 mod
  Patch: https://git.openjdk.org/jdk/pull/25577.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25577/head:pull/25577

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

From ayang at openjdk.org  Tue Jun 10 18:14:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 10 Jun 2025 18:14:28 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <n3nJ2iTkVfAQEr1rVEhFbc7fv5g8RH203XwAXBpDeDI=.4c12b70b-71d2-4872-a6b8-25290a94e529@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <n3nJ2iTkVfAQEr1rVEhFbc7fv5g8RH203XwAXBpDeDI=.4c12b70b-71d2-4872-a6b8-25290a94e529@github.com>
Message-ID: <jTjIQ-CgYCDdYe_IyVK_5x8XxqNIwnKW8_EVHvdhEA0=.e98601b1-5bb6-449a-a3f2-3c1b6b2387d2@github.com>

On Tue, 10 Jun 2025 13:14:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Trying to answer the question about the right place for that optimization: To mirror other code like allocate_humongous() which also has the special casing to avoid some expensive operation in G1HeapRegionManager, I would tend to keep the check there, and so my preference would be to keep the code as is. That special-casing does not fit in the suggested location too imo.

On rereading the surrounding code, the early-return logic can even precede the following, right?


// early-return based on obj_regions vs num_available_regions
G1HeapRegion* humongous_start = _hrm.allocate_humongous(obj_regions);

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2960197344

From ayang at openjdk.org  Tue Jun 10 20:13:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 10 Jun 2025 20:13:33 GMT
Subject: Integrated: 8358294: Remove unnecessary GenAlignment
In-Reply-To: <i_uMl0YdxEjg4Qjs8GuNOVhRRJTAY4uFx52guCmxS3o=.aa817c34-8586-4fbf-83ed-cf22f5df3b23@github.com>
References: <i_uMl0YdxEjg4Qjs8GuNOVhRRJTAY4uFx52guCmxS3o=.aa817c34-8586-4fbf-83ed-cf22f5df3b23@github.com>
Message-ID: <m2YRickxr6BDbf8CVFwx9jMFa1-AV8PbQEES6ZCUk3w=.52e4d449-ff87-4812-bcac-79b77213f4d5@github.com>

On Mon, 2 Jun 2025 08:36:08 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple replacement of `GenAlignment` with `SpaceAlignment`, because they always have the same value. Removing the former to reduce complexity.
> 
> Test: tier1-3

This pull request has now been integrated.

Changeset: 38b877e9
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38b877e941918cc5f0463b256d4672d765d40302
Stats:     105 lines in 16 files changed: 0 ins; 46 del; 59 mod

8358294: Remove unnecessary GenAlignment

Reviewed-by: iwalulya, tschatzl

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

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

From ayang at openjdk.org  Tue Jun 10 20:13:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 10 Jun 2025 20:13:32 GMT
Subject: RFR: 8358294: Remove unnecessary GenAlignment [v2]
In-Reply-To: <IZnNRGaXTEnFWtgihTl2HBdrgUiWDFo9siX_sjUrRSs=.7e3d67fb-82f6-4fd0-9d03-e4d59f9c4724@github.com>
References: <i_uMl0YdxEjg4Qjs8GuNOVhRRJTAY4uFx52guCmxS3o=.aa817c34-8586-4fbf-83ed-cf22f5df3b23@github.com>
 <IZnNRGaXTEnFWtgihTl2HBdrgUiWDFo9siX_sjUrRSs=.7e3d67fb-82f6-4fd0-9d03-e4d59f9c4724@github.com>
Message-ID: <4-LjRq2jPjNeeH4KZq4NYgzkIM8QM3K-a9fz0b67IJY=.de37d756-35cd-4b00-b80f-bac5fe861f42@github.com>

On Tue, 10 Jun 2025 17:47:47 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple replacement of `GenAlignment` with `SpaceAlignment`, because they always have the same value. Removing the former to reduce complexity.
>> 
>> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into remove-gen-alignment
>  - remove-gen-alignment

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25577#issuecomment-2960461165

From wkemper at openjdk.org  Tue Jun 10 20:20:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 10 Jun 2025 20:20:01 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
Message-ID: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>

Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.

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

Commit messages:
 - Merge remote-tracking branch 'jdk/master' into clean-read-table-for-degen
 - Clean the read table before swapping during a degenerated cycle

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

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

From xpeng at openjdk.org  Tue Jun 10 20:31:28 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 10 Jun 2025 20:31:28 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
In-Reply-To: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
Message-ID: <x1g1sCNWi31Yjz4Lkqtrzq9xkpA0YMC_URsc5M12e34=.8ec6a5a2-e398-474b-9861-a2eb33805cb8@github.com>

On Tue, 10 Jun 2025 20:14:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.

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

> 644:   if (heap->mode()->is_generational()) {
> 645:     heap->old_generation()->card_scan()->mark_read_table_as_clean();
> 646:   }

I guess swap_card_tables has to be done at safe-point, otherwise we can move this to the place right before swap_card_tables is called in `op_init_mark`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25735#discussion_r2138715859

From kdnilsen at openjdk.org  Tue Jun 10 20:47:26 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 10 Jun 2025 20:47:26 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
In-Reply-To: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
Message-ID: <qpG90qAha_A-xAIdmZ5At8HzqgQQ7nN5PAs9QWu3ZNo=.43a6d13d-8742-47d4-82a4-5b0920d4b0a8@github.com>

On Tue, 10 Jun 2025 20:14:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.

Thanks.  LGTM

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25735#pullrequestreview-2914990916

From xpeng at openjdk.org  Tue Jun 10 21:13:31 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 10 Jun 2025 21:13:31 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
In-Reply-To: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
Message-ID: <j9NENeT27H5NautAdS8yUQ-7TgB7c0QS_l8Ftfdw8e4=.0d8c3663-0e2a-49ea-92d0-537fbccdf968@github.com>

On Tue, 10 Jun 2025 20:14:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.

src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 142:

> 140:         // Clean the read table before swapping it. The end goal here is to have a clean
> 141:         // write table, and to have the read table updated with the previous write table.
> 142:         heap->old_generation()->card_scan()->mark_read_table_as_clean();

Should we clean only when _generation is young, given we swap card tables when _generation is young?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25735#discussion_r2138774860

From cslucas at openjdk.org  Tue Jun 10 23:05:27 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 10 Jun 2025 23:05:27 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
In-Reply-To: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
Message-ID: <B1lPiP_YsHcrEDNZNPTlG-PDgBmx_q1lssjoa0U2H7Y=.512c0e73-b2ee-4521-837d-6d5666c7155f@github.com>

On Tue, 10 Jun 2025 20:14:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.

Marked as reviewed by cslucas (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25735#pullrequestreview-2915227439

From ysr at openjdk.org  Tue Jun 10 23:33:27 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 10 Jun 2025 23:33:27 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
In-Reply-To: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
Message-ID: <E37h4N1yyGNE4zBaw9h5TKlEDMiyUPnv3dBTyIdXilw=.72fb33fb-1955-4d0a-b802-f90a403dd3dc@github.com>

On Tue, 10 Jun 2025 20:14:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.

Suggest moving the reset to a more consolidated natural point rather than piecemeal as done in this solution.

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

Changes requested by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25735#pullrequestreview-2915255444

From ysr at openjdk.org  Tue Jun 10 23:33:28 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 10 Jun 2025 23:33:28 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
In-Reply-To: <x1g1sCNWi31Yjz4Lkqtrzq9xkpA0YMC_URsc5M12e34=.8ec6a5a2-e398-474b-9861-a2eb33805cb8@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
 <x1g1sCNWi31Yjz4Lkqtrzq9xkpA0YMC_URsc5M12e34=.8ec6a5a2-e398-474b-9861-a2eb33805cb8@github.com>
Message-ID: <I7WcLC8JQ6CrAJFzdhDUVGqhaYnZ620slP6Kmrc1pYw=.b3fcaf42-7bad-44e2-8683-fd2af503fe29@github.com>

On Tue, 10 Jun 2025 20:28:21 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 646:
> 
>> 644:   if (heap->mode()->is_generational()) {
>> 645:     heap->old_generation()->card_scan()->mark_read_table_as_clean();
>> 646:   }
> 
> I guess swap_card_tables has to be done at safe-point, otherwise we can move this to the place right before swap_card_tables is called in `op_init_mark`

To the point that Xiaolong is making in his other comment, I think we can move this cleaning into the `prepare_gc()` for the young generation which would be called above.

Similarly, see my comment at the other place in degen collection, we'd have the prepare_gc() in the op_reset() clear the rad table along that path.

I think that is the right place to do this resetting as we "prepare" the generation for a future collection at the conclusion of this one.

> src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp line 142:
> 
>> 140:         // Clean the read table before swapping it. The end goal here is to have a clean
>> 141:         // write table, and to have the read table updated with the previous write table.
>> 142:         heap->old_generation()->card_scan()->mark_read_table_as_clean();
> 
> Should we clean only when _generation is young, given we swap card tables when _generation is young?

If we started out with a clean read table, each concurrent gc cleaned the read table after it completed, then if we degenerate outside a cycle, we should find the read table clean already. 

Unless I am missing something, we should be able to assert here that the read table is clean (which the swap already does). Do we need the reset?

It would seem that in the event that we degenerated within a concurrent cycle then we may not have done the reset and that's where we'd need to do an explicit reset further below where we call `op_reset()` which then calls `prepare_gc()` on the generation that was subject to this collection cycle, addressing the point that Xiaolong makes. See my comment in the other file as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25735#discussion_r2138918518
PR Review Comment: https://git.openjdk.org/jdk/pull/25735#discussion_r2138919561

From ivan.walulya at oracle.com  Wed Jun 11 07:40:43 2025
From: ivan.walulya at oracle.com (Ivan Walulya)
Date: Wed, 11 Jun 2025 07:40:43 +0000
Subject: Request for Feedback and Testing on G1 Heap Resizing Prototype
In-Reply-To: <CA+w6HxYobzMFVm13NVbB6=XYuG2Up6Xim1d54EF=du97TCvweg@mail.gmail.com>
References: <6B0649C0-8188-47AB-8EA1-B4A48172898C@oracle.com>
 <91b4d64f-261c-4355-b6d3-279af4583b1a@oracle.com>
 <CA+w6HxYobzMFVm13NVbB6=XYuG2Up6Xim1d54EF=du97TCvweg@mail.gmail.com>
Message-ID: <DC6B4911-E037-4CB8-94BD-7AF13CC83DD0@oracle.com>

Hi all,

I'm happy to do some experiments and provide feedback. Does [1] contain all necessary changes? Will that branch be updated as parts of it merge into master?


Yes, the branch includes all the necessary changes, and we regularly merge it with the master branch.

We?d like to reiterate our request for feedback and benchmarking on this prototype to help expand our test coverage before upstreaming it to master.

Regards

Ivan


On 1 May 2025, at 09:07, Man Cao <manc at google.com> wrote:

Great progress! Thank you, Ivan. Optimistically, many of these changes could make it to JDK 25.

I'm happy to do some experiments and provide feedback. Does [1] contain all necessary changes? Will that branch be updated as parts of it merge into master?

Some early questions/feedback below.

> We also increase the default GCTimeRatio from 12 to 24 [3] (we are choosing 24 but open to suggestions). The existing default causes the heap to shrink too aggressively under the new policy in order to maintain the target GCTimeRatio. A higher default provides a better balance and avoids shrinking heap.
This changes the pause overhead target from ~8% (1/13) to 4% (1/25). Would it make G1 expand the heap more aggressively after incremental collections compared to existing behavior? Could you share some early/rough performance numbers about 12 vs 24 with the prototype, such as actual heap sizes, throughput differences?

> Additionally, we are removing the heap resizing at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. This resizing of the heap ignores current application behaviour and may lead to pathological cases of repeated concurrent mark cycles:
In the new prototype, does the pathological case happen with the default MinHeapFreeRatio=40 MaxHeapFreeRatio=70 value? Or mainly with smaller user-defined values for MinHeapFreeRatio/MaxHeapFreeRatio?

Re Thomas's comments:

> So if one were to make GCTimeRatio manageable (just for testing
> purposes), and made it a float (for better control), changes to it
> should reflect on the used heap size in the next few GCs automatically.

Making GCTimeRatio manageable sounds like a good idea. Do we plan to do this eventually (why "just for testing purposes")?

> A SoftMaxHeapSize implementation based on the discussion in the PR [0]
> that only guides IHOP with changes in
> ?G1AdaptiveIHOPControl::actual_target_threshold() should be effective
> now, but there may be issues with this GCTimeRatio based heap sizing
> that would be interesting to explore.

If G1 strives to respect GCTimeRatio as the prototype proposes, our existing use cases probably no longer need to set SoftMaxHeapSize (and maintains a separate algorithm to calculate values for SoftMaxHeapSize).
Our use case still needs CurrentMaxHeapSize, but it could be followed up in https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-April/051996.html.

[1] https://github.com/openjdk/jdk/compare/master...walulyai:jdk:G1HeapResizePolicy<https://urldefense.com/v3/__https://github.com/openjdk/jdk/compare/master...walulyai:jdk:G1HeapResizePolicy__;!!ACWV5N9M2RV99hQ!JlnhkOzqIxHgH_spHDGjsfW6b5ZVKUugvs1Kl9qfByI_epprMWfr5pHawxc2UT8H4_cgbnZcvXog7gI$>

-Man


On Tue, Apr 29, 2025 at 4:34?AM Thomas Schatzl <thomas.schatzl at oracle.com<mailto:thomas.schatzl at oracle.com>> wrote:
Hi Ivan,

   thanks for working on this!

Some comments for people (Man, Monica, Kirk) potentially taking this for
a spin:

On 29.04.25 12:46, Ivan Walulya wrote:
> As part of our preparations for AHS, we are prototyping changes to the
> G1 heap resizing policy to improve the effectiveness of the GCTimeRatio
> [1]. The GCTimeRatio is set to manage the balance between GC time and
> Application execution time. G1's current implementation of GCTimeRatio
> appears to have drifted from its intended purpose over time. It may no
> longer accurately guide heap sizing in response to GC overhead.
> Therefore, we need to change this mechanism with the goal that G1 better
> manages heap sizes without the need for additional tuning knobs.
 > > The prototype allows both expansion and shrinking of the heap at
the end
> of any GC, as opposed to the current behavior where shrinking is only
> allowed at Remark or Full GC pauses [2].  We also increase the default
> GCTimeRatio from 12 to 24 [3] (we are choosing 24 but open to
> suggestions). The existing default causes the heap to shrink too
> aggressively under the new policy in order to maintain the target
> GCTimeRatio. A higher default provides a better balance and avoids
> shrinking heap.

So if one were to make GCTimeRatio manageable (just for testing
purposes), and made it a float (for better control), changes to it
should reflect on the used heap size in the next few GCs automatically.

A SoftMaxHeapSize implementation based on the discussion in the PR [0]
that only guides IHOP with changes in
?G1AdaptiveIHOPControl::actual_target_threshold() should be effective
now, but there may be issues with this GCTimeRatio based heap sizing
that would be interesting to explore.
> Additionally, we are removing the heap resizing at the end of the Remark
> pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. This
> resizing of the heap ignores current application behaviour and may lead
> to pathological cases of repeated concurrent mark cycles:
>
>    *      we shrink the heap at remark,
>    *      a smaller heap triggers a concurrent marking in the subsequent
>     GCs as well as expanding the heap
>    *      the concurrent cycle ends in another remark pause where the
>     cycle restarts.
>
>
> We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at
> the end of Full GC.

The use case for this might be ones similar to CraC to temporarily
compact the heap as much as possible; however it might be better to have
explicit control for that (e.g. a jcmd).

Ultimately there may be need to remove it as well for full gcs,
replacing it with something else.
> As a result of these changes, applications may settle at more
> appropriate and in some cases smaller heap sizes for a given
> GCTimeRatio. While this may show as regression in some benchmarks that
> are sensitive to heap size, it is still improved control over GC behaviour.
>
> We are requesting for feedback or testing of these changes before
> propose to merge them with mainline.
>
> Some of the changes that are independent of the GCTimeRatio are already
> out for review [4, 5], other minor fixes will be split out and pushed
> independently.
>
[0] https://github.com/openjdk/jdk/pull/24211<https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/24211__;!!ACWV5N9M2RV99hQ!JlnhkOzqIxHgH_spHDGjsfW6b5ZVKUugvs1Kl9qfByI_epprMWfr5pHawxc2UT8H4_cgbnZcDP8RivU$>

Hth,
   Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250611/398b9d58/attachment-0001.htm>

From tschatzl at openjdk.org  Wed Jun 11 09:19:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 11 Jun 2025 09:19:28 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <jTjIQ-CgYCDdYe_IyVK_5x8XxqNIwnKW8_EVHvdhEA0=.e98601b1-5bb6-449a-a3f2-3c1b6b2387d2@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <n3nJ2iTkVfAQEr1rVEhFbc7fv5g8RH203XwAXBpDeDI=.4c12b70b-71d2-4872-a6b8-25290a94e529@github.com>
 <jTjIQ-CgYCDdYe_IyVK_5x8XxqNIwnKW8_EVHvdhEA0=.e98601b1-5bb6-449a-a3f2-3c1b6b2387d2@github.com>
Message-ID: <8iL29_igsPWMwEwKheH4AkPjjjkV7TBnLMOXyWbpMR4=.5ea098a6-493c-4cc9-86b5-31bf419604e6@github.com>

On Tue, 10 Jun 2025 18:12:06 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> 
> On rereading the surrounding code, the early-return logic can even precede the following, right?
> 
> ```
> // early-return based on obj_regions vs num_available_regions
> G1HeapRegion* humongous_start = _hrm.allocate_humongous(obj_regions);
> ```

I think so too; this can be an argument for moving this out; an alternative that seems to be better could be moving all the code related to `G1HeapRegionManager` in this method into it. Both `allocate_humongous` and `expand_and_allocate_humongous` are only called in this one method of `G1CollectedHeap`.

Then the (public) interface for `G1HeapRegionManager` could be even smaller; there also seems to be some opportunity to flatten out a few methods in `G1HeapRegionManager` along the way.

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2961870840

From jsikstro at openjdk.org  Wed Jun 11 09:46:21 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 11 Jun 2025 09:46:21 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v2]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <PN40IcJFM-DJgVR-9M2y-DAcWrAZGUX4QLiK874cn5A=.dc46b01f-96cf-4e42-8a33-1ce4d388d1f0@github.com>

> Hello,
> 
> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
> 
> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
> 
> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
> 
> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
> 
> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
> 
> Testing:
> * Oracle's tier 1-5

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

 - -Wconversion fixes
 - Intermediate alloc_object in ZHeap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/24489a20..4d33d429

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

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

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

From jsikstro at openjdk.org  Wed Jun 11 10:22:28 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 11 Jun 2025 10:22:28 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v2]
In-Reply-To: <PN40IcJFM-DJgVR-9M2y-DAcWrAZGUX4QLiK874cn5A=.dc46b01f-96cf-4e42-8a33-1ce4d388d1f0@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <PN40IcJFM-DJgVR-9M2y-DAcWrAZGUX4QLiK874cn5A=.dc46b01f-96cf-4e42-8a33-1ce4d388d1f0@github.com>
Message-ID: <1mwNciX8rBovstwBkcnOnWVQjtqFeNKkfpiCkEQvEo0=.8ba43988-ec2a-49ca-a4f1-7361dd7fedbf@github.com>

On Wed, 11 Jun 2025 09:46:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
>> 
>> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
>> 
>> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
>> 
>> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
>> 
>> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - -Wconversion fixes
>  - Intermediate alloc_object in ZHeap

I fixed some offline feedback from @xmas92 on keeping the callsite in ZCollectedHeap clean and delegating the actual work (the null-check and out-of-memory accounting) to ZHeap.

I also fixed some -Wconversion warnings in zObjectAllocator.inline.hpp.

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

PR Comment: https://git.openjdk.org/jdk/pull/25693#issuecomment-2962092262

From ayang at openjdk.org  Wed Jun 11 11:01:23 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 11 Jun 2025 11:01:23 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v12]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <8ydE-ymScXytYj65qVxSOmFikkvS90bH5NcvLsfAa7c=.b410d110-0db6-4750-8603-d2de21436263@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - merge
 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - merge
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - ... and 7 more: https://git.openjdk.org/jdk/compare/56ce70c5...8689b54c

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=11
  Stats: 4373 lines in 31 files changed: 522 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From ayang at openjdk.org  Wed Jun 11 11:04:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 11 Jun 2025 11:04:40 GMT
Subject: RFR: 8359224: G1: Incorrect size unit in logging of
 G1CollectedHeap::alloc_archive_region
Message-ID: <No3fAKJ4YEYdBB-G7G5WjUhPNKQCFMQNX7l8h4-h1CQ=.4a1c9b82-71bd-4199-aebb-3653b175563f@github.com>

Simple fixing incorrect unit (byte vs word) in logging.

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

Commit messages:
 - g1-word-byte-size

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

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

From tschatzl at openjdk.org  Wed Jun 11 12:37:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 11 Jun 2025 12:37:28 GMT
Subject: RFR: 8359224: G1: Incorrect size unit in logging of
 G1CollectedHeap::alloc_archive_region
In-Reply-To: <No3fAKJ4YEYdBB-G7G5WjUhPNKQCFMQNX7l8h4-h1CQ=.4a1c9b82-71bd-4199-aebb-3653b175563f@github.com>
References: <No3fAKJ4YEYdBB-G7G5WjUhPNKQCFMQNX7l8h4-h1CQ=.4a1c9b82-71bd-4199-aebb-3653b175563f@github.com>
Message-ID: <3h_haECBdGpuZhvnL1gs84AtKIsuZfrvBDfPNe_7LG0=.31b9b343-31b4-445c-a59c-60d15d210016@github.com>

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

> Simple fixing incorrect unit (byte vs word) in logging.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25746#pullrequestreview-2916951948

From ayang at openjdk.org  Wed Jun 11 14:37:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 11 Jun 2025 14:37:46 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions [v2]
In-Reply-To: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
Message-ID: <jIjoujLHYi0TRtQ_MCAT5-hl6U4-sMdwsbNsxSy4ezY=.08d53790-f91b-40ee-b9c7-a22196648deb@github.com>

> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
> 
> Test: tier1

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 g1-move-api
 - g1-move-api

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25611/files
  - new: https://git.openjdk.org/jdk/pull/25611/files/396dbd57..0f3b7e76

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

  Stats: 28092 lines in 703 files changed: 21517 ins; 4115 del; 2460 mod
  Patch: https://git.openjdk.org/jdk/pull/25611.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25611/head:pull/25611

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

From ayang at openjdk.org  Wed Jun 11 14:37:46 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 11 Jun 2025 14:37:46 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <8iL29_igsPWMwEwKheH4AkPjjjkV7TBnLMOXyWbpMR4=.5ea098a6-493c-4cc9-86b5-31bf419604e6@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <n3nJ2iTkVfAQEr1rVEhFbc7fv5g8RH203XwAXBpDeDI=.4c12b70b-71d2-4872-a6b8-25290a94e529@github.com>
 <jTjIQ-CgYCDdYe_IyVK_5x8XxqNIwnKW8_EVHvdhEA0=.e98601b1-5bb6-449a-a3f2-3c1b6b2387d2@github.com>
 <8iL29_igsPWMwEwKheH4AkPjjjkV7TBnLMOXyWbpMR4=.5ea098a6-493c-4cc9-86b5-31bf419604e6@github.com>
Message-ID: <ZWtUJ8EHJ7TTy5WTW734gkv7NJN4oZrWpLBIoB-JrQ8=.21e4c1c8-b2ca-478d-acf0-dd6ecc1ce23d@github.com>

On Wed, 11 Jun 2025 09:17:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> an alternative that seems to be better could be moving all the code related to G1HeapRegionManager in this method into it.

If I understand you correctly, the suggestion is to merge `expand_and_allocate_humongous` into `allocate_humongous`. However, in that case the caller (g1-heap) doesn't know whether expansion happened or not. (The heap needs to call `record_new_heap_size` when expanding.)


  G1HeapRegion* humongous_start = _hrm.allocate_humongous(obj_regions);
  if (humongous_start == nullptr) {
    humongous_start = _hrm.expand_and_allocate_humongous(obj_regions);
    if (humongous_start != nullptr) {
      policy()->record_new_heap_size(num_committed_regions());

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2963086968

From syan at openjdk.org  Thu Jun 12 07:50:40 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 12 Jun 2025 07:50:40 GMT
Subject: RFR: 8359272: Several vmTestbase/compact tests timed out on large
 memory machine
Message-ID: <lWtRRgi58ur6iDhoGUHR7LCpTWTkypsC-JG4V021R2U=.3a247361-4e6e-470b-afcf-83cc516be168@github.com>

Hi all,

We observed 4 vmTestbase/vm/gc/compact tests run timed out on large physical memory machine (755G memory) with jtreg args `-timeoutFactor:4`. The other vmTestbase tests do not observed the same failure.
The tested class `vm.gc.compact.Compact` create lots objects util trigger OOM exception. But if the tested machine has very large physica memory, these tests need takes a lots of time to finish.
So this PR add jvm args `-Xmx3G` to make these tests will run finish in a deterministic time. Change has been verified locally, test-fix only, no risk.

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

Commit messages:
 - 8359272: Several vmTestbase/compact tests timed out on large memory machine

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

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

From aboldtch at openjdk.org  Thu Jun 12 09:26:33 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 12 Jun 2025 09:26:33 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v2]
In-Reply-To: <PN40IcJFM-DJgVR-9M2y-DAcWrAZGUX4QLiK874cn5A=.dc46b01f-96cf-4e42-8a33-1ce4d388d1f0@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <PN40IcJFM-DJgVR-9M2y-DAcWrAZGUX4QLiK874cn5A=.dc46b01f-96cf-4e42-8a33-1ce4d388d1f0@github.com>
Message-ID: <pEPL89DTdFmlBlGF0hc8hW3EkHiLD0VA2oMvCt-XTIY=.693443d9-edaf-4be3-8df8-8f3ad0be4cb0@github.com>

On Wed, 11 Jun 2025 09:46:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
>> 
>> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
>> 
>> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
>> 
>> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
>> 
>> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - -Wconversion fixes
>  - Intermediate alloc_object in ZHeap

The change looks good. But I have a few thoughts if we want to take this a step further.

This change starts adding a static interface on `ZObjectAllocator` which is used for `retire_pages`. I wonder if we can take this all the way and make `ZObjectAllocator` a static only interface. And keep the Allocator implementation opaque / private. 

So instead of first pulling out the allocator and calling the corresponding function, we go through the static interface. So we get something like
```c++
  static void initialize();
  static void retire_pages(ZPageAgeRange range);
  static zaddress alloc_object(size_t size, ZPageAge age);
  static void undo_alloc_object(zaddress addr, size_t size, ZPageAge age);
  static size_t remaining_in_eden();

src/hotspot/share/gc/z/zObjectAllocator.hpp line 44:

> 42:   static constexpr uint NumRelocationAllocators = NumAllocators - 1;
> 43: 
> 44:   typedef Deferred<ValueObjArray<ZObjectAllocator, NumAllocators>> Allocators;

Nit, I prefer `using` over `typedef`.
Suggestion:

  using Allocators = Deferred<ValueObjArray<ZObjectAllocator, NumAllocators>>;

src/hotspot/share/gc/z/zObjectAllocator.hpp line 85:

> 83:   static ZObjectAllocator* eden();
> 84: 
> 85:   static void retire_pages(ZPageAgeRange range);

We tend to avoid mixing static and non static interfaces.

Maybe adding a `ZObjectAllocators` to wrap the static interface is preferable.

src/hotspot/share/gc/z/zObjectAllocator.inline.hpp line 43:

> 41:   guarantee(size <= ZHeap::heap()->max_tlab_size(), "TLAB too large");
> 42:   return alloc_object(size);
> 43: }

This could probably be on `ZHeap` instead and only have `alloc_object` on `ZObjectAllocator`

src/hotspot/share/gc/z/zObjectAllocator.inline.hpp line 47:

> 45: inline void ZObjectAllocator::retire_pages(ZPageAgeRange range) {
> 46:   for (ZPageAge age : range) {
> 47:     _allocators->at((int)untype(age))->retire_pages();

Suggestion:

    allocator(age)->retire_pages();

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

PR Review: https://git.openjdk.org/jdk/pull/25693#pullrequestreview-2920054625
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142045793
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142109305
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142153886
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142089670

From tschatzl at openjdk.org  Thu Jun 12 10:56:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 10:56:27 GMT
Subject: RFR: 8359272: Several vmTestbase/compact tests timed out on large
 memory machine
In-Reply-To: <lWtRRgi58ur6iDhoGUHR7LCpTWTkypsC-JG4V021R2U=.3a247361-4e6e-470b-afcf-83cc516be168@github.com>
References: <lWtRRgi58ur6iDhoGUHR7LCpTWTkypsC-JG4V021R2U=.3a247361-4e6e-470b-afcf-83cc516be168@github.com>
Message-ID: <QjQ22k56_DaAg3zaNshZrAYxG37dw8utCf2PB83CA7k=.3e0bcfc8-f49e-41f9-bb63-130c7fbb957a@github.com>

On Thu, 12 Jun 2025 07:45:49 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> We observed 4 vmTestbase/vm/gc/compact tests run timed out on large physical memory machine (755G memory) with jtreg args `-timeoutFactor:4`. The other vmTestbase tests do not observed the same failure.
> The tested class `vm.gc.compact.Compact` create lots objects util trigger OOM exception. But if the tested machine has very large physica memory, these tests need takes a lots of time to finish.
> So this PR add jvm args `-Xmx3G` to make these tests will run finish in a deterministic time. Change has been verified locally, test-fix only, no risk.

Although it would probably be better to fix all the other tests preemptively too - I could not find a particular reason why only these particular tests would be that slow (there are more string related tests in that directory) - it seems fine to just fix these.
There does not seem to be any difference between using a larger or smaller heap either.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25771#pullrequestreview-2920545620

From duke at openjdk.org  Thu Jun 12 11:28:35 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 11:28:35 GMT
Subject: Withdrawn: 8359110: Log accumulated GC and process CPU time upon VM
 exit
In-Reply-To: <dJ1wtrK-AzIRBUUEKh44iP4UsWuR8a2x0fRiPlVXr30=.6cbaa927-879e-4e0e-8bd8-ac5eed26ed52@github.com>
References: <dJ1wtrK-AzIRBUUEKh44iP4UsWuR8a2x0fRiPlVXr30=.6cbaa927-879e-4e0e-8bd8-ac5eed26ed52@github.com>
Message-ID: <24ib50kFQIUcwJ1BlMmQPdDDZI2wDSV0aHdR1_ratQE=.7c283605-89a7-491b-802b-86958b78e801@github.com>

On Tue, 10 Jun 2025 13:24:37 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

This pull request has been closed without being integrated.

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

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

From ayang at openjdk.org  Thu Jun 12 11:38:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 12 Jun 2025 11:38:34 GMT
Subject: RFR: 8359272: Several vmTestbase/compact tests timed out on large
 memory machine
In-Reply-To: <lWtRRgi58ur6iDhoGUHR7LCpTWTkypsC-JG4V021R2U=.3a247361-4e6e-470b-afcf-83cc516be168@github.com>
References: <lWtRRgi58ur6iDhoGUHR7LCpTWTkypsC-JG4V021R2U=.3a247361-4e6e-470b-afcf-83cc516be168@github.com>
Message-ID: <IFhSeEUQVFviNSjrwDSVUy6lcMf3aISGk_u1RR5tRlo=.07b4f31a-ad25-458b-9a75-39acc8052207@github.com>

On Thu, 12 Jun 2025 07:45:49 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> We observed 4 vmTestbase/vm/gc/compact tests run timed out on large physical memory machine (755G memory) with jtreg args `-timeoutFactor:4`. The other vmTestbase tests do not observed the same failure.
> The tested class `vm.gc.compact.Compact` create lots objects util trigger OOM exception. But if the tested machine has very large physica memory, these tests need takes a lots of time to finish.
> So this PR add jvm args `-Xmx3G` to make these tests will run finish in a deterministic time. Change has been verified locally, test-fix only, no risk.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25771#pullrequestreview-2920725216

From tschatzl at openjdk.org  Thu Jun 12 11:40:36 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 11:40:36 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions [v2]
In-Reply-To: <jIjoujLHYi0TRtQ_MCAT5-hl6U4-sMdwsbNsxSy4ezY=.08d53790-f91b-40ee-b9c7-a22196648deb@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <jIjoujLHYi0TRtQ_MCAT5-hl6U4-sMdwsbNsxSy4ezY=.08d53790-f91b-40ee-b9c7-a22196648deb@github.com>
Message-ID: <JvbTQ5wvwzbStm5FNyr_Yo0KXC_4EtiNmRUygVh0vIg=.7dc166de-24df-4a2f-9563-341784d79d47@github.com>

On Wed, 11 Jun 2025 14:37:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
>> 
>> Test: tier1
>
> 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 g1-move-api
>  - g1-move-api

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25611#pullrequestreview-2920738634

From tschatzl at openjdk.org  Thu Jun 12 11:40:38 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 11:40:38 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <ZWtUJ8EHJ7TTy5WTW734gkv7NJN4oZrWpLBIoB-JrQ8=.21e4c1c8-b2ca-478d-acf0-dd6ecc1ce23d@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <n3nJ2iTkVfAQEr1rVEhFbc7fv5g8RH203XwAXBpDeDI=.4c12b70b-71d2-4872-a6b8-25290a94e529@github.com>
 <jTjIQ-CgYCDdYe_IyVK_5x8XxqNIwnKW8_EVHvdhEA0=.e98601b1-5bb6-449a-a3f2-3c1b6b2387d2@github.com>
 <8iL29_igsPWMwEwKheH4AkPjjjkV7TBnLMOXyWbpMR4=.5ea098a6-493c-4cc9-86b5-31bf419604e6@github.com>
 <ZWtUJ8EHJ7TTy5WTW734gkv7NJN4oZrWpLBIoB-JrQ8=.21e4c1c8-b2ca-478d-acf0-dd6ecc1ce23d@github.com>
Message-ID: <i_zdPxbcl8yNj6RcSzdrHsEVjrgIHl1w1V2_COumALw=.9f2f11b4-1e81-44a5-ab85-4e3043f69aff@github.com>

On Wed, 11 Jun 2025 14:34:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > an alternative that seems to be better could be moving all the code related to G1HeapRegionManager in this method into it.
> 
> If I understand you correctly, the suggestion is to merge `expand_and_allocate_humongous` into `allocate_humongous`. However, in that case the caller (g1-heap) doesn't know whether expansion happened or not. (The heap needs to call `record_new_heap_size` when expanding.)
> 
> ```
>   G1HeapRegion* humongous_start = _hrm.allocate_humongous(obj_regions);
>   if (humongous_start == nullptr) {
>     humongous_start = _hrm.expand_and_allocate_humongous(obj_regions);
>     if (humongous_start != nullptr) {
>       policy()->record_new_heap_size(num_committed_regions());
> ```

An additional return parameter could handle that, like I prototyped at https://github.com/openjdk/jdk/commit/5cf6f2545062c6e5fb582070f4a0b6e9a25731de . However overall I think the change as is is okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2966299998

From duke at openjdk.org  Thu Jun 12 12:32:46 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 12:32:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
Message-ID: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>

Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.


[1.500s][info ][gc] GC CPU cost: 1.75%


Additionally, detailed information may be retrieved with `-Xlog:gc=trace`


[1.500s][trace][gc] Process CPU time: 4.945370s
[1.500s][trace][gc] GC CPU time: 0.086382s
[1.500s][info ][gc] GC CPU cost: 1.75%

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

Commit messages:
 - Add elapsed_process_vtime
 - Log GC vtime on VM exit

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

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

From duke at openjdk.org  Thu Jun 12 12:32:46 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 12:32:46 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <Ue8SSC2EoS4-lc-PZsHEiMelSH2OjuYNcElXEvxuCzc=.3abc83a3-4706-4daf-9f93-7dd8b58d65fb@github.com>

On Thu, 12 Jun 2025 11:28:14 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

This PR is ready for review

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966510906

From jsikstro at openjdk.org  Thu Jun 12 12:40:24 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 12 Jun 2025 12:40:24 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v3]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <elMkIz7XHX7wQyqV2l5_z9h-tBjzQcXPMWndq0C7Yr0=.3ad95491-0b7d-4151-a13e-5c28f0d191b3@github.com>

> Hello,
> 
> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
> 
> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
> 
> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
> 
> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
> 
> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
> 
> Testing:
> * Oracle's tier 1-5

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

  AllStatic interface with ZObjectAllocators

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/4d33d429..9412bae5

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

  Stats: 123 lines in 10 files changed: 44 ins; 46 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/25693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25693/head:pull/25693

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

From jsikstro at openjdk.org  Thu Jun 12 12:40:27 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 12 Jun 2025 12:40:27 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v2]
In-Reply-To: <pEPL89DTdFmlBlGF0hc8hW3EkHiLD0VA2oMvCt-XTIY=.693443d9-edaf-4be3-8df8-8f3ad0be4cb0@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <PN40IcJFM-DJgVR-9M2y-DAcWrAZGUX4QLiK874cn5A=.dc46b01f-96cf-4e42-8a33-1ce4d388d1f0@github.com>
 <pEPL89DTdFmlBlGF0hc8hW3EkHiLD0VA2oMvCt-XTIY=.693443d9-edaf-4be3-8df8-8f3ad0be4cb0@github.com>
Message-ID: <xx34HnDeOUV-NU19SPiUdRQ0oyZISll9UbAZk0U8nDo=.293bea44-46dc-4109-9f21-b3ea455b2d87@github.com>

On Thu, 12 Jun 2025 09:23:35 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - -Wconversion fixes
>>  - Intermediate alloc_object in ZHeap
>
> The change looks good. But I have a few thoughts if we want to take this a step further.
> 
> This change starts adding a static interface on `ZObjectAllocator` which is used for `retire_pages`. I wonder if we can take this all the way and make `ZObjectAllocator` a static only interface. And keep the Allocator implementation opaque / private. 
> 
> So instead of first pulling out the allocator and calling the corresponding function, we go through the static interface. So we get something like
> ```c++
>   static void initialize();
>   static void retire_pages(ZPageAgeRange range);
>   static zaddress alloc_object(size_t size, ZPageAge age);
>   static void undo_alloc_object(zaddress addr, size_t size, ZPageAge age);
>   static size_t remaining_in_eden();

Thank you for the feedback @xmas92!

I addressed your comments in a new commit. Do you think we should now rename the zObjectAllocator{.hpp, .inline.hpp, cpp} to zObjectAllocators instead, now that the static interface is the new "accessor"?

If you have any thoughts on my comment about making the ZObjectAllocator constuctor private I'm open to suggestions.

> src/hotspot/share/gc/z/zObjectAllocator.hpp line 44:
> 
>> 42:   static constexpr uint NumRelocationAllocators = NumAllocators - 1;
>> 43: 
>> 44:   typedef Deferred<ValueObjArray<ZObjectAllocator, NumAllocators>> Allocators;
> 
> Nit, I prefer `using` over `typedef`.
> Suggestion:
> 
>   using Allocators = Deferred<ValueObjArray<ZObjectAllocator, NumAllocators>>;

Sure!

> src/hotspot/share/gc/z/zObjectAllocator.hpp line 85:
> 
>> 83:   static ZObjectAllocator* eden();
>> 84: 
>> 85:   static void retire_pages(ZPageAgeRange range);
> 
> We tend to avoid mixing static and non static interfaces.
> 
> Maybe adding a `ZObjectAllocators` to wrap the static interface is preferable.

I added an AllStatic ZObjectAllocators. I think this looks good. I couldn't get around not having the ZObjectAllocator constructor being public so that ValueObjArray can access it. Adding ValueObjArray as a friend did not work either, maybe there's a better way to do this but I'm not sure.

> src/hotspot/share/gc/z/zObjectAllocator.inline.hpp line 43:
> 
>> 41:   guarantee(size <= ZHeap::heap()->max_tlab_size(), "TLAB too large");
>> 42:   return alloc_object(size);
>> 43: }
> 
> This could probably be on `ZHeap` instead and only have `alloc_object` on `ZObjectAllocator`

I agree, we don't have to include ZObjectAllocator in zCollectedHeap.cpp any more as well, and the guarantee check fits better in ZHeap instead of here.

> src/hotspot/share/gc/z/zObjectAllocator.inline.hpp line 47:
> 
>> 45: inline void ZObjectAllocator::retire_pages(ZPageAgeRange range) {
>> 46:   for (ZPageAge age : range) {
>> 47:     _allocators->at((int)untype(age))->retire_pages();
> 
> Suggestion:
> 
>     allocator(age)->retire_pages();

?

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

PR Comment: https://git.openjdk.org/jdk/pull/25693#issuecomment-2966542623
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142626884
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142625860
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142621460
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2142626528

From mdoerr at openjdk.org  Thu Jun 12 12:53:31 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 12 Jun 2025 12:53:31 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v2]
In-Reply-To: <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
Message-ID: <RxFOQmRFDnrOUb9TbplJl1e_EjK4cLwb-YDTJbywGVA=.be50fd6c-66f3-4874-90e5-5f3e56f5e851@github.com>

On Thu, 12 Jun 2025 02:01:47 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - ... and stale code
>  - removed stale comment

I appreciate this PR. I like using the nmethod entry barrier and getting rid of not-entrant patching.
I have some change requests. In addition, we can get rid of much more code. I've put my proposal in a Commit: https://github.com/TheRealMDoerr/jdk/commit/4aed569dc353c254a2f4de2d387208a0a1323990
Please take a look!

src/hotspot/share/gc/shared/barrierSetNMethod.cpp line 246:

> 244:   ConditionalMutexLocker ml(NMethodEntryBarrier_lock, !NMethodEntryBarrier_lock->owned_by_self(), Mutex::_no_safepoint_check_flag);
> 245:   int value = guard_value(nm) | not_entrant;
> 246:   set_guard_value(nm, value);

Same here.

src/hotspot/share/gc/shenandoah/shenandoahCodeRoots.cpp line 153:

> 151:         // Code cache unloading needs to know about on-stack nmethods. Arm the nmethods to get
> 152:         // mark_as_maybe_on_stack() callbacks when they are used again.
> 153:         _bs->arm(nm);

This breaks the Shenandoah build. `arm` is private.

src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 116:

> 114:     value |= not_entrant;
> 115:   }
> 116:   set_guard_value(nm, value);

We can avoid redundant patching since we have the lock: Only update if the value is not already there. This happens quite often.

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

Changes requested by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2920990811
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2142655962
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2142641974
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2142654627

From jsikstro at openjdk.org  Thu Jun 12 13:17:19 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 12 Jun 2025 13:17:19 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v4]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <ICiJJ71OdjRLnLUoP1ZLsteTf4kS8I1t2IlrxWc8yxs=.ddbc2f78-25ae-4ae1-b37b-d45616e91a4d@github.com>

> Hello,
> 
> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
> 
> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
> 
> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
> 
> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
> 
> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
> 
> Testing:
> * Oracle's tier 1-5

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

  Friend class ValueObjBlock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/9412bae5..12a3b140

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

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

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

From jsikstro at openjdk.org  Thu Jun 12 13:17:20 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 12 Jun 2025 13:17:20 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v3]
In-Reply-To: <elMkIz7XHX7wQyqV2l5_z9h-tBjzQcXPMWndq0C7Yr0=.3ad95491-0b7d-4151-a13e-5c28f0d191b3@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <elMkIz7XHX7wQyqV2l5_z9h-tBjzQcXPMWndq0C7Yr0=.3ad95491-0b7d-4151-a13e-5c28f0d191b3@github.com>
Message-ID: <pK0P42rDrEez9HOrB-hR6ngEq9j9Tp25kt-oPtCg3R4=.9d733432-bcc4-4c12-b959-6724ba1c203a@github.com>

On Thu, 12 Jun 2025 12:40:24 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
>> 
>> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
>> 
>> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
>> 
>> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
>> 
>> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   AllStatic interface with ZObjectAllocators

I got it! I friend class'd ValueObjBlock, which actually calls the constructor, not ValueObjArray. We can't specialize on the Count, since ValueObjBlock decrements it when constructing the array, and we can't do partial specialization, so I ended up friend class'ing any specialization of ValueObjBlock.


/Users/jsikstro/dev/jdk/open/src/hotspot/share/gc/z/zObjectAllocator.hpp:43:10: error: partial specialization cannot be declared as a friend
  friend class ValueObjBlock<ZObjectAllocator, Count>;


I think I prefer this over keeping the constructor of ZObjectAllocator public, which now allows us to make the entire implementation of ZObjectAllocator opaque/private.

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

PR Comment: https://git.openjdk.org/jdk/pull/25693#issuecomment-2966662822

From duke at openjdk.org  Thu Jun 12 13:35:51 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 13:35:51 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - Remove unused bool
 - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/4eaa6e1f..dbf314c7

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

  Stats: 125 lines in 5 files changed: 101 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From duke at openjdk.org  Thu Jun 12 13:35:52 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 13:35:52 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <W1lPRJzuwttSAcdvB8sNM2G9o21W6hylXbx8TCxVxQk=.350f9e13-d53d-45cf-ae43-85f3b7b94473@github.com>

On Thu, 12 Jun 2025 11:28:14 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Refactored code per @kstefanj suggestions

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966727348

From tschatzl at openjdk.org  Thu Jun 12 13:42:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 13:42:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
Message-ID: <iCOk2HGYxCEPtFwMspKFnHVVkt3B0CmsUtkjoALdQVM=.997eb3c2-5a9f-4929-9708-f5314a89ee8f@github.com>

On Thu, 12 Jun 2025 13:35:51 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused bool
>  - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection

Fwiw, I would prefer to have one message containing all the information, and add the `exit` tag. This decreases clutter (timestamp and tags), and allows direct selection of that message.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966768048

From tschatzl at openjdk.org  Thu Jun 12 13:53:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 13:53:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
Message-ID: <Lr7C5g7ICViqGcC76awvF81P8Mm6nfQgN39LJxWesCk=.ad5369c4-a0c2-41fc-a8b7-735287440d4b@github.com>

On Thu, 12 Jun 2025 13:35:51 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused bool
>  - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1498:

> 1496:   _cr->threads_do(&cl);
> 1497:   _cm->threads_do(&cl);
> 1498:   _workers->threads_do(&cl);

There is `CollectedHeap::gc_threads_do()` (in general, for all collectors) to iterate over GC threads. Please use that. It may allow putting all that code into `CollectedHeap` used by all collectors too.

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2921251009
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2142799289

From tschatzl at openjdk.org  Thu Jun 12 13:56:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 13:56:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <iCOk2HGYxCEPtFwMspKFnHVVkt3B0CmsUtkjoALdQVM=.997eb3c2-5a9f-4929-9708-f5314a89ee8f@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
 <iCOk2HGYxCEPtFwMspKFnHVVkt3B0CmsUtkjoALdQVM=.997eb3c2-5a9f-4929-9708-f5314a89ee8f@github.com>
Message-ID: <Nha1mhv7H0CgBo5AV7DWmFuPyfmkuapnhI-LThs4XPI=.af8c4bd2-fad0-4bdc-b0c2-593cb0553b56@github.com>

On Thu, 12 Jun 2025 13:39:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Fwiw, I would prefer to have one message containing all the information, and add the `exit` tag. This decreases clutter (timestamp and tags), and allows direct selection of that message.

Also reduces the amount of parsing needed in scripts etc. (I.e. three regexps vs. one). These three values are not really too much to digest for human readers.

Another problem seems to be the large amount of digits after the comma for the times; maybe use a different time scale (ms/us).

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2966846342

From tschatzl at openjdk.org  Thu Jun 12 14:33:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 12 Jun 2025 14:33:29 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
Message-ID: <Bb8ks2_3B7h_4zra7NehB-7Hv3bf_LyfWfXEiwu2MdY=.19ca851d-8520-4a12-8bbd-cefee760f8c7@github.com>

On Thu, 12 Jun 2025 13:35:51 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove unused bool
>  - Refactor vtime logic in evaluate_operation into a stack object and call CPUTimeCounters without indirection

src/hotspot/share/gc/shared/collectedHeap.cpp line 234:

> 232:       cost = 100 * gc_vtime / process_vtime;
> 233:     }
> 234:     log_info(gc)("GC CPU cost: %2.2f%%", cost);

I would prefer "usage" instead of "cost". The former seems to be more neutral.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2142928706

From duke at openjdk.org  Thu Jun 12 14:40:27 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 14:40:27 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v2]
In-Reply-To: <Nha1mhv7H0CgBo5AV7DWmFuPyfmkuapnhI-LThs4XPI=.af8c4bd2-fad0-4bdc-b0c2-593cb0553b56@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <CO6Z3Mbn2NogTZNSKkJmJ6IWe04ZD38dCrsu8C5sgLE=.b9f5a224-ae1a-491c-b682-205bc5151f91@github.com>
 <iCOk2HGYxCEPtFwMspKFnHVVkt3B0CmsUtkjoALdQVM=.997eb3c2-5a9f-4929-9708-f5314a89ee8f@github.com>
 <Nha1mhv7H0CgBo5AV7DWmFuPyfmkuapnhI-LThs4XPI=.af8c4bd2-fad0-4bdc-b0c2-593cb0553b56@github.com>
Message-ID: <H_hXvJ5PaF7KWK36HtkHDZ_4He65ahwp7l5Fl6GcC64=.ff46150e-31ac-4c8a-9ac5-2ea5883e68e9@github.com>

On Thu, 12 Jun 2025 13:53:29 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Fwiw, I would prefer to have one message containing all the information, and add the `exit` tag. This decreases clutter (timestamp and tags), and allows direct selection of that message.

Thank you for sharing your concern. I'm OK with putting the CPU times currently in trace into the `exit` tag but I strongly believe we should keep the 
`[1.500s][info ][gc] GC CPU cost: 1.75%` as is. I discussed the `exit` tag option with @kstefanj but I thought that hiding the nominal values in the trace level would suffice, but can change that if we think that is preferable. I think that exposing this number at `-Xlog:gc`-level may be an important tool for users to understand that they may running with too small heap. We expose a lot of way for users to understand the memory footprint, but not too much about the CPU footprint. Putting this number behind `exit` may increase the risk that the typical user will not discover it. Adding one line at the end while at the same time logging information about each GC cycle does not clutter the message log IMO.

Another option could be to not log the nominal values at all. If one have the percentage and measure process CPU time with e.g. perf one could calculate it yourself anyways. What do you think about that?

> 
> Another problem seems to be the large amount of digits after the comma for the times; maybe use a different time scale (ms/us).

Thanks for pointing that out, I will fix that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2967112195

From duke at openjdk.org  Thu Jun 12 15:25:08 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 15:25:08 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
 - Remove unnecessary assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/dbf314c7..aeb4ad04

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

  Stats: 84 lines in 9 files changed: 17 ins; 62 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From duke at openjdk.org  Thu Jun 12 15:31:31 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 12 Jun 2025 15:31:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
Message-ID: <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>

On Thu, 12 Jun 2025 15:25:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>  - Remove unnecessary assert

FYI; I removed nominal logging

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2967302296

From wkemper at openjdk.org  Thu Jun 12 18:52:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Jun 2025 18:52:50 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
 [v2]
In-Reply-To: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
Message-ID: <-hSDnHAfYEBYrD639Gd-a7jNOFOlA-XVOEvZqypyzyk=.c64ccff0-b13b-4a5e-b81a-0c1966f32f8e@github.com>

> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.

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

  Consolidate read table cleaning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25735/files
  - new: https://git.openjdk.org/jdk/pull/25735/files/5e2c20a8..9552021c

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

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

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

From dlong at openjdk.org  Thu Jun 12 19:54:45 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 12 Jun 2025 19:54:45 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v3]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <cXYQYfOLGgpJUJXn_mfH0sFsyhUHzUlOa7kCZD5sA4A=.537b7c84-4fb4-4c59-b125-d876a50449cf@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

Dean Long has updated the pull request incrementally with six additional commits since the last revision:

 - more cleanup
 - more TheRealMDoerr suggestions
 - TheRealMDoerr suggestions
 - remove trailing space
 - Fix Shenandoah build
 - more cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/0780d156..0950fc5e

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

  Stats: 330 lines in 25 files changed: 10 ins; 304 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/25764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764

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

From dlong at openjdk.org  Thu Jun 12 19:57:28 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 12 Jun 2025 19:57:28 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v2]
In-Reply-To: <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
Message-ID: <QmK2HAht4vFeChrAEcBdGS0s3eZFRS2VUPs34gcNO10=.f6aa2937-81e6-482c-9ef2-d83859fe2e39@github.com>

On Thu, 12 Jun 2025 02:01:47 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - ... and stale code
>  - removed stale comment

Thanks @TheRealMDoer for the suggestions, I incorporated all of them, however for shenandoahCodeRoots.cpp I decided to make arm() public, so the caller code doesn't need to know about the magic value 0.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2967999465

From mdoerr at openjdk.org  Thu Jun 12 20:08:31 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 12 Jun 2025 20:08:31 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v2]
In-Reply-To: <QmK2HAht4vFeChrAEcBdGS0s3eZFRS2VUPs34gcNO10=.f6aa2937-81e6-482c-9ef2-d83859fe2e39@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <8oM2Y0kAMRN6wxtjAmpXDWTcHDZ6gPrNM-8PPtukwAA=.dde201dd-8c2a-4a16-96e5-ca92604e6edd@github.com>
 <QmK2HAht4vFeChrAEcBdGS0s3eZFRS2VUPs34gcNO10=.f6aa2937-81e6-482c-9ef2-d83859fe2e39@github.com>
Message-ID: <15r53QUpAANeu3oucJCrmg3BOqTksEQK24cppfHjQow=.b5848d6f-0bfe-43ce-a4d8-29d57d91e873@github.com>

On Thu, 12 Jun 2025 19:54:28 GMT, Dean Long <dlong at openjdk.org> wrote:

> Thanks @TheRealMDoer for the suggestions, I incorporated all of them, however for shenandoahCodeRoots.cpp I decided to make arm() public, so the caller code doesn't need to know about the magic value 0.

Excellent! Thank you! I'll take another look over it and run tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2968024418

From kdnilsen at openjdk.org  Thu Jun 12 20:12:50 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 12 Jun 2025 20:12:50 GMT
Subject: RFR: 8357471: GenShen: Share collector reserves between young and
 old [v4]
In-Reply-To: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
References: <ymVpMrOFM1IwZnr-rycrifWPhzhLu5-zMpCL5z48ZDs=.61bdc3f1-d744-4686-a247-4c8d99e014d0@github.com>
Message-ID: <V5AHTUiMKriw_-4VySEn8r5jirj7WNEgCOtUwNjzizM=.8e4134f5-526e-4f32-9cc9-8a462dd698f3@github.com>

> Genshen independently reserves memory to hold evacuations into young and old generations.  We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young).
> 
> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle.  In this case, we can share the young collector reserves with the old generation.  This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity.
> 
> The following spreadsheet snapshots highlight the benefits of this change.  In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time).  This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young.  This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC.  In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive.  The total number of GC cycles decreases significantly.
> 
> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a)
> 
> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles.  By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles.  This reduces CPU load.  The impact on response times is not as significant as with the 6G heap size.  We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100.
> 
> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f)
> 
> At 8G heap size, the GC is not at all stressed.  We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100.
> 
> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c)
> 
> The command line for these comparisons follows:
> 
> 
>             ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jdk/bin/java \
>                 -XX:+Unlock...

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

  fix whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25357/files
  - new: https://git.openjdk.org/jdk/pull/25357/files/8ec6ea06..aea2b925

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

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

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

From wkemper at openjdk.org  Thu Jun 12 22:10:12 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Jun 2025 22:10:12 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
 [v3]
In-Reply-To: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
Message-ID: <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>

> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.

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

  Revert "Consolidate read table cleaning"
  
  This reverts commit 9552021cbeec699e7b04db81fa68819c23b7dab7.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25735/files
  - new: https://git.openjdk.org/jdk/pull/25735/files/9552021c..a313cf8d

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

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

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

From wkemper at openjdk.org  Thu Jun 12 22:47:28 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Jun 2025 22:47:28 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
 [v3]
In-Reply-To: <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
 <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
Message-ID: <GHjpKb3XaH9ordY5cWVGnqEwjwrXs_pPfgoxnckwNNk=.5e985710-7a3f-4c21-93a0-b14fecf8a845@github.com>

On Thu, 12 Jun 2025 22:10:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Consolidate read table cleaning"
>   
>   This reverts commit 9552021cbeec699e7b04db81fa68819c23b7dab7.

@pengxiaolong - We don't want to clean the read table during init-mark because that's a safepoint. We can safely clean the read table concurrently because only the GC thread has access to it.

@ysramakrishna - The refactoring you suggest is not so simple, alas. We have to be very careful about the ordering of cleaning the `read` table, resetting the mark bitmap and swapping the card tables. Genshen does not clean the `read` table at the end of a concurrent cycle (we _could_ do this, but we'd still need to do the same in a degenerated cycle). The complexity comes from swapping the card tables in a concurrent cycle. We must not let a subsequent degenerated cycle swap them a second time. The degenerated cycle can only clean the `read` table if there was no active concurrent cycle (lest it throw away critical remembered set data). 

However, the degenerated cycle must also clear the mark bitmaps if the concurrent cycle degenerated during the root scan (the degenerated cycle will rescan the roots). Of course, we cannot clear the mark bitmaps if the concurrent cycle degenerated during the mark phase. So, for the degenerated cycle, clearing the mark bitmaps and cleaning the read table need to happen in two different cases and it doesn't work if they're combined into the same method (and I don't think adding a method parameter to sometimes clear the mark bitmap and sometimes the read table will make the code any easier to understand).

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

PR Comment: https://git.openjdk.org/jdk/pull/25735#issuecomment-2968354749

From wkemper at openjdk.org  Thu Jun 12 23:46:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Jun 2025 23:46:36 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
Message-ID: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>

We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

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

Commit messages:
 - Fix typo
 - Clean up/fix gc causes for Shenandoah

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

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

From wkemper at openjdk.org  Fri Jun 13 00:15:29 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Jun 2025 00:15:29 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <p9BzwURqdvou-U1L4pPs5O-kir0JqOJcpWEoKMsOF9g=.e3e7f924-60bd-456a-99ac-cae5c9226e6f@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

src/hotspot/share/gc/shared/gcCause.cpp line 92:

> 90:       return "Diagnostic Command";
> 91: 
> 92:     case _shenandoah_stop_vm:

Just reordered this case to match enum's declaration order.

src/hotspot/share/gc/shared/gcCause.hpp line 118:

> 116:   inline static bool is_allocation_failure_gc(GCCause::Cause cause) {
> 117:     // _allocation_failure is the generic cause a collection for allocation failure
> 118:     return cause == GCCause::_allocation_failure;

Shenandoah does not use this method. Nobody else needs to know about this Shenandoah specific value.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25789#discussion_r2143900441
PR Review Comment: https://git.openjdk.org/jdk/pull/25789#discussion_r2143904488

From sangheki at openjdk.org  Fri Jun 13 00:41:33 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Fri, 13 Jun 2025 00:41:33 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions [v2]
In-Reply-To: <jIjoujLHYi0TRtQ_MCAT5-hl6U4-sMdwsbNsxSy4ezY=.08d53790-f91b-40ee-b9c7-a22196648deb@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <jIjoujLHYi0TRtQ_MCAT5-hl6U4-sMdwsbNsxSy4ezY=.08d53790-f91b-40ee-b9c7-a22196648deb@github.com>
Message-ID: <QcJonpPhzZyJvaXyO3XPEz9IXOli5RH_QglFR4TjEZM=.e5eeb3ad-10ab-4d8b-887c-2934decd9791@github.com>

On Wed, 11 Jun 2025 14:37:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
>> 
>> Test: tier1
>
> 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 g1-move-api
>  - g1-move-api

Marked as reviewed by sangheki (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25611#pullrequestreview-2923105099

From jsikstro at openjdk.org  Fri Jun 13 07:25:17 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 13 Jun 2025 07:25:17 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v5]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <yIMwj8i8hNYYcg6viDtqm9RZkIPa71JjyjbaE-vwoWs=.8d9cf645-c7e0-4b80-bece-8d3581785874@github.com>

> Hello,
> 
> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
> 
> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
> 
> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
> 
> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
> 
> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
> 
> Testing:
> * Oracle's tier 1-5

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

  Consistent template friend style

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/12a3b140..54af2098

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

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

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

From ayang at openjdk.org  Fri Jun 13 08:08:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 13 Jun 2025 08:08:36 GMT
Subject: RFR: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions [v2]
In-Reply-To: <jIjoujLHYi0TRtQ_MCAT5-hl6U4-sMdwsbNsxSy4ezY=.08d53790-f91b-40ee-b9c7-a22196648deb@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
 <jIjoujLHYi0TRtQ_MCAT5-hl6U4-sMdwsbNsxSy4ezY=.08d53790-f91b-40ee-b9c7-a22196648deb@github.com>
Message-ID: <u7-qKg6_mZEBufGbYy9CCfpA-lreAOBpm7G9KB-YkUQ=.79eee319-c02a-4d3e-aa93-4a4f883d447b@github.com>

On Wed, 11 Jun 2025 14:37:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
>> 
>> Test: tier1
>
> 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 g1-move-api
>  - g1-move-api

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25611#issuecomment-2969459783

From ayang at openjdk.org  Fri Jun 13 08:08:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 13 Jun 2025 08:08:37 GMT
Subject: Integrated: 8358483: G1: Remove
 G1HeapRegionManager::num_available_regions
In-Reply-To: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
References: <9sCW0ekUAWyBlIFbTUHU5Z9PMcJxwB766Zr525pfrO0=.c6f19ad1-ae7c-49d7-a8c6-88dd24b03786@github.com>
Message-ID: <CMotCQSWREaLBtNdGvx94fVPFGhrxWHzGAngoon_tx0=.a40d9566-19b0-4a76-b0d1-ddc1109d868c@github.com>

On Tue, 3 Jun 2025 09:10:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple cleanup of moving an API from `G1HeapRegionManager` to `G1CollectedHeap`.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: 032ead1d
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/032ead1d905d820f1fe4bf7a49dff98f59a21ded
Stats:     13 lines in 4 files changed: 4 ins; 7 del; 2 mod

8358483: G1: Remove G1HeapRegionManager::num_available_regions

Reviewed-by: tschatzl, sangheki

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

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

From syan at openjdk.org  Fri Jun 13 08:48:34 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 13 Jun 2025 08:48:34 GMT
Subject: RFR: 8359272: Several vmTestbase/compact tests timed out on large
 memory machine
In-Reply-To: <IFhSeEUQVFviNSjrwDSVUy6lcMf3aISGk_u1RR5tRlo=.07b4f31a-ad25-458b-9a75-39acc8052207@github.com>
References: <lWtRRgi58ur6iDhoGUHR7LCpTWTkypsC-JG4V021R2U=.3a247361-4e6e-470b-afcf-83cc516be168@github.com>
 <IFhSeEUQVFviNSjrwDSVUy6lcMf3aISGk_u1RR5tRlo=.07b4f31a-ad25-458b-9a75-39acc8052207@github.com>
Message-ID: <6XaqEoMV5WSBWepbufIWbKxZ5KGRlVHzDGQmYKsGe1M=.af876a73-87e1-4e19-b764-91a117b008eb@github.com>

On Thu, 12 Jun 2025 11:35:36 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>> We observed 4 vmTestbase/vm/gc/compact tests run timed out on large physical memory machine (755G memory) with jtreg args `-timeoutFactor:4`. The other vmTestbase tests do not observed the same failure.
>> The tested class `vm.gc.compact.Compact` create lots objects util trigger OOM exception. But if the tested machine has very large physica memory, these tests need takes lots of time to finish.
>> So this PR add jvm args `-Xmx3G` to make these tests will run finish in a deterministic time. Change has been verified locally, test-fix only, no risk.
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk @tschatzl Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25771#issuecomment-2969570032

From syan at openjdk.org  Fri Jun 13 08:48:35 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 13 Jun 2025 08:48:35 GMT
Subject: Integrated: 8359272: Several vmTestbase/compact tests timed out on
 large memory machine
In-Reply-To: <lWtRRgi58ur6iDhoGUHR7LCpTWTkypsC-JG4V021R2U=.3a247361-4e6e-470b-afcf-83cc516be168@github.com>
References: <lWtRRgi58ur6iDhoGUHR7LCpTWTkypsC-JG4V021R2U=.3a247361-4e6e-470b-afcf-83cc516be168@github.com>
Message-ID: <uS09wGoBTUIYDzYHncY-7_tyJSlpkvaQL2L8Yjbtv6U=.a410b5c8-d9e5-46bc-b6d9-0419392a26f0@github.com>

On Thu, 12 Jun 2025 07:45:49 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> We observed 4 vmTestbase/vm/gc/compact tests run timed out on large physical memory machine (755G memory) with jtreg args `-timeoutFactor:4`. The other vmTestbase tests do not observed the same failure.
> The tested class `vm.gc.compact.Compact` create lots objects util trigger OOM exception. But if the tested machine has very large physica memory, these tests need takes lots of time to finish.
> So this PR add jvm args `-Xmx3G` to make these tests will run finish in a deterministic time. Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: a0fb35c8
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0fb35c8379295d2927c18d694ea52f7b7488a2b
Stats:     12 lines in 4 files changed: 8 ins; 0 del; 4 mod

8359272: Several vmTestbase/compact tests timed out on large memory machine

Reviewed-by: tschatzl, ayang

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

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

From syan at openjdk.org  Fri Jun 13 09:05:11 2025
From: syan at openjdk.org (SendaoYan)
Date: Fri, 13 Jun 2025 09:05:11 GMT
Subject: [jdk25] RFR: 8359272: Several vmTestbase/compact tests timed out on
 large memory machine
Message-ID: <VkN-x7w3wr833QunuXjxWU2zXJh3wNvcdvWKeN5PkCs=.957cd08c-ac90-4b99-98d2-870d6a16c714@github.com>

Hi all,

This pull request contains a backport of commit [a0fb35c8](https://github.com/openjdk/jdk/commit/a0fb35c8379295d2927c18d694ea52f7b7488a2b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by SendaoYan on 13 Jun 2025 and was reviewed by Thomas Schatzl and Albert Mingkun Yang.

Thanks!

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

Commit messages:
 - Backport a0fb35c8379295d2927c18d694ea52f7b7488a2b

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

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

From shade at openjdk.org  Fri Jun 13 09:45:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 09:45:29 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <yX3ItHkBc8Rt7jI6Iu8bQMODtI-SrtMZ4ZbA4MGqvpc=.1bb654f5-cadb-4447-8769-0b459ed1ef91@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

Shenandoah parts look good, but we should avoid changing shared code unnecessarily.

Changes requested by shade (Reviewer).

src/hotspot/share/gc/shared/gcCause.hpp line 58:

> 56:     /* implementation independent, but reserved for GC use */
> 57:     _no_gc,
> 58:     _no_cause_specified,

Code history shows this enum was there since the beginning of OpenJDK. So it is better to leave it alone. It is also less confusing to have only Shenandoah-specific changes in RFE that starts with "Shenandoah: ..."

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

Changes requested by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2924090662
PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2924091681
PR Review Comment: https://git.openjdk.org/jdk/pull/25789#discussion_r2144632935

From tschatzl at openjdk.org  Fri Jun 13 10:21:22 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 13 Jun 2025 10:21:22 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
Message-ID: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>

On Thu, 12 Jun 2025 15:25:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>  - Remove unnecessary assert

The string deduplication thread, which is to some degree also a GC helper thread, is not considered here. Not sure if it should, slightly tending to add it.

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 164:

> 162: 
> 163: void ParallelScavengeHeap::stop() {
> 164:   log_gc_vtime();

I think in OO-fashion, instead of adding the `log_gc_vtime()` call everywhere, it should be called in the super-class method and the others defer to it.

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

> 151: 
> 152: double SerialHeap::elapsed_gc_vtime() {
> 153:   return (double) Universe::heap()->vm_vtime() / NANOSECS_PER_SEC;

This specialization does not seem necessary. Serial GC also has `gc_threads_do()`, which does nothing, as expected.

src/hotspot/share/gc/shared/collectedHeap.cpp line 239:

> 237:     double gc_vtime = elapsed_gc_vtime();
> 238: 
> 239:     if (process_vtime == -1 || gc_vtime == -1) return;

I would prefer to add braces to avoid overlooking this return statement in this context.

src/hotspot/share/gc/z/zCollectedHeap.cpp line 123:

> 121:       Atomic::add(&_vtime, os::thread_cpu_time(thread));
> 122:     }
> 123:   }

Why does this exclude threads like the `ZDirector` and other ZGC background threads? That thread seems to clearly be relevant to ZGC operation, doing so would make the measurement incomplete.
The change does not exclude e.g. some random G1 "director" threads either, even if they do not contribute much to the result.

src/hotspot/share/gc/z/zCollectedHeap.cpp line 130:

> 128:   ZVCPUThreadClosure cl;
> 129:   gc_threads_do(&cl);
> 130:   return (double)(cl.vtime() + Universe::heap()->vm_vtime()) / NANOSECS_PER_SEC;

Taking the comment about missing ZGC threads into account, it seems `elapsed_gc_vtime()` can be implemented without any need of overrides in `CollectedHeap`.

src/hotspot/share/runtime/vmOperation.hpp line 171:

> 169:   virtual bool evaluate_at_safepoint() const { return true; }
> 170: 
> 171:   virtual bool operation_is_gc() const { return false; }

This method seems to be never read anywhere. Is this correct?

src/hotspot/share/runtime/vmThread.cpp line 282:

> 280: 
> 281:     EventExecuteVMOperation event;
> 282:     VTimeScope vTimeScope(this);

Not sure if it is the intent of this change to put all VM operations into the "GC" bucket, particularly because of the log message indicating so. I would prefer if really only GC operations would be counted here; `VTimeScope` does not use `operation_is_gc()` either, so I am not sure about the intention here.

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2921860873
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144665083
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144669651
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2143164063
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144687225
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144693093
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144695741
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2143169291

From tschatzl at openjdk.org  Fri Jun 13 10:28:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 13 Jun 2025 10:28:29 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>
Message-ID: <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com>

On Thu, 12 Jun 2025 15:28:25 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> FYI; I removed nominal logging

Okay, these can be re-added if needed. I also see your point about that this is just one message at VM exit, so we do not need the "exit" label. I would prefer if it had, so I won't insist on it given that others do not mind either. It would fit the purpose of the `exit` label perfectly though.

The argument that "the user could forget specifying it", is somewhat weak imo - in that case one could argue why there are those labels, and I kind of doubt that GC cpu usage at the end only is that important to have for everyone every time.

I.e. if there is need to monitor it, only printing it at the end seems insufficient, as that kind of monitoring is continuous. It helps benchmarking though.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2969876711

From duke at openjdk.org  Fri Jun 13 10:50:38 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 10:50:38 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>
 <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com>
Message-ID: <UmjavZ2LxSQe-jy2OqaVOD5N_TT_tuZsWDb33Z00EJM=.9d37a8cd-d41e-4769-8f11-f372fcb71eeb@github.com>

On Fri, 13 Jun 2025 10:25:22 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> The argument that "the user could forget specifying it", is somewhat weak imo - in that case one could argue why there are those labels, and I kind of doubt that GC cpu usage at the end only is that important to have for everyone every time.

I disagree, it is equally important as reporting pre and post compaction heap usage like we do now with -Xlog:gc. Users who are not experts in GC may underestimate the CPU cost of GC at a given heap max. Even experts in academia tend to run with too small heap. I maintain my position that adding it at the end is crucial.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2969922344

From duke at openjdk.org  Fri Jun 13 10:50:39 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 10:50:39 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
Message-ID: <1rWshKBN5OE7MVryOUpeH2aOo4cbVLaZpbj7H8WCr9Q=.201e4fb8-50b6-466c-b863-1081bf034e9e@github.com>

On Thu, 12 Jun 2025 15:25:08 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>  - Remove unnecessary assert

Additionally, if we want to we can also add capabilities to track it continuously with JFR and/or MXBeans. But that may introduce a performance penalty as sampling may not be free so I want to still keep logging it at the end as a base case.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2969931470

From shade at openjdk.org  Fri Jun 13 10:59:28 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 13 Jun 2025 10:59:28 GMT
Subject: RFR: 8359224: G1: Incorrect size unit in logging of
 G1CollectedHeap::alloc_archive_region
In-Reply-To: <No3fAKJ4YEYdBB-G7G5WjUhPNKQCFMQNX7l8h4-h1CQ=.4a1c9b82-71bd-4199-aebb-3653b175563f@github.com>
References: <No3fAKJ4YEYdBB-G7G5WjUhPNKQCFMQNX7l8h4-h1CQ=.4a1c9b82-71bd-4199-aebb-3653b175563f@github.com>
Message-ID: <NAF0tuGc5Mtx1QvS111KIZyuo2Wsi4oG6hxLZo5Rbuc=.0ad7ce5d-33bf-46ae-b775-d910dc567255@github.com>

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

> Simple fixing incorrect unit (byte vs word) in logging.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25746#pullrequestreview-2924317470

From tschatzl at openjdk.org  Fri Jun 13 11:21:30 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 13 Jun 2025 11:21:30 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <UmjavZ2LxSQe-jy2OqaVOD5N_TT_tuZsWDb33Z00EJM=.9d37a8cd-d41e-4769-8f11-f372fcb71eeb@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <Lykwv6_mgJMSbPjraK_NfKWz8DCOpkHtukcaEJ2-Jy8=.35f4e074-790b-4f33-a561-f543ecfdf5d4@github.com>
 <8TCEc0dNl_P6eSaqltwYl0meAPd4Qzp9E2J8yUcTQvs=.1e1aca70-6576-4af1-bc04-a158554d9faa@github.com>
 <UmjavZ2LxSQe-jy2OqaVOD5N_TT_tuZsWDb33Z00EJM=.9d37a8cd-d41e-4769-8f11-f372fcb71eeb@github.com>
Message-ID: <_rAjyUhvY8figCunG0eUdqNQyZoRTnJz-RUTkv8KJR0=.32329766-3198-4b9f-8399-34ffd90a9dce@github.com>

On Fri, 13 Jun 2025 10:45:15 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> > The argument that "the user could forget specifying it", is somewhat weak imo - in that case one could argue why there are those labels, and I kind of doubt that GC cpu usage at the end only is that important to have for everyone every time.
> 
> I disagree, it is equally important as reporting pre and post compaction heap usage like we do now with -Xlog:gc. Users who are not experts in GC may underestimate the CPU cost of GC at a given heap max. Even experts in academia tend to run with too small heap. I maintain my position that adding it at the end is crucial.

I do not disagree about the usefulness of the message (it is - I even liked the nominal output), I only somewhat disagree about making a message purposefully printed at VM exit, to state the cpu usage at exit, not having the "exit" label.
(Regarding the nominal logging: my points were that I thought it was a waste to use three messages, and the presentation format)

We do not need to agree on everything 100%.

> Additionally, if we want to we can also add capabilities to track it continuously with JFR and/or MXBeans. But that may introduce a performance penalty as sampling may not be free so I want to still keep logging it at the end as a base case.

That's fine.

Fwiw, there has even been interest from me (https://bugs.openjdk.org/browse/JDK-8349476) about regularly printing these statistics at even higher detail.

However as far as I understand, there are jstat/perf counters already for that, and they are in use (in industry). There is the jcmd command (even before that) that prints per-thread cpu usage for some time now - one could filter out the interesting threads manually...

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2970035555

From mdoerr at openjdk.org  Fri Jun 13 11:57:35 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 13 Jun 2025 11:57:35 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v3]
In-Reply-To: <cXYQYfOLGgpJUJXn_mfH0sFsyhUHzUlOa7kCZD5sA4A=.537b7c84-4fb4-4c59-b125-d876a50449cf@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <cXYQYfOLGgpJUJXn_mfH0sFsyhUHzUlOa7kCZD5sA4A=.537b7c84-4fb4-4c59-b125-d876a50449cf@github.com>
Message-ID: <0jwlIB4VebRh3dORUSPdbmmE4YWS1Z6t_Ax8ni0_tpg=.f9dd6d19-1c97-43d7-acb2-ad575b61d433@github.com>

On Thu, 12 Jun 2025 19:54:45 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - Fix Shenandoah build
>  - more cleanup

LGTM, now. I think `is_sigill_not_entrant` should also be removed completely: https://github.com/TheRealMDoerr/jdk/commit/f61f54a40ad0b952ba8c0a668675b3f315f83a95
I've run tests on some platforms, but will run on more.
@offamitkumar, @RealFYang, @bulasevich: You may also want to check your platforms.
@fisk: You may want to take a look at the nmethod entry barrier changes.

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

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2924552667

From duke at openjdk.org  Fri Jun 13 12:02:40 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 12:02:40 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
Message-ID: <Nu5fmsTJbdSRmLg6Scl9kwD8UNAlskBXA02YRSCo06U=.ae87dac8-0969-41a2-bf30-a9b1027325cc@github.com>

On Thu, 12 Jun 2025 16:21:12 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>>  - Remove unnecessary assert
>
> src/hotspot/share/runtime/vmThread.cpp line 282:
> 
>> 280: 
>> 281:     EventExecuteVMOperation event;
>> 282:     VTimeScope vTimeScope(this);
> 
> Not sure if it is the intent of this change to put all VM operations into the "GC" bucket, particularly because of the log message indicating so. I would prefer if really only GC operations would be counted here; `VTimeScope` does not use `operation_is_gc()` either, so I am not sure about the intention here.

Ouch, thanks for catching this! My intention to use `operation_is_gc()` got lost during code refactoring. `VTimeScope` are supposed to call `os::thread_cpu_time` minimum amount of times needed and update VM cpu time tracking used by hsperf counters and the CPU time tracking this patch adds for GC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2144945218

From duke at openjdk.org  Fri Jun 13 12:54:34 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 12:54:34 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
Message-ID: <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>

On Fri, 13 Jun 2025 10:04:18 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>>  - Remove unnecessary assert
>
> src/hotspot/share/gc/z/zCollectedHeap.cpp line 123:
> 
>> 121:       Atomic::add(&_vtime, os::thread_cpu_time(thread));
>> 122:     }
>> 123:   }
> 
> Why does this exclude threads like the `ZDirector` and other ZGC background threads? That thread seems to clearly be relevant to ZGC operation, doing so would make the measurement incomplete.
> The change does not exclude e.g. some random G1 "director" threads either, even if they do not contribute much to the result.

I believe it does not exclude ZDirector, etc. Adding `printf("%s\n", thread->name());` to prove my point results in:


ZDirector
ZDriverMajor
ZDriverMinor
ZStat
ZUncommitter#0
ZWorkerYoung#0
ZWorkerYoung#1
ZWorkerYoung#2
ZWorkerYoung#3
ZWorkerOld#0
ZWorkerOld#1
ZWorkerOld#2
ZWorkerOld#3


This code is working around the fact that `ZCollectedHeap::gc_threads_do` also calls `_runtime_workers.threads_do` which I believe do not participate in GC related work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145029576

From ayang at openjdk.org  Fri Jun 13 13:07:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 13 Jun 2025 13:07:45 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
 <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>
Message-ID: <GChPrCekSO-bFpXBFJoFi7CHJGkXe1reHZmsrT49uyY=.4e52f2d8-35d4-4a1c-a4a7-61a2a9f7fafa@github.com>

On Fri, 13 Jun 2025 12:51:40 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/z/zCollectedHeap.cpp line 123:
>> 
>>> 121:       Atomic::add(&_vtime, os::thread_cpu_time(thread));
>>> 122:     }
>>> 123:   }
>> 
>> Why does this exclude threads like the `ZDirector` and other ZGC background threads? That thread seems to clearly be relevant to ZGC operation, doing so would make the measurement incomplete.
>> The change does not exclude e.g. some random G1 "director" threads either, even if they do not contribute much to the result.
>
> I believe it does not exclude ZDirector, etc. Adding `printf("%s\n", thread->name());` to prove my point results in:
> 
> 
> ZDirector
> ZDriverMajor
> ZDriverMinor
> ZStat
> ZUncommitter#0
> ZWorkerYoung#0
> ZWorkerYoung#1
> ZWorkerYoung#2
> ZWorkerYoung#3
> ZWorkerOld#0
> ZWorkerOld#1
> ZWorkerOld#2
> ZWorkerOld#3
> 
> 
> This code is working around the fact that `ZCollectedHeap::gc_threads_do` also calls `_runtime_workers.threads_do` which I believe do not participate in GC related work.

Both Parallel and G1 reuse the same gc-worker threads in `safepoint_workers()` for non-gc work, just fyi.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145051424

From ayang at openjdk.org  Fri Jun 13 13:43:57 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 13 Jun 2025 13:43:57 GMT
Subject: RFR: 8359224: G1: Incorrect size unit in logging of
 G1CollectedHeap::alloc_archive_region
In-Reply-To: <No3fAKJ4YEYdBB-G7G5WjUhPNKQCFMQNX7l8h4-h1CQ=.4a1c9b82-71bd-4199-aebb-3653b175563f@github.com>
References: <No3fAKJ4YEYdBB-G7G5WjUhPNKQCFMQNX7l8h4-h1CQ=.4a1c9b82-71bd-4199-aebb-3653b175563f@github.com>
Message-ID: <oXWo-kUwvSJV4We785L1i1SPKq-ldIUEd2Uch5Xut-0=.41e4e6ef-f54b-4d5b-9319-e69f644d4bfb@github.com>

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

> Simple fixing incorrect unit (byte vs word) in logging.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25746#issuecomment-2970444707

From ayang at openjdk.org  Fri Jun 13 13:43:57 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 13 Jun 2025 13:43:57 GMT
Subject: Integrated: 8359224: G1: Incorrect size unit in logging of
 G1CollectedHeap::alloc_archive_region
In-Reply-To: <No3fAKJ4YEYdBB-G7G5WjUhPNKQCFMQNX7l8h4-h1CQ=.4a1c9b82-71bd-4199-aebb-3653b175563f@github.com>
References: <No3fAKJ4YEYdBB-G7G5WjUhPNKQCFMQNX7l8h4-h1CQ=.4a1c9b82-71bd-4199-aebb-3653b175563f@github.com>
Message-ID: <U_pi--o-gL2Hnifjwx6QFj5YVuQ7Fp64OfPDSGkCJM4=.9099f741-d384-4219-8d5e-11a4f575241c@github.com>

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

> Simple fixing incorrect unit (byte vs word) in logging.

This pull request has now been integrated.

Changeset: 417f8ecf
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/417f8ecf072daabe0f79d145ffab121e5336988f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8359224: G1: Incorrect size unit in logging of G1CollectedHeap::alloc_archive_region

Reviewed-by: tschatzl, shade

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

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

From duke at openjdk.org  Fri Jun 13 14:40:30 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 14:40:30 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
Message-ID: <TBuVnwupYtMrRKHMazEXgmCK-9Bwr2qKUSJpHSX1l8U=.4071ab22-4b05-4cb0-9267-6a743898e7d6@github.com>

On Fri, 13 Jun 2025 09:55:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Refactor shared logic into CollectedHeap, remove nominal logging and cost->usage
>>  - Remove unnecessary assert
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 164:
> 
>> 162: 
>> 163: void ParallelScavengeHeap::stop() {
>> 164:   log_gc_vtime();
> 
> I think in OO-fashion, instead of adding the `log_gc_vtime()` call everywhere, it should be called in the super-class method and the others defer to it.

Just wanna double-check that I understood your suggestion. Are you suggesting that we should rather add calls to `CollectedHeap::stop()` at the beginning of the specialization?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145239880

From duke at openjdk.org  Fri Jun 13 16:01:35 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 16:01:35 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <GChPrCekSO-bFpXBFJoFi7CHJGkXe1reHZmsrT49uyY=.4e52f2d8-35d4-4a1c-a4a7-61a2a9f7fafa@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
 <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>
 <GChPrCekSO-bFpXBFJoFi7CHJGkXe1reHZmsrT49uyY=.4e52f2d8-35d4-4a1c-a4a7-61a2a9f7fafa@github.com>
Message-ID: <vLqfVwJ1I5pqpacCN6hRdNUmmz8tyoRXhE62ToVZ83g=.9b8731a4-1410-4103-b466-56f98dff62b7@github.com>

On Fri, 13 Jun 2025 13:04:35 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> I believe it does not exclude ZDirector, etc. Adding `printf("%s\n", thread->name());` to prove my point results in:
>> 
>> 
>> ZDirector
>> ZDriverMajor
>> ZDriverMinor
>> ZStat
>> ZUncommitter#0
>> ZWorkerYoung#0
>> ZWorkerYoung#1
>> ZWorkerYoung#2
>> ZWorkerYoung#3
>> ZWorkerOld#0
>> ZWorkerOld#1
>> ZWorkerOld#2
>> ZWorkerOld#3
>> 
>> 
>> This code is working around the fact that `ZCollectedHeap::gc_threads_do` also calls `_runtime_workers.threads_do` which I believe do not participate in GC related work.
>
> Both Parallel and G1 reuse the same gc-worker threads in `safepoint_workers()` for non-gc work, just fyi.

FWIW; I confirmed with @stefank that `_runtime_workers` shoud not be accounted for GC CPU time for ZGC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2145419752

From duke at openjdk.org  Fri Jun 13 17:08:00 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 17:08:00 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v4]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <k5hvg8PoaIH_cuL2JAGKgn0Ffi3XGRe6bpAE3KIDWQE=.bec462cc-6fb3-47dd-8cea-fcba22808587@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - Replace calls to log_gc_vtime with super-class method calls
 - Add bug fix after refactor and fixes for review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/aeb4ad04..dec5b8ba

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

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

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

From duke at openjdk.org  Fri Jun 13 17:14:35 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 17:14:35 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
Message-ID: <OKHlSSVavKR-Xn-qZKlJUfazQdwCuyOS4NeuRLOSfRo=.c69354e7-152f-45fd-9941-592065933681@github.com>

On Fri, 13 Jun 2025 10:17:17 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> The string deduplication thread, which is to some degree also a GC helper thread, is not considered here. Not sure if it should, slightly tending to add it.

I can see arguments for both ways, but do not have a strong opinion. Unless someone object I will add it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2970995550

From dlong at openjdk.org  Fri Jun 13 19:18:19 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 13 Jun 2025 19:18:19 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  remove is_sigill_not_entrant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/0950fc5e..c1ebde09

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

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

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

From duke at openjdk.org  Fri Jun 13 20:11:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 13 Jun 2025 20:11:04 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Add CPU time tracking for string deduplication to log_gc_vtime

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/dec5b8ba..895f3747

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

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

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

From ysr at openjdk.org  Fri Jun 13 20:52:28 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 13 Jun 2025 20:52:28 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <d2iYDGY5VtLvwbwWaz2klBw7uRgMaf829WpdFFqweDc=.bd1c05f3-7ac3-4fe0-9ac8-a336abaefe34@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

Reviewed -- would be good to go from my standpoint after separating into a separate ticket as suggested by Aleksey the collapse of `no_cause_specified` into its putative synonym `_no_gc`.

Approving in advance, subject to that change, and re-review by Aleksey.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/gc/shared/GCCause.java line 42:

> 40: 
> 41:   _no_gc ("No GC"),
> 42:   _no_cause_specified ("Unknown GCCause"),

I agree that "no cause specified" and "no gc" almost sound like synonyms, and any uses of one could be replaced with the other. However, with @shipilev , I agree that may be you split the changes to this kind of shared code into a separate ticket, in keeping with hotspot dev practices.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2926250505
PR Review Comment: https://git.openjdk.org/jdk/pull/25789#discussion_r2146013368

From mdoerr at openjdk.org  Sat Jun 14 11:10:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 14 Jun 2025 11:10:38 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
Message-ID: <0-Re4fyQGaSyOl-bYm1h9LT5a0TKKrgJCHquooXOIkQ=.d6044248-6188-4705-b564-90fa3d2d7762@github.com>

On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove is_sigill_not_entrant

Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance.

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2928005394

From eosterlund at openjdk.org  Mon Jun 16 00:59:31 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 16 Jun 2025 00:59:31 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
Message-ID: <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>

On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove is_sigill_not_entrant

Thanks for doing this! I have been wanting something like this for a while too and it looks great. I have some comments though...

src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 109:

> 107: }
> 108: 
> 109: void ZBarrierSetNMethod::arm_with(nmethod* nm, int value) {

I don't usually comment on names, but could we call this guard_with instead? We tried to stop saying "arm" about things used also for disarming and we have (hopefully) been consistent about calling that "guard" instead.

src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 114:

> 112:   // Preserve the sticky bit
> 113:   if (is_not_entrant(nm)) {
> 114:     value |= not_entrant;

Is it possible to have a race where another thread sets an nmethod to not entrant and the thread calling this making the nmethod entry barrier not entrant?

If this was called to disarm a method and then enter it, it seems a bit sneaky in that case that we pass the nmethod entry barrier even though we under the lock see that it is not entrant. Probably okay but still feels like it might be more robust if the thread setting an nmethod to not entrant is always the one that arms the nmethod entry barrier.

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

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2930412450
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2148888954
PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2148891702

From dholmes at openjdk.org  Mon Jun 16 07:43:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 16 Jun 2025 07:43:32 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
Message-ID: <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>

On Fri, 13 Jun 2025 20:11:04 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CPU time tracking for string deduplication to log_gc_vtime

This seems reasonable though I'm unclear on some details.  Could you give a high-level description of what times we capture for what threads and when, and the calculations involved. Thanks.

Some minor style nits.

src/hotspot/share/gc/shared/vtimeScope.hpp line 38:

> 36: 
> 37: public:
> 38:   VTimeScope(VMThread *thread, bool operation_is_gc);

Suggestion:

  VTimeScope(VMThread* thread, bool operation_is_gc);

src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 32:

> 30: #include "runtime/os.hpp"
> 31: 
> 32: inline VTimeScope::VTimeScope(VMThread *thread, bool operation_is_gc)

Suggestion:

inline VTimeScope::VTimeScope(VMThread* thread, bool operation_is_gc)

This style nit needs fixing in a few places.

src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 35:

> 33:     : _start(0), _enabled(os::is_thread_cpu_time_supported()),
> 34:       _gcLogging(operation_is_gc && (log_is_enabled(Info, gc) || log_is_enabled(Info, gc, cpu))),
> 35:       _thread((Thread*)thread) {

Cast should not be necessary

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2930801029
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149153155
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149153527
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149153897

From stefank at openjdk.org  Mon Jun 16 07:54:30 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Jun 2025 07:54:30 GMT
Subject: RFR: 8359394: Shenandoah: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <JsnkRZTMVaOtyBbLr1Nb9dlXmaChJVpKxBvatGtb7mg=.1543b4bd-d6bf-458b-bea3-f8dda0031a1e@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We can remove `GCCause::_no_cause_specified` and need to add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string`. We are also missing `_shenandoah_humongous_allocation_failure` in the `SA` analog.

I'm OK with the shared GC changes if you change the title of JBS issue or split it out the shared parts into a separate issue.

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

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2930994011

From amitkumar at openjdk.org  Mon Jun 16 08:29:34 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 16 Jun 2025 08:29:34 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
Message-ID: <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>

On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove is_sigill_not_entrant

Just FYI, s390 build is broken with this change: 


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
#  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
#
# JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
# Problematic frame:
# V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
#
# Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#


stack trace: 

Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
....

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2975564797

From tschatzl at openjdk.org  Mon Jun 16 08:34:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 16 Jun 2025 08:34:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
Message-ID: <8JpTGtXweaka2sBESSAKeOHqdsd-DrnLj7oF0XiZ0GI=.c8212dfd-a4ee-41a4-bf83-848c87bbd7ba@github.com>

On Fri, 13 Jun 2025 20:11:04 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CPU time tracking for string deduplication to log_gc_vtime

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 166:

> 164:   CollectedHeap::stop();
> 165: }
> 166: 

There is no need to override this method if the only thing it does is calling the super class method.

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

> 149:   CollectedHeap::stop();
> 150: }
> 151: 

There is no need to override this method if the only thing it does is calling the super class method.

src/hotspot/share/gc/shared/collectedHeap.hpp line 245:

> 243: 
> 244:   // Stop any onging concurrent work and prepare for exit.
> 245:   virtual void stop() { log_gc_vtime(); }

Please move this implementation into the `.cpp` file to avoid making the `.hpp` file more complicated than needed. It's not performance sensitive at all (or if you really think this is required, into the `.inline.hpp` file).

src/hotspot/share/gc/shared/collectedHeap.hpp line 258:

> 256:     _vm_vtime += time;
> 257:   }
> 258: 

Probably better to move into `.inline.hpp` file too.

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

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2930986521
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149271551
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149272195
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149350924
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149352267

From tschatzl at openjdk.org  Mon Jun 16 08:34:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 16 Jun 2025 08:34:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v3]
In-Reply-To: <vLqfVwJ1I5pqpacCN6hRdNUmmz8tyoRXhE62ToVZ83g=.9b8731a4-1410-4103-b466-56f98dff62b7@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <Cwh60zMu9SQfVBpI6RWoKJyL1b25EGO8CIlXFFy--2A=.dbf8012e-0bef-4ee9-bf62-91fa55a02077@github.com>
 <ButDY7qENolFBn7oM69UtjYeIB1E-sEvlk2-SZPsN8w=.4446e17b-a724-48ed-b4b2-7a85c9840851@github.com>
 <DBx2N5ui00OlD0YwkYDGMZtYXwYryEgy9HN3ABGcxMg=.05044f36-d65f-4500-bf61-b7390384f8ee@github.com>
 <GChPrCekSO-bFpXBFJoFi7CHJGkXe1reHZmsrT49uyY=.4e52f2d8-35d4-4a1c-a4a7-61a2a9f7fafa@github.com>
 <vLqfVwJ1I5pqpacCN6hRdNUmmz8tyoRXhE62ToVZ83g=.9b8731a4-1410-4103-b466-56f98dff62b7@github.com>
Message-ID: <ybJ_XoFTxPFpOxcux5e4ofseTtOZskiXBsk353QOPxA=.a8eeac02-4fb4-434f-a793-98b28add5648@github.com>

On Fri, 13 Jun 2025 15:59:05 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Both Parallel and G1 reuse the same gc-worker threads in `safepoint_workers()` for non-gc work, just fyi.
>
> FWIW; I confirmed with @stefank that `_runtime_workers` shoud not be accounted for GC CPU time for ZGC.

But then runtime tasks performed by the GC worker threads when using them for runtime work is differently counted towards those GCs that do this sharing/shadowing.

I looked a bit what they are doing, after JDK-8329488 they are only used by heap inspection and heap dumping. Which seems to be solely GC related task, so I kind of think they should be counted against GC.
At least make the accounting uniform across collectors.

So one option is duplicating these workers in G1/Parallel too, and fix https://bugs.openjdk.org/browse/JDK-8277394. Since we can't share GC workers and these "runtime workers" any more due to this change, the safepoint workers management should probably be moved to `CollectedHeap`, and they shouldn't be advertised as general purpose workers everyone can hook into.

Or just let ZGC's `_runtime_threads` also count towards GC time. After all both of these VM operations are `VM_GC_Operations`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149337356

From jsikstro at openjdk.org  Mon Jun 16 09:00:13 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 16 Jun 2025 09:00:13 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v6]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <hECBLDf0uF4TnymsuqXnOl_PenrbK7q27KT--lVPbeE=.21bdb33e-ca9b-418a-8457-1062a37e6ac1@github.com>

> Hello,
> 
> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
> 
> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
> 
> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
> 
> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
> 
> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
> 
> Testing:
> * Oracle's tier 1-5

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

  Move implementation to .cpp and static-only interface in .hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/54af2098..1885d763

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

  Stats: 183 lines in 8 files changed: 49 ins; 94 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/25693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25693/head:pull/25693

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

From jsikstro at openjdk.org  Mon Jun 16 09:00:14 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 16 Jun 2025 09:00:14 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v2]
In-Reply-To: <pEPL89DTdFmlBlGF0hc8hW3EkHiLD0VA2oMvCt-XTIY=.693443d9-edaf-4be3-8df8-8f3ad0be4cb0@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <PN40IcJFM-DJgVR-9M2y-DAcWrAZGUX4QLiK874cn5A=.dc46b01f-96cf-4e42-8a33-1ce4d388d1f0@github.com>
 <pEPL89DTdFmlBlGF0hc8hW3EkHiLD0VA2oMvCt-XTIY=.693443d9-edaf-4be3-8df8-8f3ad0be4cb0@github.com>
Message-ID: <tBGO9OJ6XOofYQLFj_vK-SMpleDNHAl_YKtnkrDX6Lc=.21290b65-23ba-41f3-98eb-96485cff6cfa@github.com>

On Thu, 12 Jun 2025 09:23:35 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - -Wconversion fixes
>>  - Intermediate alloc_object in ZHeap
>
> The change looks good. But I have a few thoughts if we want to take this a step further.
> 
> This change starts adding a static interface on `ZObjectAllocator` which is used for `retire_pages`. I wonder if we can take this all the way and make `ZObjectAllocator` a static only interface. And keep the Allocator implementation opaque / private. 
> 
> So instead of first pulling out the allocator and calling the corresponding function, we go through the static interface. So we get something like
> ```c++
>   static void initialize();
>   static void retire_pages(ZPageAgeRange range);
>   static zaddress alloc_object(size_t size, ZPageAge age);
>   static void undo_alloc_object(zaddress addr, size_t size, ZPageAge age);
>   static size_t remaining_in_eden();

With some more feedback from @xmas92 I have moved the implementation of ZObjectAllocator to the .cpp file, now named ZObjectAllocatorImpl. I have also moved the storage of the static allocators to the .cpp file and the .hpp file only contains the static interface, now called ZObjectAllocator.

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

PR Comment: https://git.openjdk.org/jdk/pull/25693#issuecomment-2975667892

From duke at openjdk.org  Mon Jun 16 09:03:32 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 09:03:32 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
 <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
Message-ID: <k_YqSpi_9RH66Yjcm71vsJU5PSE0QL63yqKnFvX1Uz0=.2e2248c0-35ac-467b-b1bf-c78a1525ce5d@github.com>

On Mon, 16 Jun 2025 06:37:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add CPU time tracking for string deduplication to log_gc_vtime
>
> src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 35:
> 
>> 33:     : _start(0), _enabled(os::is_thread_cpu_time_supported()),
>> 34:       _gcLogging(operation_is_gc && (log_is_enabled(Info, gc) || log_is_enabled(Info, gc, cpu))),
>> 35:       _thread((Thread*)thread) {
> 
> Cast should not be necessary

Not casting requires adding `#include "runtime/vmThread.hpp"`. Will add that since that seems to be preferred.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149417216

From duke at openjdk.org  Mon Jun 16 09:19:32 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 09:19:32 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
Message-ID: <djVKbomyI9yqnNVulCU26eHLGhU1M6oPIPd_nc2s8sY=.66ab1eeb-0073-4f32-8335-145a40374fcf@github.com>

On Fri, 13 Jun 2025 20:11:04 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add CPU time tracking for string deduplication to log_gc_vtime

src/hotspot/share/runtime/vmThread.cpp line 278:

> 276:     PerfTraceTime vm_op_timer(perf_accumulated_vm_operation_time());
> 277:     HOTSPOT_VMOPS_BEGIN(
> 278:                      (char *) op->name(), strlen(op->name()),

@dholmes-ora given that I'm editing `VMThread::evaluate_operation` and your comments about code style - do you want me to also change this type cast to `(char*)` to align with the preferred style?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2149450013

From jsikstro at openjdk.org  Mon Jun 16 09:55:12 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 16 Jun 2025 09:55:12 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v7]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <tcXjycyBkYEFGWHoxEjXXi3FFDmUaQf6V3wIFmsYhWQ=.06662a0c-1e81-46c5-9fab-8f12ca0b67fb@github.com>

> Hello,
> 
> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
> 
> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
> 
> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
> 
> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
> 
> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
> 
> Testing:
> * Oracle's tier 1-5

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

  Private member variables in ZObjectAlloactorImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/1885d763..4ef788d7

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

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

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

From aboldtch at openjdk.org  Mon Jun 16 10:03:30 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 16 Jun 2025 10:03:30 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v7]
In-Reply-To: <tcXjycyBkYEFGWHoxEjXXi3FFDmUaQf6V3wIFmsYhWQ=.06662a0c-1e81-46c5-9fab-8f12ca0b67fb@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <tcXjycyBkYEFGWHoxEjXXi3FFDmUaQf6V3wIFmsYhWQ=.06662a0c-1e81-46c5-9fab-8f12ca0b67fb@github.com>
Message-ID: <_QBZPZBf96-aR3lyWsh66c5h_UT--J1NNfMy7kSlxk8=.0adb4aab-4b2f-4831-aef4-95b0dad3e5ed@github.com>

On Mon, 16 Jun 2025 09:55:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
>> 
>> The storage of the static allocators for each ZPageAge has been moved from ZHeap into ZObjectAllocator, and initilization is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
>> 
>> Instead of storing eden and relocation allocators separately, they are now in a single array, which makes iterating over the allocators more straightforward (when retiring pages for example). I have opted to keep the getter for the eden allocator (`ZObjectAllocator::eden()`), but it can be swapped to `ZObjectAllocator::allocator(ZPageAge::eden)` if we prefer that instead.
>> 
>> `ZObjectAllocator::{alloc_object, alloc_object_for_relocation}` have been merged into a single `ZObjectAllocator::alloc_object()`, with a check to add a non-blocking flag or not. The null-check for eden allocation has been moved to its single caller in zCollectedHeap.cpp. This makes the API in ZObjectAllocator more general and we don't have to track methods for both eden and relocation allocations.
>> 
>> `_relocation_allocators` has been moved from ZAllocator to ZObjectAllocator and renamed to `NumRelocationAllocators` to be more consistent with the naming style in ZGC.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Private member variables in ZObjectAlloactorImpl

lgtm.

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25693#pullrequestreview-2931439144

From ayang at openjdk.org  Mon Jun 16 10:25:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 16 Jun 2025 10:25:38 GMT
Subject: RFR: 8359664: G1: Remove default arg for pretouch_workers of
 G1CollectedHeap::expand
Message-ID: <MGKFmhWE6J0NROZJyQae4YucZaWoFIj1zgmYc72M2F0=.d4812de8-6e34-41c4-b77b-ac9a596ea008@github.com>

Trivial removing unnecessary default arg value.

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

Commit messages:
 - g1-trivial-remove-default-arg

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

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

From jsikstro at openjdk.org  Mon Jun 16 11:02:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 16 Jun 2025 11:02:58 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v7]
In-Reply-To: <tcXjycyBkYEFGWHoxEjXXi3FFDmUaQf6V3wIFmsYhWQ=.06662a0c-1e81-46c5-9fab-8f12ca0b67fb@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <tcXjycyBkYEFGWHoxEjXXi3FFDmUaQf6V3wIFmsYhWQ=.06662a0c-1e81-46c5-9fab-8f12ca0b67fb@github.com>
Message-ID: <l-9VCRrax_w-INk-v3xlfXMJ7wtu9h6-DQFRb22TZWo=.631a4247-c8a4-49f7-ae0b-f744688a1944@github.com>

On Mon, 16 Jun 2025 09:55:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> The main purpose of this RFE is to merge the ZAllocator class into ZObjectAllocator. After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, with a few tweaks for different behavior for eden or relocation allocations. The goal is to make the code a bit easier to follow and generalise the different paths for eden and relocation allocations to a shared path.
>> 
>> The solution I propose adds a static-only interface called ZObjectAllocator, which interfaces with a number of statically allocated allocators of the class `ZObjectAllocatorImpl`. The ZObjectAllocatorImpl class is the combination of ZAllocator and ZObjectAllocator. The initialization of the static allocators is done via ZInitialize (calling into `ZObjectAllocator::initialize()`) instead of in the ZHeap constructor.
>> 
>> Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes over all allocators more straightforward (when retiring pages for example). The allocators are only used in ZObjectAllocator.cpp, and can only be accessed from there, or externally via the static functions in ZObjectAllocator.
>> 
>> `allob_object` and `alloc_tlab` now have intermediate calls with checks in ZHeap, so that ZObjectAllocator only exposes an `alloc_object`. This makes the API in ZObjectAllocator very clean and straightforward to understand. As a side note, I've made `ZHeap::out_of_memory` const so that it can be called from `ZHeap::alloc_object`, which is also const.
>> 
>> The new ZObjectAllocator now stores two static constants: `NumAllocators` and `NumRelocationAllocators`, which replaces `ZAllocator::_relocation_allocators`. I plan on moving `NumRelocationAllocators` to a more sensible place in a future patch.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Private member variables in ZObjectAlloactorImpl

FYI: I updated the description of the PR to match the latest changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25693#issuecomment-2976100895

From duke at openjdk.org  Mon Jun 16 11:25:16 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 11:25:16 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v6]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <hYV-Wcy1Z3qgRT0MQHpkZ-4ouZD8Tg6LwkYv14RNH6s=.4c6ca02b-d2da-4933-9104-beb67280f313@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Remove explicit super call and minor fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/895f3747..effaeede

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

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

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

From duke at openjdk.org  Mon Jun 16 11:31:51 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 11:31:51 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v7]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <8LJedORsD5AZ49XAf3_JjzbYhOa_HVvB0PMUWyI7m5s=.3cf83050-ed44-4516-96e1-ea87a97ae9fa@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Only sample if needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/effaeede..2ac00321

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

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

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

From duke at openjdk.org  Mon Jun 16 11:52:28 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 11:52:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
 <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
Message-ID: <jbnYC9JF8tUEu88HJ0DBOVQK59pc_qo722YmKZX7De0=.58085ec8-6f1d-4b55-a8b3-af7d2e7b9810@github.com>

On Mon, 16 Jun 2025 07:40:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> This seems reasonable though I'm unclear on some details. Could you give a
> high-level description of what times we capture for what threads and when, and
> the calculations involved. Thanks.

What threads:

* All GC threads e.g. director thread, sample threads, worker threads, driver
  threads (except for ZGC where I currently exclude the "runtime" threads which
  we may decide to change, see @tschatzl comments above)

* The VM thread, but only include VM operations related to GC

* The string deduplication thread

What times:

* CPU time for all the threads above

* CPU time for the entire process


When:

* VM thread:

  - If VM operation is GC and `-Xlog:gc` or more is enabled, sample `start`, and `end` CPU time
    for the GC operation. Add `end - start` to `gc_vm_vtime`.

* GC threads:

  - If `-Xlog:gc` or more is enabled, sample all GC threads and store the CPU
    time sum to `gc_threads_vtime` during VM exit.

* String deduplication thread:

  - If string deduplication is enabled and if `-Xlog:gc` or more is enabled
    sample CPU time during VM exit for that thread and store to `string_deduplication_vtime`

* Process:

  - If  `-Xlog:gc` or more is enabled, sample the CPU time for the entire process

Log accumulated CPU time `gc_threads_vtime + gc_vm_vtime + string_deduplication_vtime`
as a percentage of the total process CPU time. We sample the total process CPU 
time with the new method `os::elapsed_process_vtime`.

It should be noted from the above that calling elapsed_gc_vtime assumes that
-Xlog:gc or more is enabled. If one breaks this assumption the GC CPU time will
not include VM thread and may be horribly wrong (e.g. if one runs Serial).

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2976252452

From tschatzl at openjdk.org  Mon Jun 16 12:45:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 16 Jun 2025 12:45:28 GMT
Subject: RFR: 8359664: G1: Remove default arg for pretouch_workers of
 G1CollectedHeap::expand
In-Reply-To: <MGKFmhWE6J0NROZJyQae4YucZaWoFIj1zgmYc72M2F0=.d4812de8-6e34-41c4-b77b-ac9a596ea008@github.com>
References: <MGKFmhWE6J0NROZJyQae4YucZaWoFIj1zgmYc72M2F0=.d4812de8-6e34-41c4-b77b-ac9a596ea008@github.com>
Message-ID: <MAS2aTgVgxV5mSx-CThi7BekM6viu7j1I4mXHlRoHiI=.3d386de6-b7a4-4a6e-83b6-790892b79212@github.com>

On Mon, 16 Jun 2025 10:20:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unnecessary default arg value.

Trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25826#pullrequestreview-2931988369

From duke at openjdk.org  Mon Jun 16 12:50:17 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 12:50:17 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v8]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  operation_is_gc -> is_gc_operation per @stefank suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/2ac00321..b20c9740

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

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

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

From sroy at openjdk.org  Mon Jun 16 13:53:07 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 16 Jun 2025 13:53:07 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all
Message-ID: <nBuldyLzGPSPj7mdsnrrtyrx4Rol52jQW-67Sn0zQLc=.227796c6-6e1b-4540-9ac4-9bdb2a80c7c7@github.com>

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

we found the method names `update_all` of the class `GenerationCounters` and its subclasses are not so good. It is better to rename it to something like `update_capacity` (such as `ZGenerationCounters::update_capacity`).

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

Commit messages:
 -  copyright
 - update capacity

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

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

From mdoerr at openjdk.org  Mon Jun 16 13:59:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Jun 2025 13:59:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
Message-ID: <eKflnYAqlB11rSLWSuw6ZAeIzNQjESuZ_TBG1Le2dS4=.78600187-5347-45b7-855c-03ac92941117@github.com>

On Mon, 16 Jun 2025 08:26:38 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove is_sigill_not_entrant
>
> Just FYI, s390 build is broken with this change: 
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
> #  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
> #
> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
> # Problematic frame:
> # V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> 
> stack trace: 
> 
> Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
> v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
> j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
> j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
> j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
> j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
> j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
> j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
> j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
> j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
> ....

@offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183)
Should be 0.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2976308103

From mdoerr at openjdk.org  Mon Jun 16 13:59:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Jun 2025 13:59:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
Message-ID: <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>

On Fri, 13 Jun 2025 19:18:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove is_sigill_not_entrant

Seems like arm32 has the same issue: https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199
The init value shouldn't have the sticky bit set.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2976766766

From sroy at openjdk.org  Mon Jun 16 14:04:34 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 16 Jun 2025 14:04:34 GMT
Subject: Withdrawn: JDK-8349077 : Rename GenerationCounters::update_all
In-Reply-To: <nBuldyLzGPSPj7mdsnrrtyrx4Rol52jQW-67Sn0zQLc=.227796c6-6e1b-4540-9ac4-9bdb2a80c7c7@github.com>
References: <nBuldyLzGPSPj7mdsnrrtyrx4Rol52jQW-67Sn0zQLc=.227796c6-6e1b-4540-9ac4-9bdb2a80c7c7@github.com>
Message-ID: <WuP1dIKU9hvpeGLdOfWDHRHIZHkBqUQCyeAY62gNRR8=.dfe66b31-bfca-4531-aa2c-9375e3795188@github.com>

On Mon, 16 Jun 2025 13:31:00 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names `update_all` of the class `GenerationCounters` and its subclasses are not so good. It is better to rename it to something like `update_capacity` (such as `ZGenerationCounters::update_capacity`).

This pull request has been closed without being integrated.

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

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

From amitkumar at openjdk.org  Mon Jun 16 15:07:29 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 16 Jun 2025 15:07:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
Message-ID: <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>

On Mon, 16 Jun 2025 08:26:38 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove is_sigill_not_entrant
>
> Just FYI, s390 build is broken with this change: 
> 
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
> #  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
> #
> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
> # Problematic frame:
> # V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
> #
> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
> #
> # If you would like to submit a bug report, please visit:
> #   https://bugreport.java.com/bugreport/crash.jsp
> #
> 
> 
> stack trace: 
> 
> Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
> v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
> j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
> j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
> j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
> j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
> j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
> j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
> j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
> j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
> ....

> @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0.

Thank you Martin for the suggestion. 

@dean-long would you please add this diff, fixing s390x build. I ran tier1 test with fastdebug, test are clean; 


diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
index e78906708af..2d663061aec 100644
--- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
@@ -180,7 +180,7 @@ void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) {
     __ z_lg(Z_R0_scratch, in_bytes(bs_nm->thread_disarmed_guard_value_offset()), Z_thread); // 6 bytes
 
     // Compare to current patched value:
-    __ z_cfi(Z_R0_scratch, /* to be patched */ -1); // 6 bytes (2 + 4 byte imm val)
+    __ z_cfi(Z_R0_scratch, /* to be patched */ 0); // 6 bytes (2 + 4 byte imm val)
 
     // Conditional Jump
     __ z_larl(Z_R14, (Assembler::instr_len((unsigned long)LARL_ZOPC) + Assembler::instr_len((unsigned long)BCR_ZOPC)) / 2); // 6 bytes
diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
index d3f6540a3ea..bb1d9ce6037 100644
--- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
+++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
@@ -3197,7 +3197,7 @@ class StubGenerator: public StubCodeGenerator {
 
     // VM-Call: BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr)
     __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetNMethod::nmethod_stub_entry_barrier));
-    __ z_ltr(Z_R0_scratch, Z_RET);
+    __ z_ltr(Z_RET, Z_RET);
 
     // VM-Call Epilogue
     __ restore_volatile_regs(Z_SP, frame::z_abi_160_size, true, false);

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2977015369

From sroy at openjdk.org  Mon Jun 16 15:09:40 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 16 Jun 2025 15:09:40 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all
Message-ID: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>

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

we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).



Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

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

Commit messages:
 - update_capacity exists

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

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

From ayang at openjdk.org  Mon Jun 16 15:25:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 16 Jun 2025 15:25:45 GMT
Subject: RFR: 8359664: G1: Remove default arg for pretouch_workers of
 G1CollectedHeap::expand
In-Reply-To: <MGKFmhWE6J0NROZJyQae4YucZaWoFIj1zgmYc72M2F0=.d4812de8-6e34-41c4-b77b-ac9a596ea008@github.com>
References: <MGKFmhWE6J0NROZJyQae4YucZaWoFIj1zgmYc72M2F0=.d4812de8-6e34-41c4-b77b-ac9a596ea008@github.com>
Message-ID: <8IcsmRrq2RGY8o6jbv1tiaWaqBWxSk3O3QiEgUPkeLk=.8284e595-8d83-4a33-b1ed-e41dcfbab614@github.com>

On Mon, 16 Jun 2025 10:20:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unnecessary default arg value.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25826#issuecomment-2977067317

From ayang at openjdk.org  Mon Jun 16 15:25:45 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 16 Jun 2025 15:25:45 GMT
Subject: Integrated: 8359664: G1: Remove default arg for pretouch_workers of
 G1CollectedHeap::expand
In-Reply-To: <MGKFmhWE6J0NROZJyQae4YucZaWoFIj1zgmYc72M2F0=.d4812de8-6e34-41c4-b77b-ac9a596ea008@github.com>
References: <MGKFmhWE6J0NROZJyQae4YucZaWoFIj1zgmYc72M2F0=.d4812de8-6e34-41c4-b77b-ac9a596ea008@github.com>
Message-ID: <KWMK3rGnSx-6VMw9oCnMFuPuSDBcyvJTqRxGMu0LnFE=.4c920d0e-d9ac-4c01-a1f2-f1bbb5c17e57@github.com>

On Mon, 16 Jun 2025 10:20:48 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unnecessary default arg value.

This pull request has now been integrated.

Changeset: 59460ff7
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/59460ff700e36f8dba5cb50ddc60f107d7d5ad7f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8359664: G1: Remove default arg for pretouch_workers of G1CollectedHeap::expand

Reviewed-by: tschatzl

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

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

From ayang at openjdk.org  Mon Jun 16 15:41:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 16 Jun 2025 15:41:01 GMT
Subject: RFR: 8359701: G1: Move heap expansion time tracking of
 G1CollectedHeap:expand to call site
Message-ID: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>

Simple patch of moving time-tracking logic from callee to caller, which removes a default arg. The default-arg is there because there are other callers that don't use/need this time-tracking logic.

Test: tier1

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

Commit messages:
 - g1-expand-time

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

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

From ayang at openjdk.org  Mon Jun 16 15:47:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 16 Jun 2025 15:47:28 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <PSAFnFHWw74BD-uP56umBijHt_2SYAWh0faSZMrAt6c=.e09b1cfc-9906-4571-8a84-a2f521149589@github.com>

On Mon, 16 Jun 2025 14:39:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

I believe the ticket was only about this method, which handles only capacity.


void GenerationCounters::update_all(size_t curr_capacity) {
  _current_size->set_value(curr_capacity);
}


However, in the patch, this method is renamed as well. Not sure if this is intentional.


void HSpaceCounters::update_all(size_t capacity, size_t used) {
  update_capacity(capacity);
  update_used(used);
}

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

PR Comment: https://git.openjdk.org/jdk/pull/25833#issuecomment-2977143602

From yzheng at openjdk.org  Mon Jun 16 16:14:28 2025
From: yzheng at openjdk.org (Yudi Zheng)
Date: Mon, 16 Jun 2025 16:14:28 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <_dbY3cVxby--JIeliaIXLOB8jKH4oPX97JRvj3AqqhM=.30829434-40eb-4113-bce2-de119f26a27b@github.com>

On Mon, 16 Jun 2025 14:39:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Since the base is before the branch off, could you please merge master before integration and see if GHA still passes? This also helps us testing libgraal compilation.

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

PR Comment: https://git.openjdk.org/jdk/pull/25833#issuecomment-2977233601

From sroy at openjdk.org  Mon Jun 16 16:36:14 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 16 Jun 2025 16:36:14 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v2]
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <yGGVqIj5czY74eAIfGmyfMGXKU8eohyXvGG2Gcpgr14=.75a73dc4-ea20-4c3c-8108-a6f98796bedd@github.com>

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Suchismith Roy 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 'openjdk:master' into update_memory_state
 - update_capacity exists

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25833/files
  - new: https://git.openjdk.org/jdk/pull/25833/files/cf2d66d5..419f3d5f

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

  Stats: 202092 lines in 3611 files changed: 122500 ins; 53972 del; 25620 mod
  Patch: https://git.openjdk.org/jdk/pull/25833.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25833/head:pull/25833

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

From xpeng at openjdk.org  Mon Jun 16 16:47:30 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 16 Jun 2025 16:47:30 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
 [v3]
In-Reply-To: <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
 <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
Message-ID: <ph5oOLlFbu-Sn5RIISQLpz_5URG41wauFE49xRRvhd8=.2e2d2118-e3f8-49e5-80cd-673c07233b7a@github.com>

On Thu, 12 Jun 2025 22:10:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Consolidate read table cleaning"
>   
>   This reverts commit 9552021cbeec699e7b04db81fa68819c23b7dab7.

Marked as reviewed by xpeng (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/25735#pullrequestreview-2932825279

From xpeng at openjdk.org  Mon Jun 16 16:47:30 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 16 Jun 2025 16:47:30 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
 [v3]
In-Reply-To: <GHjpKb3XaH9ordY5cWVGnqEwjwrXs_pPfgoxnckwNNk=.5e985710-7a3f-4c21-93a0-b14fecf8a845@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
 <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
 <GHjpKb3XaH9ordY5cWVGnqEwjwrXs_pPfgoxnckwNNk=.5e985710-7a3f-4c21-93a0-b14fecf8a845@github.com>
Message-ID: <5VL86NUy8SQCA02KjzGeF74KhEC7b7uFcKqipeiSJuE=.cca1f9fe-f124-4e5f-bf12-a2a13335db89@github.com>

On Thu, 12 Jun 2025 22:44:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We don't want to clean the read table during init-mark because that's a safepoint. We can safely clean the read table concurrently because only the GC thread has access to it.

Thanks, we want to minimize the time at safepoint, I understand this part. My question was about swap_card_tables, I we don't have to do it at safepoint, we could move swap_card_tables out of the init-mark safepoint and move to close to mark_read_table_as_clean to make the code slight earlier to understand. @ysramakrishna also suggested this, I saw your attempt and rollback, thanks for the explanations.

It looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25735#issuecomment-2977329569

From ayang at openjdk.org  Mon Jun 16 17:00:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 16 Jun 2025 17:00:50 GMT
Subject: [jdk25] RFR: 8359272: Several vmTestbase/compact tests timed out
 on large memory machine
In-Reply-To: <VkN-x7w3wr833QunuXjxWU2zXJh3wNvcdvWKeN5PkCs=.957cd08c-ac90-4b99-98d2-870d6a16c714@github.com>
References: <VkN-x7w3wr833QunuXjxWU2zXJh3wNvcdvWKeN5PkCs=.957cd08c-ac90-4b99-98d2-870d6a16c714@github.com>
Message-ID: <NMtLGNTTm6dAa0cWs9QIMoZ1kK-MHcFk38XGOXUYHrE=.7312b5f2-54a5-4d59-8a43-a97ee5f5becf@github.com>

On Fri, 13 Jun 2025 08:59:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a0fb35c8](https://github.com/openjdk/jdk/commit/a0fb35c8379295d2927c18d694ea52f7b7488a2b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 13 Jun 2025 and was reviewed by Thomas Schatzl and Albert Mingkun Yang.
> 
> Thanks!

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25794#pullrequestreview-2932856991

From ysr at openjdk.org  Mon Jun 16 17:15:30 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 16 Jun 2025 17:15:30 GMT
Subject: RFR: 8359394: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <yafhgRUcOsermOyGoRk3A1cklCmJrjOtBUuhRDBSVbg=.3aa7f942-000d-4fc4-b00f-e0245db73509@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove `GCCause::_no_cause_specified` (only referenced by Shenandoah) and add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string` and the `SA` analog.

Thanks for changing the title/summary to broaden scope.

Re-approved; ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2932895948

From stefank at openjdk.org  Mon Jun 16 18:12:34 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Jun 2025 18:12:34 GMT
Subject: RFR: 8359394: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <nylY2hgZL81KmVnTDF-HBBGPRRfHd_Y5JLYda6PFZh0=.b4a48507-7378-40dd-a6e3-30311379aca9@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove `GCCause::_no_cause_specified` (only referenced by Shenandoah) and add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string` and the `SA` analog.

I've reviewed the non-shenandoah parts of this patch.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2933048021

From ysr at openjdk.org  Mon Jun 16 18:36:29 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 16 Jun 2025 18:36:29 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
 [v3]
In-Reply-To: <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
 <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
Message-ID: <j6ukqICqyUmNm0Dnw-ojbiBLLm8Wce3VacWyFh-sAWU=.dbe1fe11-876b-46a0-8fa2-79136c416d4e@github.com>

On Thu, 12 Jun 2025 22:10:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Consolidate read table cleaning"
>   
>   This reverts commit 9552021cbeec699e7b04db81fa68819c23b7dab7.

Thanks for the explanation; let me digest this and re-review with this background. I'll update before EOD.

> @ysramakrishna - The refactoring you suggest is not so simple, alas. We have to be very careful about the ordering of cleaning the `read` table, resetting the mark bitmap and swapping the card tables. Genshen does not clean the `read` table at the end of a concurrent cycle (we _could_ do this, but we'd still need to do the same in a degenerated cycle). The complexity comes from swapping the card tables in a concurrent cycle. We must not let a subsequent degenerated cycle swap them a second time. The degenerated cycle can only clean the `read` table if there was no active concurrent cycle (lest it throw away critical remembered set data).
> 
> However, the degenerated cycle must also clear the mark bitmaps if the concurrent cycle degenerated during the root scan (the degenerated cycle will rescan the roots). Of course, we cannot clear the mark bitmaps if the concurrent cycle degenerated during the mark phase. So, for the degenerated cycle, clearing the mark bitmaps and cleaning the read table need to happen in two different cases and it doesn't work if they're combined into the same method (and I don't think adding a method parameter to sometimes clear the mark bitmap and sometimes the read table will make the code any easier to understand).

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

PR Comment: https://git.openjdk.org/jdk/pull/25735#issuecomment-2977654895

From wkemper at openjdk.org  Mon Jun 16 20:46:28 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 16 Jun 2025 20:46:28 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
 [v3]
In-Reply-To: <5VL86NUy8SQCA02KjzGeF74KhEC7b7uFcKqipeiSJuE=.cca1f9fe-f124-4e5f-bf12-a2a13335db89@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
 <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
 <GHjpKb3XaH9ordY5cWVGnqEwjwrXs_pPfgoxnckwNNk=.5e985710-7a3f-4c21-93a0-b14fecf8a845@github.com>
 <5VL86NUy8SQCA02KjzGeF74KhEC7b7uFcKqipeiSJuE=.cca1f9fe-f124-4e5f-bf12-a2a13335db89@github.com>
Message-ID: <a7BOAdBd3wtxUihX6nd1aFSR9aV6YxZu5KspXLKyWJI=.e53724b0-9c39-47e7-ac8e-b2aa6735cbd0@github.com>

On Mon, 16 Jun 2025 16:44:25 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> @pengxiaolong - We don't want to clean the read table during init-mark because that's a safepoint. We can safely clean the read table concurrently because only the GC thread has access to it.
>> 
>> @ysramakrishna - The refactoring you suggest is not so simple, alas. We have to be very careful about the ordering of cleaning the `read` table, resetting the mark bitmap and swapping the card tables. Genshen does not clean the `read` table at the end of a concurrent cycle (we _could_ do this, but we'd still need to do the same in a degenerated cycle). The complexity comes from swapping the card tables in a concurrent cycle. We must not let a subsequent degenerated cycle swap them a second time. The degenerated cycle can only clean the `read` table if there was no active concurrent cycle (lest it throw away critical remembered set data). 
>> 
>> However, the degenerated cycle must also clear the mark bitmaps if the concurrent cycle degenerated during the root scan (the degenerated cycle will rescan the roots). Of course, we cannot clear the mark bitmaps if the concurrent cycle degenerated during the mark phase. So, for the degenerated cycle, clearing the mark bitmaps and cleaning the read table need to happen in two different cases and it doesn't work if they're combined into the same method (and I don't think adding a method parameter to sometimes clear the mark bitmap and sometimes the read table will make the code any easier to understand).
>
>> We don't want to clean the read table during init-mark because that's a safepoint. We can safely clean the read table concurrently because only the GC thread has access to it.
> 
> Thanks, we want to minimize the time at safepoint, I understand this part. My question was about swap_card_tables, I we don't have to do it at safepoint, we could move swap_card_tables out of the init-mark safepoint and move to close to mark_read_table_as_clean to make the code slight earlier to understand. @ysramakrishna also suggested this, I saw your attempt and rollback, thanks for the explanations.
> 
> It looks good to me.

@pengxiaolong - I think we _could_ swap card table pointers with a thread local handshake, but if we don't remove `init-mark` entirely, it would just mean stopping all the threads twice. I'm inclined to leave it on the safepoint for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25735#issuecomment-2978071741

From duke at openjdk.org  Mon Jun 16 21:15:29 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 16 Jun 2025 21:15:29 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v8]
In-Reply-To: <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>
Message-ID: <I1w52ppE-DOj6l4srchOPKVMIJ9lZt6DF093icbXDzo=.c6496623-d7d2-4fcb-b305-c03d8af80508@github.com>

On Mon, 16 Jun 2025 12:50:17 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   operation_is_gc -> is_gc_operation per @stefank suggestion

> After all both of these VM operations are VM_GC_Operations.

@tschatzl Thanks for pointing that out, that's an excellent point!

Your comment caused me to reflect over that I have currently defined all operations as GC operations if they inherit from `VM_GC_Sync_Operation`. However the following should probably not be strictly counted as a GC activity: `VM_GC_HeapInspection`, `VM_PopulateDynamicDumpSharedSpace`, `VM_Verify`, `VM_PopulateDumpSharedSpace`. I will update the PR.

> So one option is duplicating these workers in G1/Parallel too, and fix https://bugs.openjdk.org/browse/JDK-8277394. 

Thanks for the suggestion, I agree that we should do that to fix the root issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2978167405

From dlong at openjdk.org  Mon Jun 16 23:34:43 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:34:43 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v5]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <ZN6kFFf-mJIH6ATSurRl3RmKBp7MUytFmJJRMvdEag4=.92f1c003-6de3-47cb-9d97-cb75f5d9b348@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  s390 fix courtesy of Amit Kumar

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/c1ebde09..a7d784b2

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

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

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

From dlong at openjdk.org  Mon Jun 16 23:34:43 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:34:43 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
 <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>
Message-ID: <Bluq4RaeKqEQJqYp4iVrX3AjaUQ9T1yQqmQx7iYw9A8=.596712ac-1525-4428-b80c-bb10098e26dd@github.com>

On Mon, 16 Jun 2025 15:04:23 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Just FYI, s390 build is broken with this change: 
>> 
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
>> #  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
>> #
>> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
>> # Problematic frame:
>> # V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> 
>> 
>> stack trace: 
>> 
>> Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
>> v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
>> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
>> j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
>> j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
>> j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
>> j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
>> j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
>> j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
>> j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
>> j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
>> ....
>
>> @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0.
> 
> Thank you Martin for the suggestion. 
> 
> @dean-long would you please add this diff, fixing s390x build. I ran tier1 test with fastdebug, test are clean; 
> 
> 
> diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> index e78906708af..2d663061aec 100644
> --- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> +++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> @@ -180,7 +180,7 @@ void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) {
>      __ z_lg(Z_R0_scratch, in_bytes(bs_nm->thread_disarmed_guard_value_offset()), Z_thread); // 6 bytes
>  
>      // Compare to current patched value:
> -    __ z_cfi(Z_R0_scratch, /* to be patched */ -1); // 6 bytes (2 + 4 byte imm val)
> +    __ z_cfi(Z_R0_scratch, /* to be patched */ 0); // 6 bytes (2 + 4 byte imm val)
>  
>      // Conditional Jump
>      __ z_larl(Z_R14, (Assembler::instr_len((unsigned long)LARL_ZOPC) + Assembler::instr_len((unsigned long)BCR_ZOPC)) / 2); // 6 bytes
> diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> index d3f6540a3ea..bb1d9ce6037 100644
> --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> @@ -3197,7 +3197,7 @@ class StubGenerator: public StubCodeGenerator {
>  
>      // VM-Call: BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr)
>      __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetNMethod::nmethod_stub_entry_barrier));
> -    __ z_ltr(Z_R0_scratch, Z_RET);
> +    __ z_ltr(Z_RET, Z_RET);
>  
>      // VM-Call Epilogue
>      __ restore_volatile_regs(Z_SP, frame::z_abi_160_size, true, false);

Thanks @offamitkumar.  Could you explain the `__ z_ltr(Z_R0_scratch, Z_RET);` change, for my curiosity?  Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978470825

From dlong at openjdk.org  Mon Jun 16 23:39:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:39:08 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v6]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <T_ifzZkpru-qrX0_TKGUplo2NhJP_gK_WeZu5rHtFdg=.4a2f286e-c25e-48e6-84f7-a0225177af68@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  arm32 fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/a7d784b2..c98f3864

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

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

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

From dlong at openjdk.org  Mon Jun 16 23:39:08 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:39:08 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>
Message-ID: <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com>

On Mon, 16 Jun 2025 13:56:30 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Seems like arm32 has the same issue:
> 
> https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199
> 
> The init value shouldn't have the sticky bit set.

Thanks, I pushed a potential fix for that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978476161

From dlong at openjdk.org  Mon Jun 16 23:45:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:45:57 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v7]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <k0ooW4tQFu9rv5NHyktrIii96Uv8r-Frics2nUnxnSg=.8db6f73e-60da-4374-864e-14a691156f58@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  rename arm_with to guard_with

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/c98f3864..3ac6dec0

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

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

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

From dlong at openjdk.org  Mon Jun 16 23:45:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 16 Jun 2025 23:45:57 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
Message-ID: <Rs8iKPDKHrHqN4ULCnUCcdmwuIWxalw8lXn-YhWHW9c=.bafc9947-1c19-4688-8478-44ffe831e2af@github.com>

On Mon, 16 Jun 2025 00:48:40 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove is_sigill_not_entrant
>
> src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 109:
> 
>> 107: }
>> 108: 
>> 109: void ZBarrierSetNMethod::arm_with(nmethod* nm, int value) {
> 
> I don't usually comment on names, but could we call this guard_with instead? We tried to stop saying "arm" about things used also for disarming and we have (hopefully) been consistent about calling that "guard" instead.

Good suggestion.  Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2151070290

From dlong at openjdk.org  Tue Jun 17 00:05:30 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 17 Jun 2025 00:05:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
Message-ID: <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>

On Mon, 16 Jun 2025 00:54:48 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove is_sigill_not_entrant
>
> src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 114:
> 
>> 112:   // Preserve the sticky bit
>> 113:   if (is_not_entrant(nm)) {
>> 114:     value |= not_entrant;
> 
> Is it possible to have a race where another thread sets an nmethod to not entrant and the thread calling this making the nmethod entry barrier not entrant?
> 
> If this was called to disarm a method and then enter it, it seems a bit sneaky in that case that we pass the nmethod entry barrier even though we under the lock see that it is not entrant. Probably okay but still feels like it might be more robust if the thread setting an nmethod to not entrant is always the one that arms the nmethod entry barrier.

If I understand your concern correctly, there is no race.  The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section.  After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way.
And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2151084557

From dlong at openjdk.org  Tue Jun 17 00:13:30 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 17 Jun 2025 00:13:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <0-Re4fyQGaSyOl-bYm1h9LT5a0TKKrgJCHquooXOIkQ=.d6044248-6188-4705-b564-90fa3d2d7762@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <0-Re4fyQGaSyOl-bYm1h9LT5a0TKKrgJCHquooXOIkQ=.d6044248-6188-4705-b564-90fa3d2d7762@github.com>
Message-ID: <UoVXZCNouvAqNqc77bktWvKke8XV6HXXgWt4NmoFbHg=.d74782fc-763f-45a3-a1bc-57d73e419ebb@github.com>

On Sat, 14 Jun 2025 09:23:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance.

For ZGC I am using a per-nmethod lock:
  ZLocker<ZReentrantLock> locker(ZNMethod::lock_for_nmethod(nm));

I don't know what benchmarks to run to check the performance for functions like Deoptimization::deoptimize_all_marked, so I welcome any help with this.

One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978525224

From ysr at openjdk.org  Tue Jun 17 00:15:27 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 17 Jun 2025 00:15:27 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
 [v3]
In-Reply-To: <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
 <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
Message-ID: <CjZ6dIlFiEB6B2CPYf6-WdhawkxODxLh_WhGT_QlkE0=.c09a4c8b-28e6-4574-9592-01ab2b063d60@github.com>

On Thu, 12 Jun 2025 22:10:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Consolidate read table cleaning"
>   
>   This reverts commit 9552021cbeec699e7b04db81fa68819c23b7dab7.

Reviewed and approved; see previous comment.

?

@earthling-amzn : 

> Genshen does not clean the read table at the end of a concurrent cycle (we could do this, but we'd still need to do the same in a degenerated cycle).

Yes, and I am suggesting we do that to clean up and consolidate the cleaning along multiple paths into the same method that is invoked at an identical point in the Collector's state machine, irrespective of whether we arrived at that state via a concurrent collection or a degeneration.

> The complexity comes from swapping the card tables in a concurrent cycle. We must not let a subsequent degenerated cycle swap them a second time. The degenerated cycle can only clean the read table if there was no active concurrent cycle (lest it throw away critical remembered set data).

The swapping must happen at the start of the marking cycle. In similar fashion, the state of the Collector's state machine should indicate if the swap has already been done in this cycle or not. The specifics of wheher the swap was done by a degenerate or concurrent collection should then not matter?

> However, the degenerated cycle must also clear the mark bitmaps if the concurrent cycle degenerated during the root scan (the degenerated cycle will rescan the roots). Of course, we cannot clear the mark bitmaps if the concurrent cycle degenerated during the mark phase. So, for the degenerated cycle, clearing the mark bitmaps and cleaning the read table need to happen in two different cases and it doesn't work if they're combined into the same method (and I don't think adding a method parameter to sometimes clear the mark bitmap and sometimes the read table will make the code any easier to understand).

That's OK, they can be in two different methods, with the clearing of the marking bitmap done in one case and not in the other based on when the degeeration occurred. I think may be we don't have sufficiently refined Collector state machine at the moment which may be part of the problem here.

That having been said, I can understand that:

> The refactoring you suggest is not so simple, alas. 

In particular, if our eventual future plan is to do away with degeneration as we know it today, then the refactoring to achieve the clean up I suggest may be moot.

With that in mind, I am going to approve the changes in their current form as they look right if somewhat difficult to maintain and prove the correctness of. (The more refined state machine approach would likely make it easier, but will be moot once degeneration is eliminated in the future.)

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25735#pullrequestreview-2933812072
PR Comment: https://git.openjdk.org/jdk/pull/25735#issuecomment-2978526794

From syan at openjdk.org  Tue Jun 17 00:46:32 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Jun 2025 00:46:32 GMT
Subject: [jdk25] RFR: 8359272: Several vmTestbase/compact tests timed out
 on large memory machine
In-Reply-To: <NMtLGNTTm6dAa0cWs9QIMoZ1kK-MHcFk38XGOXUYHrE=.7312b5f2-54a5-4d59-8a43-a97ee5f5becf@github.com>
References: <VkN-x7w3wr833QunuXjxWU2zXJh3wNvcdvWKeN5PkCs=.957cd08c-ac90-4b99-98d2-870d6a16c714@github.com>
 <NMtLGNTTm6dAa0cWs9QIMoZ1kK-MHcFk38XGOXUYHrE=.7312b5f2-54a5-4d59-8a43-a97ee5f5becf@github.com>
Message-ID: <MSWx4wB3CA67dOlTd5MY0eKiwe-fqiozAUO04CDwhK8=.25a549fb-4db5-4913-9183-23efafa65a8e@github.com>

On Mon, 16 Jun 2025 16:57:25 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [a0fb35c8](https://github.com/openjdk/jdk/commit/a0fb35c8379295d2927c18d694ea52f7b7488a2b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by SendaoYan on 13 Jun 2025 and was reviewed by Thomas Schatzl and Albert Mingkun Yang.
>> 
>> Thanks!
>
> Marked as reviewed by ayang (Reviewer).

@albertnetymk Thanks for the approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/25794#issuecomment-2978573623

From syan at openjdk.org  Tue Jun 17 00:46:33 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 17 Jun 2025 00:46:33 GMT
Subject: [jdk25] Integrated: 8359272: Several vmTestbase/compact tests timed
 out on large memory machine
In-Reply-To: <VkN-x7w3wr833QunuXjxWU2zXJh3wNvcdvWKeN5PkCs=.957cd08c-ac90-4b99-98d2-870d6a16c714@github.com>
References: <VkN-x7w3wr833QunuXjxWU2zXJh3wNvcdvWKeN5PkCs=.957cd08c-ac90-4b99-98d2-870d6a16c714@github.com>
Message-ID: <pBAnn7jt2Dae8Kde2t4506k7X76QA971tVq3pFIIKjE=.7c397dd8-9245-4a39-b125-0a3961bac51e@github.com>

On Fri, 13 Jun 2025 08:59:30 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [a0fb35c8](https://github.com/openjdk/jdk/commit/a0fb35c8379295d2927c18d694ea52f7b7488a2b) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 13 Jun 2025 and was reviewed by Thomas Schatzl and Albert Mingkun Yang.
> 
> Thanks!

This pull request has now been integrated.

Changeset: eb727dcb
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb727dcb51963add7966a9d86b08520a003af0ca
Stats:     12 lines in 4 files changed: 8 ins; 0 del; 4 mod

8359272: Several vmTestbase/compact tests timed out on large memory machine

Reviewed-by: ayang
Backport-of: a0fb35c8379295d2927c18d694ea52f7b7488a2b

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

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

From amitkumar at openjdk.org  Tue Jun 17 03:46:33 2025
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 17 Jun 2025 03:46:33 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <TIjZO_0VNfCRPgMPKQxrsKoYQ1sUMqC85VMA9dZAvWk=.211ee6de-1b89-4aeb-93d8-cb41e13cc011@github.com>
 <a6qUUAt1FkBiLSeMP3t79yKOPDge6Zv5Z_pLF0sD_IU=.e120976d-ac33-44ca-92be-289f1bce8fed@github.com>
Message-ID: <-0Y5IM8MHOmPZpTHRGKK5hnBLA5TyRV871YLJ1XnSAI=.027d1976-faf5-40f7-a7d0-fa05d6b986b4@github.com>

On Mon, 16 Jun 2025 15:04:23 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

>> Just FYI, s390 build is broken with this change: 
>> 
>> 
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  Internal Error (/home/amit/jdk/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:196), pid=1779086, tid=1779117
>> #  assert(!nm->is_osr_method() || may_enter) failed: OSR nmethods should always be entrant after migration
>> #
>> # JRE version: OpenJDK Runtime Environment (26.0) (fastdebug build 26-internal-adhoc.amit.jdk)
>> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 26-internal-adhoc.amit.jdk, mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, linux-s390x)
>> # Problematic frame:
>> # V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e
>> #
>> # Core dump will be written. Default location: Core dumps may be processed with "/lib/systemd/systemd-coredump %P %u %g %s %t 9223372036854775808 %h %d" (or dumping to /home/amit/jdk/make/core.1779086)
>> #
>> # If you would like to submit a bug report, please visit:
>> #   https://bugreport.java.com/bugreport/crash.jsp
>> #
>> 
>> 
>> stack trace: 
>> 
>> Stack: [0x000003ff9e580000,0x000003ff9e680000],  sp=0x000003ff9e67b068,  free space=1004k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.so+0x40b196]  BarrierSetNMethod::nmethod_stub_entry_barrier(unsigned char**)+0x15e  (barrierSetNMethod.cpp:196)
>> v  ~StubRoutines::method_entry_barrier 0x000003ff9050cd18
>> J 282% c2 sun.nio.fs.UnixPath.initOffsets()V java.base (189 bytes) @ 0x000003ff90c4f0c8 [0x000003ff90c4f080+0x0000000000000048]
>> j  sun.nio.fs.UnixPath.getFileName()Lsun/nio/fs/UnixPath;+1 java.base
>> j  sun.nio.fs.UnixFileSystemProvider.isHidden(Ljava/nio/file/Path;)Z+6 java.base
>> j  java.nio.file.Files.isHidden(Ljava/nio/file/Path;)Z+5 java.base
>> j  jdk.internal.module.ModulePath.isHidden(Ljava/nio/file/Path;)Z+1 java.base
>> j  jdk.internal.module.ModulePath.lambda$explodedPackages$0(Ljava/nio/file/Path;Ljava/nio/file/attribute/BasicFileAttributes;)Z+11 java.base
>> j  jdk.internal.module.ModulePath$$Lambda+0x00000000a105cbe0.test(Ljava/lang/Object;Ljava/lang/Object;)Z+12 java.base
>> j  java.nio.file.Files.lambda$find$0(Ljava/util/function/BiPredicate;Ljava/nio/file/FileTreeWalker$Event;)Z+9 java.base
>> j  java.nio.file.Files$$Lambda+0x00000000a10646c0.test(Ljava/lang/Object;)Z+8 java.base
>> ....
>
>> @offamitkumar: The problem is probably the initialization to -1: [`z_cfi(Z_R0_scratch, /* to be patched */ -1);`.](https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp#L183) Should be 0.
> 
> Thank you Martin for the suggestion. 
> 
> @dean-long would you please add this diff, fixing s390x build. I ran tier1 test with fastdebug, test are clean; 
> 
> 
> diff --git a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> index e78906708af..2d663061aec 100644
> --- a/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> +++ b/src/hotspot/cpu/s390/gc/shared/barrierSetAssembler_s390.cpp
> @@ -180,7 +180,7 @@ void BarrierSetAssembler::nmethod_entry_barrier(MacroAssembler* masm) {
>      __ z_lg(Z_R0_scratch, in_bytes(bs_nm->thread_disarmed_guard_value_offset()), Z_thread); // 6 bytes
>  
>      // Compare to current patched value:
> -    __ z_cfi(Z_R0_scratch, /* to be patched */ -1); // 6 bytes (2 + 4 byte imm val)
> +    __ z_cfi(Z_R0_scratch, /* to be patched */ 0); // 6 bytes (2 + 4 byte imm val)
>  
>      // Conditional Jump
>      __ z_larl(Z_R14, (Assembler::instr_len((unsigned long)LARL_ZOPC) + Assembler::instr_len((unsigned long)BCR_ZOPC)) / 2); // 6 bytes
> diff --git a/src/hotspot/cpu/s390/stubGenerator_s390.cpp b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> index d3f6540a3ea..bb1d9ce6037 100644
> --- a/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> +++ b/src/hotspot/cpu/s390/stubGenerator_s390.cpp
> @@ -3197,7 +3197,7 @@ class StubGenerator: public StubCodeGenerator {
>  
>      // VM-Call: BarrierSetNMethod::nmethod_stub_entry_barrier(address* return_address_ptr)
>      __ call_VM_leaf(CAST_FROM_FN_PTR(address, BarrierSetNMethod::nmethod_stub_entry_barrier));
> -    __ z_ltr(Z_R0_scratch, Z_RET);
> +    __ z_ltr(Z_RET, Z_RET);
>  
>      // VM-Call Epilogue
>      __ restore_volatile_regs(Z_SP, frame::z_abi_160_size, true, false);

> Thanks @offamitkumar. Could you explain the `__ z_ltr(Z_R0_scratch, Z_RET);` change, for my curiosity? Thanks.

`ltr` instruction stands for "load and test" (32 bit). Initially we were loading the value from `Z_RET` to `Z_R0_scratch` and then it will be compared against 0. But in this case there is no requirement of loading the value in Z_R0, as it's not being used further. So we can load the value again in `Z_RET` and the compare it against 0. There is nothing wrong in previous solution, it's just killing Z_R0 for nothing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2978824615

From dholmes at openjdk.org  Tue Jun 17 05:49:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 05:49:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <djVKbomyI9yqnNVulCU26eHLGhU1M6oPIPd_nc2s8sY=.66ab1eeb-0073-4f32-8335-145a40374fcf@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
 <djVKbomyI9yqnNVulCU26eHLGhU1M6oPIPd_nc2s8sY=.66ab1eeb-0073-4f32-8335-145a40374fcf@github.com>
Message-ID: <xpg-TJBJi4KGmq-Lwhh4ByocP12vI2wy8HW3bVKJPo0=.7ad745a6-0af2-436c-8494-2b33be715797@github.com>

On Mon, 16 Jun 2025 09:17:05 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add CPU time tracking for string deduplication to log_gc_vtime
>
> src/hotspot/share/runtime/vmThread.cpp line 278:
> 
>> 276:     PerfTraceTime vm_op_timer(perf_accumulated_vm_operation_time());
>> 277:     HOTSPOT_VMOPS_BEGIN(
>> 278:                      (char *) op->name(), strlen(op->name()),
> 
> @dholmes-ora given that I'm editing `VMThread::evaluate_operation` and your comments about code style - do you want me to also change this type cast to `(char*)` to align with the preferred style?

Please do. Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2151372297

From dholmes at openjdk.org  Tue Jun 17 05:59:30 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 05:59:30 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v5]
In-Reply-To: <jbnYC9JF8tUEu88HJ0DBOVQK59pc_qo722YmKZX7De0=.58085ec8-6f1d-4b55-a8b3-af7d2e7b9810@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <ijQ3PXMHac36NlIxQoJuaA5-U6RODrVXmx73nyUumzE=.444ca5cf-4303-4fe5-a369-93b40fe55d1a@github.com>
 <hxmpvcKBjzyQLDXXDdumwDprLabMCILTBSae6YJvH-0=.abec85de-972b-4f11-9e13-8ed40e3f5545@github.com>
 <jbnYC9JF8tUEu88HJ0DBOVQK59pc_qo722YmKZX7De0=.58085ec8-6f1d-4b55-a8b3-af7d2e7b9810@github.com>
Message-ID: <Vh5cR_pON98NQD3F3fFpBOxCsr8H67-AUSLoELxB6Sc=.6e37acc0-d81e-4973-b698-ae140500b9ca@github.com>

On Mon, 16 Jun 2025 11:49:56 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> What threads: ...

Thanks for that. Once the details have stabilized I suggest adding this summary of operation to the JBS issue as well. 

I will let GC folk do the formal reviews/approvals here, but this looks quite reasonable to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2979038213

From dholmes at openjdk.org  Tue Jun 17 05:59:31 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 17 Jun 2025 05:59:31 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v8]
In-Reply-To: <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <gV5EfuZ8zrD4UTtW2duEkKhoKqFbONuPDP1APSkHFD4=.b51c5539-6ec3-4cb6-9889-dcf8ec855082@github.com>
Message-ID: <9L-KW83n2k0foCwz6l7a2p5mMqkhrY6eigZL9FyRscU=.b8528248-522f-421d-8eae-184261a387d7@github.com>

On Mon, 16 Jun 2025 12:50:17 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   operation_is_gc -> is_gc_operation per @stefank suggestion

src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 29:

> 27: #include "logging/log.hpp"
> 28: #include "memory/universe.hpp"
> 29: #include "runtime/vmThread.hpp"

Nit: if you put this in the .hpp file you can do away with the forward decl for VMThread that is in there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2151383344

From tschatzl at openjdk.org  Tue Jun 17 06:10:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 17 Jun 2025 06:10:29 GMT
Subject: RFR: 8359701: G1: Move heap expansion time tracking of
 G1CollectedHeap:expand to call site
In-Reply-To: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>
References: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>
Message-ID: <h0oCRj_YD1SjORMWy1Oab3-Cn_Hzk3YC_294DZsSZXQ=.6d03acc8-a2fc-4c08-b687-317e98249c65@github.com>

On Mon, 16 Jun 2025 15:35:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple patch of moving time-tracking logic from callee to caller, which removes a default arg. The default-arg is there because there are other callers that don't use/need this time-tracking logic.
> 
> Test: tier1

Marked as reviewed by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2395:

> 2393:     // No need for an ergo logging here,
> 2394:     // expansion_amount() does this when it returns a value > 0.
> 2395:     Ticks expand_start_instant = Ticks::now();

Suggestion:

    Ticks expand_start = Ticks::now();


It is very unusual to add an `_instant` postfix to similar variables, regardless of whether using `Ticks` or the `elapsedTime` API, so I suggested to remove it.

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

PR Review: https://git.openjdk.org/jdk/pull/25835#pullrequestreview-2934248722
PR Review Comment: https://git.openjdk.org/jdk/pull/25835#discussion_r2151396041

From thomas.schatzl at oracle.com  Tue Jun 17 07:04:06 2025
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Tue, 17 Jun 2025 09:04:06 +0200
Subject: G1 AHS JEP draft + Request for Feedback and Testing on G1 Heap
 Resizing Prototype
In-Reply-To: <e79f6798-83c5-49f2-89c3-b8f0d0cd94a1@oracle.com>
References: <BL4PR21MB46262D1979B187498F3D6A30E58D2@BL4PR21MB4626.namprd21.prod.outlook.com>
 <CH3SPRMB01346040FC26F0B06D0B0DCBE59EA@CH3SPRMB0134.namprd21.prod.outlook.com>
 <e79f6798-83c5-49f2-89c3-b8f0d0cd94a1@oracle.com>
Message-ID: <43eb75b4-f6a4-436c-9a77-69caf83ae25b@oracle.com>

Hi all,

   just an update on AHS for G1 update:

- I started a draft of a JEP for this effort [0]. The scope of this 
effort for G1 is very different and reduced compared to the ZGC one: G1 
already has adaptive heap sizing, and while we are fixing minor issues 
around it, it is not in scope for that. Instead the change is be about 
determining the maximum heap size based on external memory availability, 
some tweaks of default min/max heap size, and G1GCIntensity.

The fixes for heap sizing are collected in the bug tracker using the 
gc-g1-heap-sizing label [1].

There are some (mostly minor) open questions still, that are all marked 
inline; the only major one is G1GCIntensity (the equivalent of 
ZGCIntensity), not completely sure whether we want/need that because all 
of that could be achieved the same using the (to be) managed 
GCTimeRatio/CPUUsagePercent flag.

- Ivan posted the PR about G1 better following GCTimeRatio for resizing 
yesterday [2].

_Now_ is the time to test this, so we encourage you to give it a try.

Thanks,
   Thomas

[0] https://bugs.openjdk.org/browse/JDK-8359211
[1] https://bugs.openjdk.org/issues/?jql=labels%20%3D%20gc-g1-heap-resizing
[2] https://github.com/openjdk/jdk/pull/25832


From roland at openjdk.org  Tue Jun 17 07:52:16 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 17 Jun 2025 07:52:16 GMT
Subject: [jdk25] RFR: 8358334: C2/Shenandoah: incorrect execution with Unsafe
Message-ID: <SO5bEwqowWRpXtIQvf8UEE6elTe9Ul2oCvu-3vIeLkY=.cdc47529-e936-4343-ad27-c536e2ed5337@github.com>

Hi all,

This pull request contains a backport of commit [1fcede05](https://github.com/openjdk/jdk/commit/1fcede053cca360c96606c1034b2a365a4fada82) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Roland Westrelin on 12 Jun 2025 and was reviewed by William Kemper and Aleksey Shipilev.

Backport applies cleanly.

Thanks!

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

Commit messages:
 - Backport 1fcede053cca360c96606c1034b2a365a4fada82

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

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

From ayang at openjdk.org  Tue Jun 17 08:01:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 17 Jun 2025 08:01:13 GMT
Subject: RFR: 8359701: G1: Move heap expansion time tracking of
 G1CollectedHeap:expand to call site [v2]
In-Reply-To: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>
References: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>
Message-ID: <4Mxr34Pkbfpy_4hMsosXNRDH8RfWBZa2FGZOeb8dkYc=.7faa1dd0-9383-4b55-bd4c-89ec1ee8787e@github.com>

> Simple patch of moving time-tracking logic from callee to caller, which removes a default arg. The default-arg is there because there are other callers that don't use/need this time-tracking logic.
> 
> Test: tier1

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 g1-expand-time
 - review
 - g1-expand-time

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25835/files
  - new: https://git.openjdk.org/jdk/pull/25835/files/2c358c59..50fcbc22

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

  Stats: 1260 lines in 35 files changed: 404 ins; 751 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/25835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25835/head:pull/25835

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

From thartmann at openjdk.org  Tue Jun 17 08:10:36 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 17 Jun 2025 08:10:36 GMT
Subject: [jdk25] RFR: 8358334: C2/Shenandoah: incorrect execution with
 Unsafe
In-Reply-To: <SO5bEwqowWRpXtIQvf8UEE6elTe9Ul2oCvu-3vIeLkY=.cdc47529-e936-4343-ad27-c536e2ed5337@github.com>
References: <SO5bEwqowWRpXtIQvf8UEE6elTe9Ul2oCvu-3vIeLkY=.cdc47529-e936-4343-ad27-c536e2ed5337@github.com>
Message-ID: <6UlV04v4D-z9ERdvYjIR2h-hXICqfmUWuGX9UN6dIT8=.c1328dc8-66f1-4499-9f92-70a6e5efc305@github.com>

On Tue, 17 Jun 2025 07:46:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1fcede05](https://github.com/openjdk/jdk/commit/1fcede053cca360c96606c1034b2a365a4fada82) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Roland Westrelin on 12 Jun 2025 and was reviewed by William Kemper and Aleksey Shipilev.
> 
> Backport applies cleanly.
> 
> Thanks!

Looks good.

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

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25845#pullrequestreview-2934573108

From roland at openjdk.org  Tue Jun 17 08:10:36 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 17 Jun 2025 08:10:36 GMT
Subject: [jdk25] RFR: 8358334: C2/Shenandoah: incorrect execution with
 Unsafe
In-Reply-To: <6UlV04v4D-z9ERdvYjIR2h-hXICqfmUWuGX9UN6dIT8=.c1328dc8-66f1-4499-9f92-70a6e5efc305@github.com>
References: <SO5bEwqowWRpXtIQvf8UEE6elTe9Ul2oCvu-3vIeLkY=.cdc47529-e936-4343-ad27-c536e2ed5337@github.com>
 <6UlV04v4D-z9ERdvYjIR2h-hXICqfmUWuGX9UN6dIT8=.c1328dc8-66f1-4499-9f92-70a6e5efc305@github.com>
Message-ID: <dXJfLCfynMxliIlr5pUXPHsBeU7_ap36XlqxiwJsREk=.442806a8-63b4-4511-a6fd-4446f3e5f820@github.com>

On Tue, 17 Jun 2025 08:04:55 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [1fcede05](https://github.com/openjdk/jdk/commit/1fcede053cca360c96606c1034b2a365a4fada82) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>> 
>> The commit being backported was authored by Roland Westrelin on 12 Jun 2025 and was reviewed by William Kemper and Aleksey Shipilev.
>> 
>> Backport applies cleanly.
>> 
>> Thanks!
>
> Looks good.

@TobiHartmann thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25845#issuecomment-2979354555

From roland at openjdk.org  Tue Jun 17 08:10:37 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 17 Jun 2025 08:10:37 GMT
Subject: [jdk25] Integrated: 8358334: C2/Shenandoah: incorrect execution with
 Unsafe
In-Reply-To: <SO5bEwqowWRpXtIQvf8UEE6elTe9Ul2oCvu-3vIeLkY=.cdc47529-e936-4343-ad27-c536e2ed5337@github.com>
References: <SO5bEwqowWRpXtIQvf8UEE6elTe9Ul2oCvu-3vIeLkY=.cdc47529-e936-4343-ad27-c536e2ed5337@github.com>
Message-ID: <99u6nre3LDFGl1DSuXcnu0e17tg6WZmkZGhM5eB504c=.1db042da-6ec6-4726-a0ef-502e7716bc11@github.com>

On Tue, 17 Jun 2025 07:46:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [1fcede05](https://github.com/openjdk/jdk/commit/1fcede053cca360c96606c1034b2a365a4fada82) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Roland Westrelin on 12 Jun 2025 and was reviewed by William Kemper and Aleksey Shipilev.
> 
> Backport applies cleanly.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 46cfc1e1
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46cfc1e1940ff6b91c4f0cb0a9161fd0aef37c38
Stats:     153 lines in 3 files changed: 117 ins; 26 del; 10 mod

8358334: C2/Shenandoah: incorrect execution with Unsafe

Reviewed-by: thartmann
Backport-of: 1fcede053cca360c96606c1034b2a365a4fada82

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

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

From sroy at openjdk.org  Tue Jun 17 08:14:47 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 17 Jun 2025 08:14:47 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v3]
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <EGGN6OK2qYZDyxnbli5JzPnQZS7Pp4kxxk6RARdK4RY=.0c15fe00-ee38-4e74-9d1c-6813a0e8e57b@github.com>

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:

 - update capacity only for Generation counter
 - Revert "update_capacity exists"
   
   This reverts commit cf2d66d598d90f1343d1ad7a4f30607c3374a0f8.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25833/files
  - new: https://git.openjdk.org/jdk/pull/25833/files/419f3d5f..59839a66

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

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

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

From tschatzl at openjdk.org  Tue Jun 17 08:23:32 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 17 Jun 2025 08:23:32 GMT
Subject: RFR: 8359701: G1: Move heap expansion time tracking of
 G1CollectedHeap:expand to call site [v2]
In-Reply-To: <4Mxr34Pkbfpy_4hMsosXNRDH8RfWBZa2FGZOeb8dkYc=.7faa1dd0-9383-4b55-bd4c-89ec1ee8787e@github.com>
References: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>
 <4Mxr34Pkbfpy_4hMsosXNRDH8RfWBZa2FGZOeb8dkYc=.7faa1dd0-9383-4b55-bd4c-89ec1ee8787e@github.com>
Message-ID: <mUk24bBiyKIZmNeyGgwiVjbw6tbyOsmYeiRtsqTf9mQ=.ac488ba3-8909-498e-868e-29a29636854f@github.com>

On Tue, 17 Jun 2025 08:01:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple patch of moving time-tracking logic from callee to caller, which removes a default arg. The default-arg is there because there are other callers that don't use/need this time-tracking logic.
>> 
>> Test: tier1
>
> 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 g1-expand-time
>  - review
>  - g1-expand-time

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25835#pullrequestreview-2934636739

From sroy at openjdk.org  Tue Jun 17 08:28:09 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 17 Jun 2025 08:28:09 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v4]
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <Ouiw3RBddqljuvERyw-N8mtQPHmmHTB4Nk9fqgPuj_Q=.dadc679e-2f95-4f09-9589-6c2440a00735@github.com>

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  psOldGen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25833/files
  - new: https://git.openjdk.org/jdk/pull/25833/files/59839a66..88c41602

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

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

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

From ayang at openjdk.org  Tue Jun 17 08:28:09 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 17 Jun 2025 08:28:09 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v3]
In-Reply-To: <EGGN6OK2qYZDyxnbli5JzPnQZS7Pp4kxxk6RARdK4RY=.0c15fe00-ee38-4e74-9d1c-6813a0e8e57b@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <EGGN6OK2qYZDyxnbli5JzPnQZS7Pp4kxxk6RARdK4RY=.0c15fe00-ee38-4e74-9d1c-6813a0e8e57b@github.com>
Message-ID: <nybLTpuZlfjZf0XUi9MTIJYCfbGrBmfRrS-Lg6ezhIc=.5cd475ea-1863-40d7-9977-b678f0c32fed@github.com>

On Tue, 17 Jun 2025 08:14:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update capacity only for Generation counter
>  - Revert "update_capacity exists"
>    
>    This reverts commit cf2d66d598d90f1343d1ad7a4f30607c3374a0f8.

Thanks for the revision.

I believe the one in `ZGenerationCounters` can be removed now.


  void update_capacity(size_t capacity) {
    update_all(capacity);
  }

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

PR Comment: https://git.openjdk.org/jdk/pull/25833#issuecomment-2979417249

From sroy at openjdk.org  Tue Jun 17 08:34:47 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 17 Jun 2025 08:34:47 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v5]
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <7pVHTK4sJLrs6GITxmgux8MmQ8CRuwky6t-1d1HRrTU=.7fdd3896-158b-4c19-9180-3a20cc3d1c96@github.com>

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  update zgenerationcounter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25833/files
  - new: https://git.openjdk.org/jdk/pull/25833/files/88c41602..bd26817c

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

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

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

From iwalulya at openjdk.org  Tue Jun 17 12:24:29 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 17 Jun 2025 12:24:29 GMT
Subject: RFR: 8359701: G1: Move heap expansion time tracking of
 G1CollectedHeap:expand to call site [v2]
In-Reply-To: <4Mxr34Pkbfpy_4hMsosXNRDH8RfWBZa2FGZOeb8dkYc=.7faa1dd0-9383-4b55-bd4c-89ec1ee8787e@github.com>
References: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>
 <4Mxr34Pkbfpy_4hMsosXNRDH8RfWBZa2FGZOeb8dkYc=.7faa1dd0-9383-4b55-bd4c-89ec1ee8787e@github.com>
Message-ID: <OK0aam06kBAC1CRaD3PhiqrBPIGfMyX0I_WRjOTm8cw=.69d41a79-fe4a-4d31-aba7-4bf4f0650b1d@github.com>

On Tue, 17 Jun 2025 08:01:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple patch of moving time-tracking logic from callee to caller, which removes a default arg. The default-arg is there because there are other callers that don't use/need this time-tracking logic.
>> 
>> Test: tier1
>
> 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 g1-expand-time
>  - review
>  - g1-expand-time

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25835#pullrequestreview-2935434150

From ayang at openjdk.org  Tue Jun 17 12:34:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 17 Jun 2025 12:34:33 GMT
Subject: RFR: 8359701: G1: Move heap expansion time tracking of
 G1CollectedHeap:expand to call site [v2]
In-Reply-To: <4Mxr34Pkbfpy_4hMsosXNRDH8RfWBZa2FGZOeb8dkYc=.7faa1dd0-9383-4b55-bd4c-89ec1ee8787e@github.com>
References: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>
 <4Mxr34Pkbfpy_4hMsosXNRDH8RfWBZa2FGZOeb8dkYc=.7faa1dd0-9383-4b55-bd4c-89ec1ee8787e@github.com>
Message-ID: <JLKzA2XbDoco8UmNAvjL-nDalGrYj-MPSUnC58UOS4o=.47c45a1f-0f85-484a-a940-dba214a76086@github.com>

On Tue, 17 Jun 2025 08:01:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple patch of moving time-tracking logic from callee to caller, which removes a default arg. The default-arg is there because there are other callers that don't use/need this time-tracking logic.
>> 
>> Test: tier1
>
> 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 g1-expand-time
>  - review
>  - g1-expand-time

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25835#issuecomment-2980195183

From ayang at openjdk.org  Tue Jun 17 12:34:33 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 17 Jun 2025 12:34:33 GMT
Subject: Integrated: 8359701: G1: Move heap expansion time tracking of
 G1CollectedHeap:expand to call site
In-Reply-To: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>
References: <0l1r8Yf6Acs16Kcx0u3jIoUMWyZGqXaVfiEUZ3K6JdA=.782f602a-6158-4eeb-9839-9e3cb513719d@github.com>
Message-ID: <2Q3XNhrTgml96qgbXUv41833qUzu2EUmrDCsQ-GuPQo=.633539e6-1ed5-43fc-a33a-682587f07893@github.com>

On Mon, 16 Jun 2025 15:35:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple patch of moving time-tracking logic from callee to caller, which removes a default arg. The default-arg is there because there are other callers that don't use/need this time-tracking logic.
> 
> Test: tier1

This pull request has now been integrated.

Changeset: f62f1178
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f62f1178aa01d812ee8ffb1d3dd165b4cf157186
Stats:     12 lines in 2 files changed: 1 ins; 6 del; 5 mod

8359701: G1: Move heap expansion time tracking of G1CollectedHeap:expand to call site

Reviewed-by: tschatzl, iwalulya

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

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

From mdoerr at openjdk.org  Tue Jun 17 12:52:34 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 17 Jun 2025 12:52:34 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>
 <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com>
Message-ID: <NXEl1i8ECESz1PQoLstGmaOkzffoX_17X6Bsjqz7WGA=.1f7458a4-43b1-40c8-bade-895ddd7ded1e@github.com>

On Mon, 16 Jun 2025 23:35:43 GMT, Dean Long <dlong at openjdk.org> wrote:

> > Seems like arm32 has the same issue:
> > https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199
> > 
> > The init value shouldn't have the sticky bit set.
> 
> Thanks, I pushed a potential fix for that.

Unfortunately, 0xBEAFDEAD also has the MSB set. Shouldn't we better use 0 like on all other platforms?

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2980261201

From ayang at openjdk.org  Tue Jun 17 13:29:02 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 17 Jun 2025 13:29:02 GMT
Subject: RFR: 8359825: Parallel: Simplify MutableNUMASpace::ensure_parsability
Message-ID: <8D8xoSoDjedCVLEYc9Vz1aVtYPCY8RCpZDBHvJEMzE0=.9140dbf3-4cf4-4564-b5b4-abff66e3433f@github.com>

Simple `fill_with_object` -> `fill_with_objects` API  change to push the implementation logic to the callee.

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

Commit messages:
 - pgc-fill-words

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

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

From iwalulya at openjdk.org  Tue Jun 17 13:43:45 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 17 Jun 2025 13:43:45 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v2]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <Qa30yKdGbs7oW_dLLLcdGPW2QHsqVcW4N_Hh3XbvmTM=.c000c44b-54ed-4e04-b6ce-ad985be64f04@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  remove unrequired changes - kim

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25832/files
  - new: https://git.openjdk.org/jdk/pull/25832/files/65730422..81a1e189

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

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

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

From sroy at openjdk.org  Tue Jun 17 14:59:01 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 17 Jun 2025 14:59:01 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v6]
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <ZwsxXACvAszjzn0JU6I-aA2rx62DD_o-zViqGyDWbKU=.f701f11b-4767-49ad-a43d-d2cf4a918963@github.com>

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  g1Monitoring

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25833/files
  - new: https://git.openjdk.org/jdk/pull/25833/files/bd26817c..7bb69a1d

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

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

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

From iwalulya at openjdk.org  Tue Jun 17 17:28:08 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 17 Jun 2025 17:28:08 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v3]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <VTJoGAsFIbJ73d2gDNhuQuzDYSFxEHmQ-hpCpux3qb4=.41a7e1f3-f410-4bc2-843b-2e257760da42@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
 - remove unrequired changes - kim
 - clean init

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

Changes: https://git.openjdk.org/jdk/pull/25832/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25832&range=02
  Stats: 576 lines in 16 files changed: 360 ins; 81 del; 135 mod
  Patch: https://git.openjdk.org/jdk/pull/25832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25832/head:pull/25832

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

From dlong at openjdk.org  Tue Jun 17 20:55:29 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 17 Jun 2025 20:55:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <NXEl1i8ECESz1PQoLstGmaOkzffoX_17X6Bsjqz7WGA=.1f7458a4-43b1-40c8-bade-895ddd7ded1e@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <SHo1MHmCagVN25GGMf9dy8DXeRuxBxtN924XLZ-hUBw=.b40304b3-67e1-4cd6-b5d8-45f15aee0c94@github.com>
 <-qfpN8-hyWv-QosNnOUvLaZtsI0Kr1vXsTIV6Tqvd-w=.badb50d8-3f05-41d1-bc90-d5939d6b571f@github.com>
 <NXEl1i8ECESz1PQoLstGmaOkzffoX_17X6Bsjqz7WGA=.1f7458a4-43b1-40c8-bade-895ddd7ded1e@github.com>
Message-ID: <87D1GHpnuO66YKnlxRh6JOlp7AZoZxhLBDbCpUG230A=.9119d110-62ba-4083-9a85-9bf78f5b462b@github.com>

On Tue, 17 Jun 2025 12:50:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> > > Seems like arm32 has the same issue:
> > > https://github.com/openjdk/jdk/blob/9d060574e5dbd13e634f00d749d0108ceff1fae8/src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp#L199
> > > 
> > > The init value shouldn't have the sticky bit set.
> > 
> > 
> > Thanks, I pushed a potential fix for that.
> 
> Unfortunately, 0xBEAFDEAD also has the MSB set. Shouldn't we better use 0 like on all other platforms?

Oops, I was tripped up trying to be clever.  Yes, I'm fine with using 0.  I'll fix it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2981800170

From dlong at openjdk.org  Tue Jun 17 20:59:46 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 17 Jun 2025 20:59:46 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

Dean Long has updated the pull request incrementally with one additional commit since the last revision:

  2nd try at arm fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25764/files
  - new: https://git.openjdk.org/jdk/pull/25764/files/3ac6dec0..3e306dde

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

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

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

From wkemper at openjdk.org  Tue Jun 17 21:20:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 17 Jun 2025 21:20:40 GMT
Subject: RFR: 8357976: GenShen crash in swap_card_tables: Should be clean
 [v3]
In-Reply-To: <CjZ6dIlFiEB6B2CPYf6-WdhawkxODxLh_WhGT_QlkE0=.c09a4c8b-28e6-4574-9592-01ab2b063d60@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
 <dpo3e1f5q1xe3MxkRyGoYs26jykQl7qg8YYtuUTl8oA=.0ba67ed6-ba73-4b14-b949-aae6003de160@github.com>
 <CjZ6dIlFiEB6B2CPYf6-WdhawkxODxLh_WhGT_QlkE0=.c09a4c8b-28e6-4574-9592-01ab2b063d60@github.com>
Message-ID: <sw8t067N68oZGHJhSxUDtEg5u6nIK9Uf1LxS1ly4ZBk=.560b3498-dba1-4d8d-ab4b-441b7ad1fb15@github.com>

On Tue, 17 Jun 2025 00:12: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:
>> 
>>   Revert "Consolidate read table cleaning"
>>   
>>   This reverts commit 9552021cbeec699e7b04db81fa68819c23b7dab7.
>
> @earthling-amzn : 
> 
>> Genshen does not clean the read table at the end of a concurrent cycle (we could do this, but we'd still need to do the same in a degenerated cycle).
> 
> Yes, and I am suggesting we do that to clean up and consolidate the cleaning along multiple paths into the same method that is invoked at an identical point in the Collector's state machine, irrespective of whether we arrived at that state via a concurrent collection or a degeneration.
> 
>> The complexity comes from swapping the card tables in a concurrent cycle. We must not let a subsequent degenerated cycle swap them a second time. The degenerated cycle can only clean the read table if there was no active concurrent cycle (lest it throw away critical remembered set data).
> 
> The swapping must happen at the start of the marking cycle. In similar fashion, the state of the Collector's state machine should indicate if the swap has already been done in this cycle or not. The specifics of wheher the swap was done by a degenerate or concurrent collection should then not matter?
> 
>> However, the degenerated cycle must also clear the mark bitmaps if the concurrent cycle degenerated during the root scan (the degenerated cycle will rescan the roots). Of course, we cannot clear the mark bitmaps if the concurrent cycle degenerated during the mark phase. So, for the degenerated cycle, clearing the mark bitmaps and cleaning the read table need to happen in two different cases and it doesn't work if they're combined into the same method (and I don't think adding a method parameter to sometimes clear the mark bitmap and sometimes the read table will make the code any easier to understand).
> 
> That's OK, they can be in two different methods, with the clearing of the marking bitmap done in one case and not in the other based on when the degeeration occurred. I think may be we don't have sufficiently refined Collector state machine at the moment which may be part of the problem here.
> 
> That having been said, I can understand that:
> 
>> The refactoring you suggest is not so simple, alas. 
> 
> In particular, if our eventual future plan is to do away with degeneration as we know it today, then the refactoring to achieve the clean up I suggest may be moot.
> 
> With that in mind, I am going to approve the changes in their current form as they look right if somewhat difficult to maintain and prove the correctness of. (The more refined state machine approach would likely make it easier, but will be moot once degeneration is el...

Thanks for the review @ysramakrishna . The plan is to get rid of degenerated cycles, but if the plan changes we certainly need to invest in a stronger state machine for the GC here.

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

PR Comment: https://git.openjdk.org/jdk/pull/25735#issuecomment-2981851757

From wkemper at openjdk.org  Tue Jun 17 21:20:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 17 Jun 2025 21:20:41 GMT
Subject: Integrated: 8357976: GenShen crash in swap_card_tables: Should be
 clean
In-Reply-To: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
References: <oJHVyiiim5PQDLgK3j1cgED8Kv-jAcR9AdMSOPyzAqQ=.31ccfc92-3844-4975-b5e1-984d932a7117@github.com>
Message-ID: <eo01j8OizFzYDv5XwzAcHvdNAdHkEMWG7cAiYJ72sKE=.4c0e3ba7-63ab-43ce-9aa3-3865e4f50c35@github.com>

On Tue, 10 Jun 2025 20:14:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Degenerated cycles must also clean the `read` card table before swapping it with the `write` card table.

This pull request has now been integrated.

Changeset: 382f870c
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/382f870cd53d69dfc1d2b96150aa2c026e47f642
Stats:     17 lines in 2 files changed: 10 ins; 4 del; 3 mod

8357976: GenShen crash in swap_card_tables: Should be clean

Reviewed-by: kdnilsen, cslucas, ysr, xpeng

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

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

From tschatzl at openjdk.org  Wed Jun 18 07:07:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 18 Jun 2025 07:07:28 GMT
Subject: RFR: 8359825: Parallel: Simplify
 MutableNUMASpace::ensure_parsability
In-Reply-To: <8D8xoSoDjedCVLEYc9Vz1aVtYPCY8RCpZDBHvJEMzE0=.9140dbf3-4cf4-4564-b5b4-abff66e3433f@github.com>
References: <8D8xoSoDjedCVLEYc9Vz1aVtYPCY8RCpZDBHvJEMzE0=.9140dbf3-4cf4-4564-b5b4-abff66e3433f@github.com>
Message-ID: <lTNr4CWsOiszMNbRyYmSxAfLzRhvhzFr7fZUxRPY4YQ=.45f56c05-d9c6-4d83-a49a-34fea44422b7@github.com>

On Tue, 17 Jun 2025 13:24:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple `fill_with_object` -> `fill_with_objects` API  change to push the implementation logic to the callee.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25852#pullrequestreview-2937979658

From mdoerr at openjdk.org  Wed Jun 18 08:33:37 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Jun 2025 08:33:37 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
Message-ID: <sc4GKWY-5ptN8_s6UfuDx26vLOMpv23NNw-74eRGNNo=.13ccc52e-49e5-495f-9fe6-6dd922a8a2c2@github.com>

On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd try at arm fix

Recent changes look good. Thanks!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2938255719

From ayang at openjdk.org  Wed Jun 18 09:01:00 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 18 Jun 2025 09:01:00 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
Message-ID: <spZuyO1XSapuWZgnkytsHbL1hsKUIWMPQLD4xbEHJz0=.3233c3a7-6b78-462f-9c3c-4909910ff768@github.com>

On Sun, 18 May 2025 15:36:03 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - pgc-size-policy
>
> src/hotspot/share/gc/parallel/psYoungGen.cpp line 268:
> 
>> 266:   size_t original_committed_size = virtual_space()->committed_size();
>> 267: 
>> 268:   while (true) {
> 
> The `while` statement only runs once. May we find a better way to refactor the code?

@lgxbslgx I did some restructuring based on some offline discussion -- hopefully, the new style is more readable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2154053199

From ayang at openjdk.org  Wed Jun 18 09:00:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 18 Jun 2025 09:00:58 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - review
 - Merge branch 'master' into pgc-size-policy
 - merge
 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - merge
 - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=12
  Stats: 4371 lines in 31 files changed: 520 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From ayang at openjdk.org  Wed Jun 18 09:03:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 18 Jun 2025 09:03:28 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v6]
In-Reply-To: <ZwsxXACvAszjzn0JU6I-aA2rx62DD_o-zViqGyDWbKU=.f701f11b-4767-49ad-a43d-d2cf4a918963@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <ZwsxXACvAszjzn0JU6I-aA2rx62DD_o-zViqGyDWbKU=.f701f11b-4767-49ad-a43d-d2cf4a918963@github.com>
Message-ID: <qr0T1uENxttpO328Nm5WrWGxtHXC0T7pXYIZ-iGN7aw=.2a5d52a5-71f2-44ec-b072-851278900f8e@github.com>

On Tue, 17 Jun 2025 14:59:01 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   g1Monitoring

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25833#pullrequestreview-2938359236

From stefank at openjdk.org  Wed Jun 18 09:31:30 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 18 Jun 2025 09:31:30 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v6]
In-Reply-To: <ZwsxXACvAszjzn0JU6I-aA2rx62DD_o-zViqGyDWbKU=.f701f11b-4767-49ad-a43d-d2cf4a918963@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <ZwsxXACvAszjzn0JU6I-aA2rx62DD_o-zViqGyDWbKU=.f701f11b-4767-49ad-a43d-d2cf4a918963@github.com>
Message-ID: <krrbu8KadaF1BPBP_tKZf4MiVUr9UhDgJwjBTH8tb_I=.bbcea176-1835-4959-885a-9b2c165cca9f@github.com>

On Tue, 17 Jun 2025 14:59:01 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   g1Monitoring

src/hotspot/share/gc/z/zServiceability.cpp line 70:

> 68:   void update_capacity(size_t capacity) {
> 69:     update_all(capacity);
> 70:   }

Could you also delete line 67.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25833#discussion_r2154104691

From stefank at openjdk.org  Wed Jun 18 09:31:30 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 18 Jun 2025 09:31:30 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v6]
In-Reply-To: <krrbu8KadaF1BPBP_tKZf4MiVUr9UhDgJwjBTH8tb_I=.bbcea176-1835-4959-885a-9b2c165cca9f@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <ZwsxXACvAszjzn0JU6I-aA2rx62DD_o-zViqGyDWbKU=.f701f11b-4767-49ad-a43d-d2cf4a918963@github.com>
 <krrbu8KadaF1BPBP_tKZf4MiVUr9UhDgJwjBTH8tb_I=.bbcea176-1835-4959-885a-9b2c165cca9f@github.com>
Message-ID: <H1aSUmWywDhAHCSIDpYaTAtSbMht8cD4aLSwmVTKo04=.864d47c3-213c-407d-b6e7-0a2c892a9063@github.com>

On Wed, 18 Jun 2025 09:18:32 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   g1Monitoring
>
> src/hotspot/share/gc/z/zServiceability.cpp line 70:
> 
>> 68:   void update_capacity(size_t capacity) {
>> 69:     update_all(capacity);
>> 70:   }
> 
> Could you also delete line 67.

Or maybe even better just entirely delete `ZGenerationCounters` and replace its usages with `GenerationCounters`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25833#discussion_r2154111929

From eosterlund at openjdk.org  Wed Jun 18 11:36:30 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 18 Jun 2025 11:36:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
Message-ID: <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>

On Tue, 17 Jun 2025 00:02:29 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/gc/z/zBarrierSetNMethod.cpp line 114:
>> 
>>> 112:   // Preserve the sticky bit
>>> 113:   if (is_not_entrant(nm)) {
>>> 114:     value |= not_entrant;
>> 
>> Is it possible to have a race where another thread sets an nmethod to not entrant and the thread calling this making the nmethod entry barrier not entrant?
>> 
>> If this was called to disarm a method and then enter it, it seems a bit sneaky in that case that we pass the nmethod entry barrier even though we under the lock see that it is not entrant. Probably okay but still feels like it might be more robust if the thread setting an nmethod to not entrant is always the one that arms the nmethod entry barrier.
>
> If I understand your concern correctly, there is no race.  The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section.  After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way.
> And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level.

My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code.
Does that make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2154370247

From ayang at openjdk.org  Wed Jun 18 11:49:36 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 18 Jun 2025 11:49:36 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v3]
In-Reply-To: <VTJoGAsFIbJ73d2gDNhuQuzDYSFxEHmQ-hpCpux3qb4=.41a7e1f3-f410-4bc2-843b-2e257760da42@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <VTJoGAsFIbJ73d2gDNhuQuzDYSFxEHmQ-hpCpux3qb4=.41a7e1f3-f410-4bc2-843b-2e257760da42@github.com>
Message-ID: <3MBZ11WVojPRr6vcJxxaepOi6mO0GjF_j9gLGkU9jTI=.749e7301-2e8d-4d32-8f4e-887b8997a6b2@github.com>

On Tue, 17 Jun 2025 17:28:08 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
>  - remove unrequired changes - kim
>  - clean init

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 887:

> 885:   } else {
> 886:     shrink(resize_bytes);
> 887:     uncommit_regions_if_necessary();

I wonder if it's more symmetric if this uncommit logic is inlined to `shrink`.

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

> 168:   product(size_t, G1MinimumPercentOfGCTimeRatio, 25, EXPERIMENTAL,          \
> 169:           "Percentage of GCTimeRatio G1 will try to avoid going below.")    \
> 170:           range(0, 100)                                                     \

If they are in [0,100], maybe `uint` is enough?

src/hotspot/share/utilities/numberSeq.cpp line 151:

> 149:   AbsSeq(alpha), _length(length), _next(0) {
> 150:   _sequence = NEW_C_HEAP_ARRAY(double, _length, mtInternal);
> 151:   TruncatedSeq::reset();

Not sure why a new method (`reset`) is needed inside this PR.

src/hotspot/share/utilities/numberSeq.hpp line 50:

> 48: 
> 49: protected:
> 50:   uint    _num; // the number of elements in the sequence

All `int` -> `uint` changes in this class/file are good; can they be extracted out to its own PR/ticket?

src/hotspot/share/utilities/numberSeq.hpp line 132:

> 130: 
> 131:   virtual void reset();
> 132:   bool is_full() const { return _length == _num; }

Seems unused.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2154373368
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2154347417
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2154395621
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2154350585
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2154388484

From ayang at openjdk.org  Wed Jun 18 14:11:05 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 18 Jun 2025 14:11:05 GMT
Subject: RFR: 8359924: Deprecate and obsolete ParallelRefProcEnabled
Message-ID: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>

Deprecating `ParallelRefProcEnabled`, which is used only by Parallel and G1, and both have it enabled by default via:


  if (FLAG_IS_DEFAULT(ParallelRefProcEnabled) && ParallelGCThreads > 1) {
    FLAG_SET_DEFAULT(ParallelRefProcEnabled, true);
  }


Disabling it offers little benefit and its presence incurs some implementation complexity in the reference-processor.

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

Commit messages:
 - deprecate-flag

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

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

From tschatzl at openjdk.org  Wed Jun 18 14:49:32 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 18 Jun 2025 14:49:32 GMT
Subject: RFR: 8359924: Deprecate and obsolete ParallelRefProcEnabled
In-Reply-To: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
References: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
Message-ID: <R7qZ9SSAwhix_BsnXJGarUpPyNSNXnd8oJWs-BJAy1E=.9c75fa3f-96f9-411b-857a-62560d28aa07@github.com>

On Wed, 18 Jun 2025 14:04:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `ParallelRefProcEnabled`, which is used only by Parallel and G1, and both have it enabled by default via:
> 
> 
>   if (FLAG_IS_DEFAULT(ParallelRefProcEnabled) && ParallelGCThreads > 1) {
>     FLAG_SET_DEFAULT(ParallelRefProcEnabled, true);
>   }
> 
> 
> Disabling it offers little benefit and its presence incurs some implementation complexity in the reference-processor.

I'm wondering whether we should make `ParallelRefProcBalancingEnabled` diagnostic at the same time? (Separately).

Same with `ReferencesPerThread`, again separately, but that does not need a CSR.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25875#pullrequestreview-2939558285

From kdnilsen at openjdk.org  Wed Jun 18 16:32:08 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 18 Jun 2025 16:32:08 GMT
Subject: RFR: 8359947: GenShen: use smaller TLABs by default
Message-ID: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>

We have found with certain workloads that the initial and maximum tlab sizes result in very high latencies for the first few invocations of particular methods for certain threads.  The root cause is that TLABs are too large.  This is causing allocatable memory to be depleted too quickly.  When large numbers of threads are trying to startup at the same time, some of the threads end up with no TLABs or very small TLABs and their efforts run hundreds of times slower than the threads that were able to grab very large TLABs.

This PR reduces the maximum TLAB size and adjusts the initial TLAB size in order to reduce the impact of this problem.

This PR also changes the value of TLABAllocationWeight from 90 to 35 when we are running in generational mode.  35 is the default value used for G1 GC, which is also generational.  The default value of 90 was established years ago for non-generational Shenandoah because it tends to have less frequent GC cycles than generational collectors.

We have exercised this PR with three different workloads, which we identify as small, medium, and huge.  We have also exercised in two different configurations: with and without 30s warmup before latency measurements are taken.  Finally, we have applied this PR to both tip and to a development branch identified as adaptive-evac-with-surge.

The initial motivation for this PR was identified during testing of the adaptive-evac-with-surge branch.  That branch runs more aggressive GCs (larger evacuation workloads, with delayed (slightly more risky) triggers.  The objectives of this branch are to make GCs more efficient and to reduce CPU consumption.

We report 6 results for each experiment.  We sort these according to P100 latencies, and average results from the bottom four (best performing) samples, tossing out the two high outliers from the averages.  Workload results are subject to noise from elastic computing and operating system interference.

The benefits of this PR are most notable with the p99.999 and p100 small configuration of adaptive-evac-with-surge and the huge configuration of tip: 

![image](https://github.com/user-attachments/assets/def49a3c-4142-48f7-a946-33527e6985d0)

![image](https://github.com/user-attachments/assets/b0df27b3-f7b0-4fd2-82c3-ac84b0ad380e)

![image](https://github.com/user-attachments/assets/471c1292-96dc-46c1-9bcc-b851be07867d)

Note also the degradation in p50 and other lower percentile latencies.  The effect of this PR is to require each mutator thread to make more frequent allocation of smaller TLABs.  This results in higher contention for Shenandoah's global heap lock.  A separate development effort is refactoring the slow allocation path to use a single CAS for the large majority of TLAB allocations rather than the current mechanism, which requires each TLAB allocation to contend for exclusive access to the global heap lock, then hold the global heap lock during the search for memory to be allocated.  We expect this other mechanism will improve all latencies, and should reduce or eliminate the performance regressions introduced at certain percentiles by this PR.

For full context, other performance comparisons are also provided here.  In the following reports, it is usually the case that the affect of this PR is to reduce the total number of GCs and to reduce the CPU utilization.  Depending on the experiment, low percentile or high percentile response times improve.  We attribute these differences to contention for global heap lock.  We observe also that sometimes warming up an experiment for 30 seconds before beginning to measure latency has a similar effect to improving the initial TLAB size,  as the pre-existing shared heuristics for adaptive TLAB sizing seem to converge fairly quickly on improved behavior, at least for this workload which is fairly consistent.  A more variable workload may struggle more to find the optimal TLAB size.  For such workloads, having smaller default TLAB sizes seems to reduce the likelihood of occasional serious performance degradation.

![image](https://github.com/user-attachments/assets/33205ba0-2ebb-4cfa-96e9-8fecd52d07ab)

![image](https://github.com/user-attachments/assets/1bf49dfc-f673-4371-940f-af76496385fe)

![image](https://github.com/user-attachments/assets/a960d02b-87fe-42bd-9b6d-0232d80d1804)

While both versions of code are clearly overwhelmed for this Medium workload, it is interesting to observe that the PR produces two results that are much better than all six of the control runs.  Better performance and more meaningful comparisons are provided by the adaptive-old-evac-with-surge experiments, shown below.

![image](https://github.com/user-attachments/assets/da83f673-93f5-4712-becf-49c00f5ffe8c)

![image](https://github.com/user-attachments/assets/9f37dd0b-2fbf-4cc9-a1e5-e1b694f125ad)

![image](https://github.com/user-attachments/assets/858b556c-9a44-426e-927f-f6a8d2f249b0)

![image](https://github.com/user-attachments/assets/3e17f4c5-0c5d-4b47-b2ad-6d7504394e31)

![image](https://github.com/user-attachments/assets/2fc79194-244b-4e4d-8547-5fcd02811a69)

The small workload is represented by the following execution script.  Note that we override the default region size in order to avoid out-of-memory-during-evacuation failures that were occurring in the default configuration due to a large number of objects of approximate size 781 KB.

            ~/github/jdk.adjust-initial-tlab-size/build/linux-x86_64-server-release/images/jdk/bin/java \
                -XX:ActiveProcessorCount=2 \
                -XX:+UnlockExperimentalVMOptions \
                -XX:-ShenandoahPacing \
                -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xms4g -Xmx4g \
                -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \
                -XX:ShenandoahFullGCThreshold=1024 \
                -XX:ShenandoahMinRegionSize=4M \
                -Xlog:"gc*=info,ergo" \
                -Xlog:safepoint=trace -Xlog:safepoint=debug -Xlog:safepoint=info \
                -XX:+UnlockDiagnosticVMOptions \
                -jar ~/github/heapothesys.fix-two-bugs/Extremem/src/main/java/extremem.jar \
                -dDictionarySize=3000000 \
                -dNumCustomers=30000 \
                -dNumProducts=30000 \
                -dCustomerThreads=500 \
                -dCustomerPeriod=5s \
                -dCustomerThinkTime=1s \
                -dKeywordSearchCount=1 \
                -dSelectionCriteriaCount=3 \
                -dProductReviewLength=12 \
                -dServerThreads=5 \
                -dServerPeriod=10s \
                -dProductNameLength=10 \
                -dBrowsingHistoryQueueCount=5 \
                -dSalesTransactionQueueCount=5 \
                -dProductDescriptionLength=40 \
                -dProductReplacementPeriod=60s \
                -dProductReplacementCount=25 \
                -dCustomerReplacementPeriod=60s \
                -dCustomerReplacementCount=1500 \
                -dBrowsingExpiration=1m \
                -dPhasedUpdates=true \
                -dPhasedUpdateInterval=180s \
                -dSimulationDuration=25m \
                -dResponseTimeMeasurements=100000 \
                >$t.genshen.MaxRSWby8-TLABisRSBby128.small.overrides.out 2>$t.genshen.MaxRSWby8-TLABisRSBby128.small.overrides.err &
            job_pid=$!
            sleep 1500
            cpu_percent=$(ps -o cputime -o etime -p $job_pid)
            rss_kb=$(ps -o rss= -p $job_pid)
            rss_mb=$((rss_kb / 1024))
            wait $job_pid
            echo "RSS: $rss_mb MB" >>$t.genshen.MaxRSWby32-TLABisRSBby256.small.overrides.out 2>>$t.genshen.MaxRSWby32-TLABisRSBby256.small.overrides.err
            echo "$cpu_percent" >>$t.genshen.MaxRSWby32-TLABisRSBby256.small.overrides.out
            gzip $t.genshen.MaxRSWby32-TLABisRSBby256.small.overrides.out $t.genshen.MaxRSWby32-TLABisRSBby256.small.overrides.err

The medium workload is represented by this execution script:

            ~/github/jdk.adaptive-evac-with-surge/build/linux-x86_64-server-release/images/jdk/bin/java \
                -XX:+UnlockExperimentalVMOptions \
                -XX:-ShenandoahPacing \
                -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xms31g -Xmx31g \
                -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \
                -XX:ShenandoahFullGCThreshold=1024 \
                -XX:ShenandoahGuaranteedOldGCInterval=0 \
                -XX:ShenandoahGuaranteedYoungGCInterval=0 \
                -Xlog:"gc*=info,ergo" \
                -Xlog:safepoint=trace -Xlog:safepoint=debug -Xlog:safepoint=info \
                -XX:+UnlockDiagnosticVMOptions \
                -jar ~/github/heapothesys/Extremem/src/main/java/extremem.jar \
                -dDictionarySize=3000000 \
                -dNumCustomers=3600000 \
                -dNumProducts=320000 \
                -dCustomerThreads=500 \
                -dAllowAnyMatch=false \
                -dCustomerPeriod=5s \
                -dCustomerThinkTime=1s \
                -dKeywordSearchCount=2 \
                -dSelectionCriteriaCount=2 \
                -dProductReviewLength=12 \
                -dServerThreads=5 \
                -dServerPeriod=10s \
                -dProductNameLength=10 \
                -dBrowsingHistoryQueueCount=5 \
                -dSalesTransactionQueueCount=5 \
                -dProductDescriptionLength=512 \
                -dProductReplacementPeriod=60s \
                -dProductReplacementCount=25 \
                -dCustomerReplacementPeriod=60s \
                -dCustomerReplacementCount=1500 \
                -dBrowsingExpiration=1m \
                -dPhasedUpdates=true \
                -dPhasedUpdateInterval=180s \
                -dSimulationDuration=25m \
                -dResponseTimeMeasurements=100000 \
                >$t.retry.genshen.medium.adaptive-evac-with-surge.control.out 2>$t.retry.genshen.medium.adaptive-evac-with-surge.control.err &
            job_pid=$!
            sleep 1500
            cpu_percent=$(ps -o cputime -o etime -p $job_pid)
            rss_kb=$(ps -o rss= -p $job_pid)
            rss_mb=$((rss_kb / 1024))
            wait $job_pid
            echo "RSS: $rss_mb MB" >>$t.retry.genshen.medium.adaptive-evac-with-surge.control.out
            echo "$cpu_percent" >>$t.retry.genshen.medium.adaptive-evac-with-surge.control.out
            gzip $t.retry.genshen.medium.adaptive-evac-with-surge.control.out $t.retry.genshen.medium.adaptive-evac-with-surge.control.err

An additional parameter was added to the adaptive-evac-with-surge configurations, to make the adaptive old GC trigger slightly more sensitive:

                -XX:ShenandoahMinOldGenGrowthHeapPercent=2 \


The huge workload is represented by this execution script:

            ~/github/jdk.adjust-initial-tlab-size/build/linux-x86_64-server-release/images/jdk/bin/java \
                -XX:ActiveProcessorCount=16 \
                -XX:+UnlockExperimentalVMOptions \
                -XX:-ShenandoahPacing \
                -XX:+AlwaysPreTouch -XX:+DisableExplicitGC -Xms512g -Xmx512g \
                -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational \
                -XX:ShenandoahFullGCThreshold=1024 \
                -XX:ShenandoahGuaranteedGCInterval=0 \
                -XX:ShenandoahGuaranteedOldGCInterval=0 \
                -XX:ShenandoahGuaranteedYoungGCInterval=0 \
                -Xlog:"gc*=info,ergo" \
                -Xlog:safepoint=trace -Xlog:safepoint=debug -Xlog:safepoint=info \
                -XX:+UnlockDiagnosticVMOptions \
                -jar ~/github/heapothesys/Extremem/src/main/java/extremem.jar \
                -dDictionarySize=3000000 \
                -dNumCustomers=210000000 \
                -dNumProducts=18000000 \
                -dCustomerThreads=2000 \
                -dCustomerPeriod=2000ms \
                -dCustomerThinkTime=300ms \
                -dKeywordSearchCount=2 \
                -dAllowAnyMatch=false \
                -dSelectionCriteriaCount=3 \
                -dProductReviewLength=96 \
                -dBuyThreshold=0.5 \
                -dSaveForLaterThreshold=0.15 \
                -dBrowsingExpiration=5m \
                -dServerThreads=20 \
                -dServerPeriod=10s \
                -dProductNameLength=6 \
                -dProductDescriptionLength=70 \
                -dBrowsingHistoryQueueCount=1 \
                -dSalesTransactionQueueCount=1 \
                -dProductReplacementPeriod=60s \
                -dProductReplacementCount=25 \
                -dCustomerReplacementPeriod=60s \
                -dCustomerReplacementCount=150 \
                -dBrowsingExpiration=1m \
                -dSimulationDuration=25m \
                -dResponseTimeMeasurements=100000 \
                -dPhasedUpdates=true \
                -dPhasedUpdateInterval=180s \
                >$t.genshen.huge.MaxTLABisRSWby32-TLABisRSBisRSBby256.out 2>$t.genshen.huge.MaxTLABisRSWby32-TLABisRSBisRSBby256.err &
            job_pid=$!
            sleep 3000
            cpu_percent=$(ps -o cputime -o etime -p $job_pid)
            rss_kb=$(ps -o rss= -p $job_pid)
            rss_mb=$((rss_kb / 1024))
            wait $job_pid
            echo "RSS: $rss_kb KB" >>$t.genshen.huge.MaxTLABisRSWby32-TLABisRSBisRSBby256.out
            echo "RSS: $rss_mb MB" >>$t.genshen.huge.MaxTLABisRSWby32-TLABisRSBisRSBby256.out
            echo "$cpu_percent" >>$t.genshen.huge.MaxTLABisRSWby32-TLABisRSBisRSBby256.out
            gzip $t.genshen.huge.MaxTLABisRSWby32-TLABisRSBisRSBby256.out $t.genshen.huge.MaxTLABisRSWby32-TLABisRSBisRSBby256.err

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

Commit messages:
 - Fix white space
 - Shrink default TLABSize in half
 - MaxRSWby32-TLABisRSBby128
 - Tidy up for review
 - Merge branch 'adjust-initial-tlab-size' of https://github.com/kdnilsen/jdk into adjust-initial-tlab-size
 - MaxTLABisRSWby1 TLABSisRSBby128 TLABAllocationWeight=35
 - Add constraints for very large heap sizes with MaxTLABisRSWby8 TLABisRSBby128
 - MaxTLABisRSWby1 TLABSisDefault TLABAllocationWeight=90
 - MaxTLABisRSWby1-TLABisDefault
 - MaxTLABisRSWby2 TLABisDefault
 - ... and 40 more: https://git.openjdk.org/jdk/compare/92730945...e8b35937

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

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

From kdnilsen at openjdk.org  Wed Jun 18 16:32:08 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 18 Jun 2025 16:32:08 GMT
Subject: RFR: 8359947: GenShen: use smaller TLABs by default
In-Reply-To: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
References: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
Message-ID: <raXynItTdzpSVZ2-onLf5xLqH5X6Rt7dcLCKFhW7vaM=.ee0c3839-eb31-4fd4-928f-9573e050b5b3@github.com>

On Fri, 23 May 2025 20:13:21 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We have found with certain workloads that the initial and maximum tlab sizes result in very high latencies for the first few invocations of particular methods for certain threads.  The root cause is that TLABs are too large.  This is causing allocatable memory to be depleted too quickly.  When large numbers of threads are trying to startup at the same time, some of the threads end up with no TLABs or very small TLABs and their efforts run hundreds of times slower than the threads that were able to grab very large TLABs.
> 
> This PR reduces the maximum TLAB size and adjusts the initial TLAB size in order to reduce the impact of this problem.
> 
> This PR also changes the value of TLABAllocationWeight from 90 to 35 when we are running in generational mode.  35 is the default value used for G1 GC, which is also generational.  The default value of 90 was established years ago for non-generational Shenandoah because it tends to have less frequent GC cycles than generational collectors.
> 
> We have exercised this PR with three different workloads, which we identify as small, medium, and huge.  We have also exercised in two different configurations: with and without 30s warmup before latency measurements are taken.  Finally, we have applied this PR to both tip and to a development branch identified as adaptive-evac-with-surge.
> 
> The initial motivation for this PR was identified during testing of the adaptive-evac-with-surge branch.  That branch runs more aggressive GCs (larger evacuation workloads, with delayed (slightly more risky) triggers.  The objectives of this branch are to make GCs more efficient and to reduce CPU consumption.
> 
> We report 6 results for each experiment.  We sort these according to P100 latencies, and average results from the bottom four (best performing) samples, tossing out the two high outliers from the averages.  Workload results are subject to noise from elastic computing and operating system interference.
> 
> The benefits of this PR are most notable with the p99.999 and p100 small configuration of adaptive-evac-with-surge and the huge configuration of tip: 
> 
> ![image](https://github.com/user-attachments/assets/def49a3c-4142-48f7-a946-33527e6985d0)
> 
> ![image](https://github.com/user-attachments/assets/b0df27b3-f7b0-4fd2-82c3-ac84b0ad380e)
> 
> ![image](https://github.com/user-attachments/assets/471c1292-96dc-46c1-9bcc-b851be07867d)
> 
> Note also the degradation in p50 and other lower percentile latencies.  The effect of this PR is to require each mutator threa...

Leaving this in draft while I prepare details for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25423#issuecomment-2905742286

From kdnilsen at openjdk.org  Wed Jun 18 16:38:45 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 18 Jun 2025 16:38:45 GMT
Subject: RFR: 8359947: GenShen: use smaller TLABs by default [v2]
In-Reply-To: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
References: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
Message-ID: <OJQ02dgxpoTaEpKihIvDOjqMmx5L3Z7NYQjeWS7eLoU=.4d420240-25b3-4cfb-8876-9f3d2b4a2ac6@github.com>

> We have found with certain workloads that the initial and maximum tlab sizes result in very high latencies for the first few invocations of particular methods for certain threads.  The root cause is that TLABs are too large.  This is causing allocatable memory to be depleted too quickly.  When large numbers of threads are trying to startup at the same time, some of the threads end up with no TLABs or very small TLABs and their efforts run hundreds of times slower than the threads that were able to grab very large TLABs.
> 
> This PR reduces the maximum TLAB size and adjusts the initial TLAB size in order to reduce the impact of this problem.
> 
> This PR also changes the value of TLABAllocationWeight from 90 to 35 when we are running in generational mode.  35 is the default value used for G1 GC, which is also generational.  The default value of 90 was established years ago for non-generational Shenandoah because it tends to have less frequent GC cycles than generational collectors.
> 
> We have exercised this PR with three different workloads, which we identify as small, medium, and huge.  We have also exercised in two different configurations: with and without 30s warmup before latency measurements are taken.  Finally, we have applied this PR to both tip and to a development branch identified as adaptive-evac-with-surge.
> 
> The initial motivation for this PR was identified during testing of the adaptive-evac-with-surge branch.  That branch runs more aggressive GCs (larger evacuation workloads, with delayed (slightly more risky) triggers.  The objectives of this branch are to make GCs more efficient and to reduce CPU consumption.
> 
> We report 6 results for each experiment.  We sort these according to P100 latencies, and average results from the bottom four (best performing) samples, tossing out the two high outliers from the averages.  Workload results are subject to noise from elastic computing and operating system interference.
> 
> The benefits of this PR are most notable with the p99.999 and p100 small configuration of adaptive-evac-with-surge and the huge configuration of tip: 
> 
> ![image](https://github.com/user-attachments/assets/def49a3c-4142-48f7-a946-33527e6985d0)
> 
> ![image](https://github.com/user-attachments/assets/b0df27b3-f7b0-4fd2-82c3-ac84b0ad380e)
> 
> ![image](https://github.com/user-attachments/assets/471c1292-96dc-46c1-9bcc-b851be07867d)
> 
> Note also the degradation in p50 and other lower percentile latencies.  The effect of this PR is to require each mutator threa...

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

  Remove debug instrumentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25423/files
  - new: https://git.openjdk.org/jdk/pull/25423/files/e8b35937..456ee6e3

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

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

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

From phh at openjdk.org  Wed Jun 18 16:42:32 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 18 Jun 2025 16:42:32 GMT
Subject: RFR: 8359947: GenShen: use smaller TLABs by default [v2]
In-Reply-To: <OJQ02dgxpoTaEpKihIvDOjqMmx5L3Z7NYQjeWS7eLoU=.4d420240-25b3-4cfb-8876-9f3d2b4a2ac6@github.com>
References: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
 <OJQ02dgxpoTaEpKihIvDOjqMmx5L3Z7NYQjeWS7eLoU=.4d420240-25b3-4cfb-8876-9f3d2b4a2ac6@github.com>
Message-ID: <aEuXKbknfljqyUB8caxYl90rjjc-peOcXQEa_OrjWqw=.06e0b963-8b53-4462-8fcc-d4edd32457e7@github.com>

On Wed, 18 Jun 2025 16:38:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We have found with certain workloads that the initial and maximum tlab sizes result in very high latencies for the first few invocations of particular methods for certain threads.  The root cause is that TLABs are too large.  This is causing allocatable memory to be depleted too quickly.  When large numbers of threads are trying to startup at the same time, some of the threads end up with no TLABs or very small TLABs and their efforts run hundreds of times slower than the threads that were able to grab very large TLABs.
>> 
>> This PR reduces the maximum TLAB size and adjusts the initial TLAB size in order to reduce the impact of this problem.
>> 
>> This PR also changes the value of TLABAllocationWeight from 90 to 35 when we are running in generational mode.  35 is the default value used for G1 GC, which is also generational.  The default value of 90 was established years ago for non-generational Shenandoah because it tends to have less frequent GC cycles than generational collectors.
>> 
>> We have exercised this PR with three different workloads, which we identify as small, medium, and huge.  We have also exercised in two different configurations: with and without 30s warmup before latency measurements are taken.  Finally, we have applied this PR to both tip and to a development branch identified as adaptive-evac-with-surge.
>> 
>> The initial motivation for this PR was identified during testing of the adaptive-evac-with-surge branch.  That branch runs more aggressive GCs (larger evacuation workloads, with delayed (slightly more risky) triggers.  The objectives of this branch are to make GCs more efficient and to reduce CPU consumption.
>> 
>> We report 6 results for each experiment.  We sort these according to P100 latencies, and average results from the bottom four (best performing) samples, tossing out the two high outliers from the averages.  Workload results are subject to noise from elastic computing and operating system interference.
>> 
>> The benefits of this PR are most notable with the p99.999 and p100 small configuration of adaptive-evac-with-surge and the huge configuration of tip: 
>> 
>> ![image](https://github.com/user-attachments/assets/def49a3c-4142-48f7-a946-33527e6985d0)
>> 
>> ![image](https://github.com/user-attachments/assets/b0df27b3-f7b0-4fd2-82c3-ac84b0ad380e)
>> 
>> ![image](https://github.com/user-attachments/assets/471c1292-96dc-46c1-9bcc-b851be07867d)
>> 
>> Note also the degradation in p50 and other lower percentile latencies.  The effect o...
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug instrumentation

What's the rationale for using a fraction of the region size as a possible maximum TLAB size? Region size seems unrelated to thread object allocation demand.

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

PR Review: https://git.openjdk.org/jdk/pull/25423#pullrequestreview-2939988648

From kdnilsen at openjdk.org  Wed Jun 18 16:52:33 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 18 Jun 2025 16:52:33 GMT
Subject: RFR: 8359947: GenShen: use smaller TLABs by default [v2]
In-Reply-To: <aEuXKbknfljqyUB8caxYl90rjjc-peOcXQEa_OrjWqw=.06e0b963-8b53-4462-8fcc-d4edd32457e7@github.com>
References: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
 <OJQ02dgxpoTaEpKihIvDOjqMmx5L3Z7NYQjeWS7eLoU=.4d420240-25b3-4cfb-8876-9f3d2b4a2ac6@github.com>
 <aEuXKbknfljqyUB8caxYl90rjjc-peOcXQEa_OrjWqw=.06e0b963-8b53-4462-8fcc-d4edd32457e7@github.com>
Message-ID: <l67qHg9KGuXMP9m-RRrXGvBslzhQheQSMxX0WNN7fo4=.45061258-6905-42b4-89b9-46de3b40de2e@github.com>

On Wed, 18 Jun 2025 16:39:42 GMT, Paul Hohensee <phh at openjdk.org> wrote:

> What's the rationale for using a fraction of the region size as a possible maximum TLAB size? Region size seems unrelated to thread object allocation demand.

Region size is generally proportional to total heap size.  If we have larger heap sizes, we have more abundant memory, and can generally afford to be "slightly" more generous in apportionment of memory between threads.  But we do this within limits.

The initial TLAB size is never made smaller than 32KB and the max TLAB size is never made larger than 256KB.

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

PR Comment: https://git.openjdk.org/jdk/pull/25423#issuecomment-2985016769

From phh at openjdk.org  Wed Jun 18 17:58:33 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 18 Jun 2025 17:58:33 GMT
Subject: RFR: 8359947: GenShen: use smaller TLABs by default [v2]
In-Reply-To: <OJQ02dgxpoTaEpKihIvDOjqMmx5L3Z7NYQjeWS7eLoU=.4d420240-25b3-4cfb-8876-9f3d2b4a2ac6@github.com>
References: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
 <OJQ02dgxpoTaEpKihIvDOjqMmx5L3Z7NYQjeWS7eLoU=.4d420240-25b3-4cfb-8876-9f3d2b4a2ac6@github.com>
Message-ID: <OUB0wWrCxSkmEbFGQCMy_zNEp6TT4gi75dmzqehwh3g=.812f80b0-270f-4961-ab6e-7739f2818ccc@github.com>

On Wed, 18 Jun 2025 16:38:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We have found with certain workloads that the initial and maximum tlab sizes result in very high latencies for the first few invocations of particular methods for certain threads.  The root cause is that TLABs are too large.  This is causing allocatable memory to be depleted too quickly.  When large numbers of threads are trying to startup at the same time, some of the threads end up with no TLABs or very small TLABs and their efforts run hundreds of times slower than the threads that were able to grab very large TLABs.
>> 
>> This PR reduces the maximum TLAB size and adjusts the initial TLAB size in order to reduce the impact of this problem.
>> 
>> This PR also changes the value of TLABAllocationWeight from 90 to 35 when we are running in generational mode.  35 is the default value used for G1 GC, which is also generational.  The default value of 90 was established years ago for non-generational Shenandoah because it tends to have less frequent GC cycles than generational collectors.
>> 
>> We have exercised this PR with three different workloads, which we identify as small, medium, and huge.  We have also exercised in two different configurations: with and without 30s warmup before latency measurements are taken.  Finally, we have applied this PR to both tip and to a development branch identified as adaptive-evac-with-surge.
>> 
>> The initial motivation for this PR was identified during testing of the adaptive-evac-with-surge branch.  That branch runs more aggressive GCs (larger evacuation workloads, with delayed (slightly more risky) triggers).  The objectives of this branch are to make GCs more efficient and to reduce CPU consumption.
>> 
>> We report 6 results for each experiment.  We sort these according to P100 latencies, and average results from the bottom four (best performing) samples, tossing out the two high outliers from the averages.  Workload results are subject to noise from elastic computing and operating system interference.
>> 
>> The benefits of this PR are most notable with the p99.999 and p100 small configuration of adaptive-evac-with-surge and the huge configuration of tip: 
>> 
>> ![image](https://github.com/user-attachments/assets/def49a3c-4142-48f7-a946-33527e6985d0)
>> 
>> ![image](https://github.com/user-attachments/assets/b0df27b3-f7b0-4fd2-82c3-ac84b0ad380e)
>> 
>> ![image](https://github.com/user-attachments/assets/471c1292-96dc-46c1-9bcc-b851be07867d)
>> 
>> Note also the degradation in p50 and other lower percentile latencies.  The effect ...
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug instrumentation

Ok, makes sense.

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

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25423#pullrequestreview-2940191050

From xpeng at openjdk.org  Wed Jun 18 18:46:40 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 18 Jun 2025 18:46:40 GMT
Subject: RFR: 8359947: GenShen: use smaller TLABs by default [v2]
In-Reply-To: <OJQ02dgxpoTaEpKihIvDOjqMmx5L3Z7NYQjeWS7eLoU=.4d420240-25b3-4cfb-8876-9f3d2b4a2ac6@github.com>
References: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
 <OJQ02dgxpoTaEpKihIvDOjqMmx5L3Z7NYQjeWS7eLoU=.4d420240-25b3-4cfb-8876-9f3d2b4a2ac6@github.com>
Message-ID: <KNg4sjnPlAVe7nKD6Uh91JrMQPSLblM7o_hBT-5FHew=.fabc848a-469c-4650-931d-378198695098@github.com>

On Wed, 18 Jun 2025 16:38:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We have found with certain workloads that the initial and maximum tlab sizes result in very high latencies for the first few invocations of particular methods for certain threads.  The root cause is that TLABs are too large.  This is causing allocatable memory to be depleted too quickly.  When large numbers of threads are trying to startup at the same time, some of the threads end up with no TLABs or very small TLABs and their efforts run hundreds of times slower than the threads that were able to grab very large TLABs.
>> 
>> This PR reduces the maximum TLAB size and adjusts the initial TLAB size in order to reduce the impact of this problem.
>> 
>> This PR also changes the value of TLABAllocationWeight from 90 to 35 when we are running in generational mode.  35 is the default value used for G1 GC, which is also generational.  The default value of 90 was established years ago for non-generational Shenandoah because it tends to have less frequent GC cycles than generational collectors.
>> 
>> We have exercised this PR with three different workloads, which we identify as small, medium, and huge.  We have also exercised in two different configurations: with and without 30s warmup before latency measurements are taken.  Finally, we have applied this PR to both tip and to a development branch identified as adaptive-evac-with-surge.
>> 
>> The initial motivation for this PR was identified during testing of the adaptive-evac-with-surge branch.  That branch runs more aggressive GCs (larger evacuation workloads, with delayed (slightly more risky) triggers).  The objectives of this branch are to make GCs more efficient and to reduce CPU consumption.
>> 
>> We report 6 results for each experiment.  We sort these according to P100 latencies, and average results from the bottom four (best performing) samples, tossing out the two high outliers from the averages.  Workload results are subject to noise from elastic computing and operating system interference.
>> 
>> The benefits of this PR are most notable with the p99.999 and p100 small configuration of adaptive-evac-with-surge and the huge configuration of tip: 
>> 
>> ![image](https://github.com/user-attachments/assets/def49a3c-4142-48f7-a946-33527e6985d0)
>> 
>> ![image](https://github.com/user-attachments/assets/b0df27b3-f7b0-4fd2-82c3-ac84b0ad380e)
>> 
>> ![image](https://github.com/user-attachments/assets/471c1292-96dc-46c1-9bcc-b851be07867d)
>> 
>> Note also the degradation in p50 and other lower percentile latencies.  The effect ...
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug instrumentation

Looks good to me! 
Smaller tlab will result more contention on heap lock in the slow path to allocate tlab, the task I am working on to use CAS may help to mitigate.

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

Marked as reviewed by xpeng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25423#pullrequestreview-2940310161

From mdoerr at openjdk.org  Wed Jun 18 19:59:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Jun 2025 19:59:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
Message-ID: <7dqmRsrYN1O1zVQSYvFbVpmjSSABHnw7dL8QXSkrOtE=.eceed621-7482-436e-a999-73b6d2611616@github.com>

On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd try at arm fix

Unfortunately, there's a merge conflict, now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2985526434

From mdoerr at openjdk.org  Wed Jun 18 19:59:30 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Jun 2025 19:59:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
 <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
Message-ID: <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>

On Wed, 18 Jun 2025 11:34:02 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> If I understand your concern correctly, there is no race.  The only caller of BarrierSetNMethod::make_not_entrant() is nmethod::make_not_entrant(), and it is done inside a NMethodState_lock critical section.  After a call to nmethod::make_not_entrant(), the nmethod entry barrier is armed and stays that way.
>> And by design, a disarm only disarms at the inner nmethod_entry_barrier level, not the outer nmethod_stub_entry_barrier level.
>
> My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code.
> Does that make sense?

Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2155390909

From eosterlund at openjdk.org  Wed Jun 18 20:28:29 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 18 Jun 2025 20:28:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
 <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
 <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>
Message-ID: <S_WVqyvsvxDSez9c0syZRE2cr8kQ1yeSOs9w4zBEWAY=.23eec805-97e0-4982-8417-6f0114646fbb@github.com>

On Wed, 18 Jun 2025 19:56:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> My concern is that while thread 1 calls nmethod::make_not_entrant(), thread 2 racingly performs nmethod entry barrier; it makes the is_not_entrant check before it gets updated, but then it gets updated as the per nmethod lock is taken. The GC code "disarms" the GC barrier but in doing so finds that "oh this should be not entrant", but that's sort of not reflected as thread 2 will then proceed with entering the nmethod it just armed as not entrant in the nmethod entry barrier code.
>> Does that make sense?
>
> Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier.

Well, yeah sort of. And hence the comment that it's probably fine in terms of correctness. They were also a bit more independent systems then though. Just thought that if we now take the step to merge compiler and GC entry trap mechanisms into the nmethod entry barrier, that we could seemingly also make it a bit less slippery here and establish some sort of invariant that if we while holding the lock protecting the entry barrier find that the nmethod entry barrier is not entrant, for whatever reason, we should not enter it. Would make it easier to understand the code I suspect. What do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2155434971

From kbarrett at openjdk.org  Wed Jun 18 21:24:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Jun 2025 21:24:28 GMT
Subject: RFR: 8359924: Deprecate and obsolete ParallelRefProcEnabled
In-Reply-To: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
References: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
Message-ID: <uBKA2bLXervjYRku2gCWdBI4DahkemZz2esyLbnfsmA=.3642cdc6-bc7d-4a64-8f90-9dc0c88263bf@github.com>

On Wed, 18 Jun 2025 14:04:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `ParallelRefProcEnabled`, which is used only by Parallel and G1, and both have it enabled by default via:
> 
> 
>   if (FLAG_IS_DEFAULT(ParallelRefProcEnabled) && ParallelGCThreads > 1) {
>     FLAG_SET_DEFAULT(ParallelRefProcEnabled, true);
>   }
> 
> 
> Disabling it offers little benefit and its presence incurs some implementation complexity in the reference-processor.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25875#pullrequestreview-2940716200

From kbarrett at openjdk.org  Wed Jun 18 21:29:27 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 18 Jun 2025 21:29:27 GMT
Subject: RFR: 8359924: Deprecate and obsolete ParallelRefProcEnabled
In-Reply-To: <R7qZ9SSAwhix_BsnXJGarUpPyNSNXnd8oJWs-BJAy1E=.9c75fa3f-96f9-411b-857a-62560d28aa07@github.com>
References: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
 <R7qZ9SSAwhix_BsnXJGarUpPyNSNXnd8oJWs-BJAy1E=.9c75fa3f-96f9-411b-857a-62560d28aa07@github.com>
Message-ID: <DuEuTPObPfC8YE9gxFMA896tdo5VgWeiaD-Hwg-54fU=.d37466d4-a73e-411a-b5e2-15f9b40496a5@github.com>

On Wed, 18 Jun 2025 14:47:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> I'm wondering whether we should make `ParallelRefProcBalancingEnabled` diagnostic at the same time? (Separately).

I think it's too late for that. We can only deprecate a product option in the current release, we can't change it
to diagnostic (which is removing it from being available for normal usage). We could deprecate now with the
intent of going to diagnostic rather than removal, but I'd rather we just deprecate for removal, and remove
in the next release.

> Same with `ReferencesPerThread`, again separately, but that does not need a CSR.

We could remove ReferencesPerThread immediately, without first deprecating, since it's experimental.

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

PR Comment: https://git.openjdk.org/jdk/pull/25875#issuecomment-2985742153

From sangheki at openjdk.org  Wed Jun 18 21:39:28 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Wed, 18 Jun 2025 21:39:28 GMT
Subject: RFR: 8359825: Parallel: Simplify
 MutableNUMASpace::ensure_parsability
In-Reply-To: <8D8xoSoDjedCVLEYc9Vz1aVtYPCY8RCpZDBHvJEMzE0=.9140dbf3-4cf4-4564-b5b4-abff66e3433f@github.com>
References: <8D8xoSoDjedCVLEYc9Vz1aVtYPCY8RCpZDBHvJEMzE0=.9140dbf3-4cf4-4564-b5b4-abff66e3433f@github.com>
Message-ID: <s0FEpsJ_lV2-Mm28tnMjryt9Fs0FhdDTo6Dm4eVvs0w=.94935562-19b3-4165-9f16-656a2897254b@github.com>

On Tue, 17 Jun 2025 13:24:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple `fill_with_object` -> `fill_with_objects` API  change to push the implementation logic to the callee.

LGTM

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

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25852#pullrequestreview-2940752249

From dlong at openjdk.org  Thu Jun 19 00:22:30 2025
From: dlong at openjdk.org (Dean Long)
Date: Thu, 19 Jun 2025 00:22:30 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <S_WVqyvsvxDSez9c0syZRE2cr8kQ1yeSOs9w4zBEWAY=.23eec805-97e0-4982-8417-6f0114646fbb@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
 <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
 <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>
 <S_WVqyvsvxDSez9c0syZRE2cr8kQ1yeSOs9w4zBEWAY=.23eec805-97e0-4982-8417-6f0114646fbb@github.com>
Message-ID: <NDd13XSxcbkLkY1hPDt7hlRUAo_3zlHikMaBpAHy8po=.c399c3e1-df5e-4ea8-a667-68d12bac991a@github.com>

On Wed, 18 Jun 2025 20:25:44 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Doesn't the old code have the same limitation? If thread 1 patches the entry point after thread 2 has executed the first instruction, thread 2 will be inside the nmethod if GC has disarmed the nmethod entry barrier.
>
> Well, yeah sort of. And hence the comment that it's probably fine in terms of correctness. They were also a bit more independent systems then though. Just thought that if we now take the step to merge compiler and GC entry trap mechanisms into the nmethod entry barrier, that we could seemingly also make it a bit less slippery here and establish some sort of invariant that if we while holding the lock protecting the entry barrier find that the nmethod entry barrier is not entrant, for whatever reason, we should not enter it. Would make it easier to understand the code I suspect. What do you think?

I think making it less slippery in one place but still leaving other races gives a false sense of security and makes the code harder to understand.  Arming the barrier is not guaranteed to be visible until there is a safepoint.  Note that AArch64 and RISCV only call increment_patching_epoch() when the guard value is set to the disarmed value, so there is no invalidation of the CPU pipeline or instruction buffer (cross modification fence) when arming.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2155757120

From dholmes at openjdk.org  Thu Jun 19 06:34:32 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 19 Jun 2025 06:34:32 GMT
Subject: RFR: 8359924: Deprecate and obsolete ParallelRefProcEnabled
In-Reply-To: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
References: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
Message-ID: <lSM9wO5zHl-o3aekRyFtLPL9rsW_IQGYHOZHxYLc9dI=.83c34151-7929-4874-a12f-1516d2a39ced@github.com>

On Wed, 18 Jun 2025 14:04:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `ParallelRefProcEnabled`, which is used only by Parallel and G1, and both have it enabled by default via:
> 
> 
>   if (FLAG_IS_DEFAULT(ParallelRefProcEnabled) && ParallelGCThreads > 1) {
>     FLAG_SET_DEFAULT(ParallelRefProcEnabled, true);
>   }
> 
> 
> Disabling it offers little benefit and its presence incurs some implementation complexity in the reference-processor.

LGTM!

Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25875#pullrequestreview-2941745997

From iwalulya at openjdk.org  Thu Jun 19 12:26:15 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 19 Jun 2025 12:26:15 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v4]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Albert suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25832/files
  - new: https://git.openjdk.org/jdk/pull/25832/files/2d5b7cd1..df4f7ce5

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

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

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

From duke at openjdk.org  Thu Jun 19 13:18:38 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 19 Jun 2025 13:18:38 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation
Message-ID: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>

[JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.

Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.

Proposed changes in the shared class hierarchy:


//  VM_Operation
//    VM_Heap_Sync_Operation
//      VM_GC_Operation
//        VM_GC_Collect_Operation
//          VM_SerialGCCollect
//          VM_ParallelGCCollect
//          VM_CollectForAllocation
//            VM_SerialCollectForAllocation
//            VM_ParallelCollectForAllocation
//          VM_CollectForMetadataAllocation
//        VM_GC_Service_Operation
//          VM_GC_HeapInspection
//      VM_Verify
//      VM_PopulateDynamicDumpSharedSpace
//      VM_PopulateDumpSharedSpace


Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".

ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.

The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.

_Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot more overrides..._

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

Commit messages:
 - Add comment about is_gc_operation in base class
 - Align to ZGC styling
 - Reorganize GC VM operations and implement is_gc_operation

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

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

From shade at openjdk.org  Thu Jun 19 18:39:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 19 Jun 2025 18:39:29 GMT
Subject: RFR: 8359394: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <wSRFrJfHBRVvxn51Uckbi8fpOyX4AmTNMUw07r6HNls=.3d686422-fd26-4243-bf31-ee1713fa5e44@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove `GCCause::_no_cause_specified` (only referenced by Shenandoah) and add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string` and the `SA` analog.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25789#pullrequestreview-2943805126

From wkemper at openjdk.org  Thu Jun 19 18:43:33 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Jun 2025 18:43:33 GMT
Subject: Integrated: 8359394: GC cause cleanup
In-Reply-To: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
References: <qD6-lm4j1SOtcjH1auGnO7Eu5PlODBWykO1VK50IZAw=.e7316073-e22c-42fc-9536-f200fde971eb@github.com>
Message-ID: <tltsW_Y2YhEcfVzMCCvzzqxKhjtB9fLYBmbNf2eDvNk=.437cb104-0b1d-4050-b832-b1990708e81b@github.com>

On Thu, 12 Jun 2025 23:42:41 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Remove `GCCause::_no_cause_specified` (only referenced by Shenandoah) and add a case for `_shenandoah_humongous_allocation_failure` in `GCCause::to_string` and the `SA` analog.

This pull request has now been integrated.

Changeset: dec42beb
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dec42bebb836b2ea244dc19a5964dac828791135
Stats:     18 lines in 5 files changed: 5 ins; 6 del; 7 mod

8359394: GC cause cleanup

Reviewed-by: shade, ysr, stefank

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

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

From ayang at openjdk.org  Thu Jun 19 19:43:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 19 Jun 2025 19:43:28 GMT
Subject: RFR: 8359825: Parallel: Simplify
 MutableNUMASpace::ensure_parsability
In-Reply-To: <8D8xoSoDjedCVLEYc9Vz1aVtYPCY8RCpZDBHvJEMzE0=.9140dbf3-4cf4-4564-b5b4-abff66e3433f@github.com>
References: <8D8xoSoDjedCVLEYc9Vz1aVtYPCY8RCpZDBHvJEMzE0=.9140dbf3-4cf4-4564-b5b4-abff66e3433f@github.com>
Message-ID: <ClQGHU8w0aLKaqEiRzC1Lza44LEPmAPU3sQLTQqzpWs=.76b8a834-1ab9-439a-9b99-cb719e53c8ed@github.com>

On Tue, 17 Jun 2025 13:24:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple `fill_with_object` -> `fill_with_objects` API  change to push the implementation logic to the callee.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25852#issuecomment-2988779453

From ayang at openjdk.org  Thu Jun 19 19:46:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 19 Jun 2025 19:46:38 GMT
Subject: Integrated: 8359825: Parallel: Simplify
 MutableNUMASpace::ensure_parsability
In-Reply-To: <8D8xoSoDjedCVLEYc9Vz1aVtYPCY8RCpZDBHvJEMzE0=.9140dbf3-4cf4-4564-b5b4-abff66e3433f@github.com>
References: <8D8xoSoDjedCVLEYc9Vz1aVtYPCY8RCpZDBHvJEMzE0=.9140dbf3-4cf4-4564-b5b4-abff66e3433f@github.com>
Message-ID: <4sIKWaAP66Wxf4mOJbO1GV_UBD9ULx8LJXtEFmS2qFo=.b70fd7e8-f365-4ee7-ba25-e207911a3f96@github.com>

On Tue, 17 Jun 2025 13:24:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple `fill_with_object` -> `fill_with_objects` API  change to push the implementation logic to the callee.

This pull request has now been integrated.

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

8359825: Parallel: Simplify MutableNUMASpace::ensure_parsability

Reviewed-by: tschatzl, sangheki

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

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

From wkemper at openjdk.org  Thu Jun 19 20:27:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Jun 2025 20:27:23 GMT
Subject: RFR: 8357550: GenShen crashes during freeze:
 assert(!chunk->requires_barriers()) failed
Message-ID: <Ucznl2ab7HdNjJ4G0aho4mjN_MqfbsPyxNysd2g45uk=.35e6904b-a093-4bd5-ad77-ecae53ca9cf9@github.com>

Shenandoah captures a preliminary top-at-mark-start (TAMS) concurrently. Once concurrent marking has begun, any object beneath TAMS requires a barrier when accessed. The implementation of `ShenandoahHeap::requires_barrier` does not distinguish between _old_ and _young_ marking. This could lead to a race between freezing the stack and capturing TAMS:

1. Collector is marking old
2. Allocate stack chunk in young
3. Barrier is not needed, begin fast freeze path
4. Collector concurrently updates TAMS (young marking will start once init-mark safepoint is reached)
5. ShenandoahHeap now thinks the barrier is needed (because TAMS changed, and we are marking old)
6. Fast freeze asserts out

This fix has the generational mode check the appropriate generation and its marking state. It also enforces barriers for stackChunks in the old generation (for card marking).

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

Commit messages:
 - override requires_barriers for generational mode

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

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

From kdnilsen at openjdk.org  Thu Jun 19 20:57:37 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 19 Jun 2025 20:57:37 GMT
Subject: RFR: 8357550: GenShen crashes during freeze:
 assert(!chunk->requires_barriers()) failed
In-Reply-To: <Ucznl2ab7HdNjJ4G0aho4mjN_MqfbsPyxNysd2g45uk=.35e6904b-a093-4bd5-ad77-ecae53ca9cf9@github.com>
References: <Ucznl2ab7HdNjJ4G0aho4mjN_MqfbsPyxNysd2g45uk=.35e6904b-a093-4bd5-ad77-ecae53ca9cf9@github.com>
Message-ID: <nOfXFYM-qRXg1KRl8gZ7IqZ5ZNJ4q0yhZb9JFXSKKhs=.719f2d41-ee2a-40cc-9025-0be0535651ef@github.com>

On Thu, 19 Jun 2025 20:21:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah captures a preliminary top-at-mark-start (TAMS) concurrently. Once concurrent marking has begun, any object beneath TAMS requires a barrier when accessed. The implementation of `ShenandoahHeap::requires_barrier` does not distinguish between _old_ and _young_ marking. This could lead to a race between freezing the stack and capturing TAMS:
> 
> 1. Collector is marking old
> 2. Allocate stack chunk in young
> 3. Barrier is not needed, begin fast freeze path
> 4. Collector concurrently updates TAMS (young marking will start once init-mark safepoint is reached)
> 5. ShenandoahHeap now thinks the barrier is needed (because TAMS changed, and we are marking old)
> 6. Fast freeze asserts out
> 
> This fix has the generational mode check the appropriate generation and its marking state. It also enforces barriers for stackChunks in the old generation (for card marking).

Marked as reviewed by kdnilsen (Committer).

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

> 189:   }
> 190: 
> 191:   if (is_concurrent_young_mark_in_progress() && is_in_young(obj) && !marking_context()->allocated_after_mark_start(obj)) {

Just so I understand (and maybe this deserves a clarifying comment to help others understand):
  The barrier we are concerned about here is SATB.  If obj is above TAMS, there's no need to enforce a SATB barrier.  Any reference residing above TAMS which is overwritten will have been marked already, or is about to be marked.  Either the value is already "presumed marked" because it also resides above TAMS, or its value was assigned from a root (in which case root scanning marked it), or it was copied from a pre-existing object (in which case it will be marked by scanning of that pre-existing object or by SATB).

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

PR Review: https://git.openjdk.org/jdk/pull/25905#pullrequestreview-2944013440
PR Review Comment: https://git.openjdk.org/jdk/pull/25905#discussion_r2157651598

From wkemper at openjdk.org  Thu Jun 19 21:32:28 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Jun 2025 21:32:28 GMT
Subject: RFR: 8357550: GenShen crashes during freeze:
 assert(!chunk->requires_barriers()) failed
In-Reply-To: <nOfXFYM-qRXg1KRl8gZ7IqZ5ZNJ4q0yhZb9JFXSKKhs=.719f2d41-ee2a-40cc-9025-0be0535651ef@github.com>
References: <Ucznl2ab7HdNjJ4G0aho4mjN_MqfbsPyxNysd2g45uk=.35e6904b-a093-4bd5-ad77-ecae53ca9cf9@github.com>
 <nOfXFYM-qRXg1KRl8gZ7IqZ5ZNJ4q0yhZb9JFXSKKhs=.719f2d41-ee2a-40cc-9025-0be0535651ef@github.com>
Message-ID: <zl1SDyiDJGqxeI8MWLo-i88H7DBOLeKKp17jJpU-UeU=.000f6021-1733-499d-ae6f-23f3d35b9ae1@github.com>

On Thu, 19 Jun 2025 20:55:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Shenandoah captures a preliminary top-at-mark-start (TAMS) concurrently. Once concurrent marking has begun, any object beneath TAMS requires a barrier when accessed. The implementation of `ShenandoahHeap::requires_barrier` does not distinguish between _old_ and _young_ marking. This could lead to a race between freezing the stack and capturing TAMS:
>> 
>> 1. Collector is marking old
>> 2. Allocate stack chunk in young
>> 3. Barrier is not needed, begin fast freeze path
>> 4. Collector concurrently updates TAMS (young marking will start once init-mark safepoint is reached)
>> 5. ShenandoahHeap now thinks the barrier is needed (because TAMS changed, and we are marking old)
>> 6. Fast freeze asserts out
>> 
>> This fix has the generational mode check the appropriate generation and its marking state. It also enforces barriers for stackChunks in the old generation (for card marking).
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 191:
> 
>> 189:   }
>> 190: 
>> 191:   if (is_concurrent_young_mark_in_progress() && is_in_young(obj) && !marking_context()->allocated_after_mark_start(obj)) {
> 
> Just so I understand (and maybe this deserves a clarifying comment to help others understand):
>   The barrier we are concerned about here is SATB.  If obj is above TAMS, there's no need to enforce a SATB barrier.  Any reference residing above TAMS which is overwritten will have been marked already, or is about to be marked.  Either the value is already "presumed marked" because it also resides above TAMS, or its value was assigned from a root (in which case root scanning marked it), or it was copied from a pre-existing object (in which case it will be marked by scanning of that pre-existing object or by SATB).

Yes, concerned about SATB here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25905#discussion_r2157677596

From dholmes at openjdk.org  Fri Jun 20 04:43:27 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 20 Jun 2025 04:43:27 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation
In-Reply-To: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
Message-ID: <ZQ2T-yHO_lX8l_gyZRNR0BCKkG4DXhXoAWX55SBaHt0=.85d92299-203d-4a2f-8d28-b70f23a7d92d@github.com>

On Thu, 19 Jun 2025 11:26:26 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.
> 
> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.
> 
> Proposed changes in the shared class hierarchy:
> 
> 
> //  VM_Operation
> //    VM_Heap_Sync_Operation
> //      VM_GC_Operation
> //        VM_GC_Collect_Operation
> //          VM_SerialGCCollect
> //          VM_ParallelGCCollect
> //          VM_CollectForAllocation
> //            VM_SerialCollectForAllocation
> //            VM_ParallelCollectForAllocation
> //          VM_CollectForMetadataAllocation
> //        VM_GC_Service_Operation
> //          VM_GC_HeapInspection
> //      VM_Verify
> //      VM_PopulateDynamicDumpSharedSpace
> //      VM_PopulateDumpSharedSpace
> 
> 
> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".
> 
> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.
> 
> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.
> 
> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot...

This looks quite reasonable to me. Obviously GC folk get final approval.

One minor nit.

src/hotspot/share/gc/shared/gcVMOperations.hpp line 188:

> 186:                     GCCause::_heap_inspection /* GC Cause */,
> 187:                     0 /* total full collections, dummy, ignored */,
> 188:                     request_full_gc), _out(out), _full_gc(request_full_gc),

Please re-align the arguments.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25896#pullrequestreview-2944528759
PR Review Comment: https://git.openjdk.org/jdk/pull/25896#discussion_r2158024854

From shade at openjdk.org  Fri Jun 20 08:50:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 20 Jun 2025 08:50:29 GMT
Subject: RFR: 8357550: GenShen crashes during freeze:
 assert(!chunk->requires_barriers()) failed
In-Reply-To: <Ucznl2ab7HdNjJ4G0aho4mjN_MqfbsPyxNysd2g45uk=.35e6904b-a093-4bd5-ad77-ecae53ca9cf9@github.com>
References: <Ucznl2ab7HdNjJ4G0aho4mjN_MqfbsPyxNysd2g45uk=.35e6904b-a093-4bd5-ad77-ecae53ca9cf9@github.com>
Message-ID: <0L1NcCsN1AEMFQspK2dasofKoZ24YaP12PIgjxO9lHg=.ef2e6083-db79-47c7-8684-98204d9a270f@github.com>

On Thu, 19 Jun 2025 20:21:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah captures a preliminary top-at-mark-start (TAMS) concurrently. Once concurrent marking has begun, any object beneath TAMS requires a barrier when accessed. The implementation of `ShenandoahHeap::requires_barrier` does not distinguish between _old_ and _young_ marking. This could lead to a race between freezing the stack and capturing TAMS:
> 
> 1. Collector is marking old
> 2. Allocate stack chunk in young
> 3. Barrier is not needed, begin fast freeze path
> 4. Collector concurrently updates TAMS (young marking will start once init-mark safepoint is reached)
> 5. ShenandoahHeap now thinks the barrier is needed (because TAMS changed, and we are marking old)
> 6. Fast freeze asserts out
> 
> This fix has the generational mode check the appropriate generation and its marking state. It also enforces barriers for stackChunks in the old generation (for card marking).

This makes sense.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25905#pullrequestreview-2945074807

From mdoerr at openjdk.org  Fri Jun 20 09:01:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 20 Jun 2025 09:01:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
Message-ID: <aqutosiSmqM1u3TePxEPFdPkM0Apd1XfjY7WXEssO-0=.83eb647e-114f-4b4f-b0f1-d2d89e16a426@github.com>

On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd try at arm fix

> > Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance.
> 
> For ZGC I am using a per-nmethod lock: ZLocker locker(ZNMethod::lock_for_nmethod(nm));

Ah, right. So, ZGC should be fine.

> I don't know what benchmarks to run to check the performance for functions like Deoptimization::deoptimize_all_marked, so I welcome any help with this.

I have tried some SPEC benchmarks with G1 on PPC64, but couldn't observe a regression. (If there is one, it was below noise.)
 
> One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint.

I guess the most critical scenario is when many Java threads need to disarm a large number of nmethod entry barriers. That doesn't happen at a safepoint. Not sure if other scenarios are worth optimizing by this idea.

I guess this PR is ok as it is. Maybe other reviewers have more comments.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2990348628

From duke at openjdk.org  Fri Jun 20 09:38:56 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 20 Jun 2025 09:38:56 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v2]
In-Reply-To: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
Message-ID: <TgCAMNKAOcpp8YIa5cjtg_DeDyYSADp4_FBSQ3wwOLw=.73d7b7bc-b8ed-4016-87b9-65a3f7674f82@github.com>

> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.
> 
> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.
> 
> Proposed changes in the shared class hierarchy:
> 
> 
> //  VM_Operation
> //    VM_Heap_Sync_Operation
> //      VM_GC_Operation
> //        VM_GC_Collect_Operation
> //          VM_SerialGCCollect
> //          VM_ParallelGCCollect
> //          VM_CollectForAllocation
> //            VM_SerialCollectForAllocation
> //            VM_ParallelCollectForAllocation
> //          VM_CollectForMetadataAllocation
> //        VM_GC_Service_Operation
> //          VM_GC_HeapInspection
> //      VM_Verify
> //      VM_PopulateDynamicDumpSharedSpace
> //      VM_PopulateDumpSharedSpace
> 
> 
> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".
> 
> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.
> 
> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.
> 
> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot...

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Re-align arguments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25896/files
  - new: https://git.openjdk.org/jdk/pull/25896/files/7c8e6d81..7faaf506

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

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

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

From duke at openjdk.org  Fri Jun 20 09:38:56 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 20 Jun 2025 09:38:56 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v2]
In-Reply-To: <ZQ2T-yHO_lX8l_gyZRNR0BCKkG4DXhXoAWX55SBaHt0=.85d92299-203d-4a2f-8d28-b70f23a7d92d@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
 <ZQ2T-yHO_lX8l_gyZRNR0BCKkG4DXhXoAWX55SBaHt0=.85d92299-203d-4a2f-8d28-b70f23a7d92d@github.com>
Message-ID: <Dyr6AODa37szQwTZa5P7SaW9zc8eYssOTgxKWUs0C6o=.9c42c108-88fc-44d9-bb5f-5ff43f34a125@github.com>

On Fri, 20 Jun 2025 04:40:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-align arguments
>
> This looks quite reasonable to me. Obviously GC folk get final approval.
> 
> One minor nit.

Thanks for the review @dholmes-ora.

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

PR Comment: https://git.openjdk.org/jdk/pull/25896#issuecomment-2990502655

From wkemper at openjdk.org  Fri Jun 20 17:10:34 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Jun 2025 17:10:34 GMT
Subject: Integrated: 8357550: GenShen crashes during freeze:
 assert(!chunk->requires_barriers()) failed
In-Reply-To: <Ucznl2ab7HdNjJ4G0aho4mjN_MqfbsPyxNysd2g45uk=.35e6904b-a093-4bd5-ad77-ecae53ca9cf9@github.com>
References: <Ucznl2ab7HdNjJ4G0aho4mjN_MqfbsPyxNysd2g45uk=.35e6904b-a093-4bd5-ad77-ecae53ca9cf9@github.com>
Message-ID: <Y9wXwS2lgiA8UV5WPchkdiXFMmCeq7Z_-hLZt9FhmCQ=.3966546b-407c-4913-ad2e-cab2474e3ab8@github.com>

On Thu, 19 Jun 2025 20:21:35 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah captures a preliminary top-at-mark-start (TAMS) concurrently. Once concurrent marking has begun, any object beneath TAMS requires a barrier when accessed. The implementation of `ShenandoahHeap::requires_barrier` does not distinguish between _old_ and _young_ marking. This could lead to a race between freezing the stack and capturing TAMS:
> 
> 1. Collector is marking old
> 2. Allocate stack chunk in young
> 3. Barrier is not needed, begin fast freeze path
> 4. Collector concurrently updates TAMS (young marking will start once init-mark safepoint is reached)
> 5. ShenandoahHeap now thinks the barrier is needed (because TAMS changed, and we are marking old)
> 6. Fast freeze asserts out
> 
> This fix has the generational mode check the appropriate generation and its marking state. It also enforces barriers for stackChunks in the old generation (for card marking).

This pull request has now been integrated.

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

8357550: GenShen crashes during freeze: assert(!chunk->requires_barriers()) failed

Reviewed-by: kdnilsen, shade

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

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

From wkemper at openjdk.org  Fri Jun 20 18:52:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Jun 2025 18:52:39 GMT
Subject: [jdk25] RFR: 8357550: GenShen crashes during freeze:
 assert(!chunk->requires_barriers()) failed
Message-ID: <jlxaobHjXlpe6zIyAXP9WwORonEeiHSudYjZ4-UUHQs=.650abd09-64a2-47f7-9b40-f79f17e0dceb@github.com>

This is a low risk change that addresses an assertion failure when Shenandoah's generational mode is used with virtual threads.

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

Commit messages:
 - Backport 17cf49746d0c289bdf779c974cdc84a3ab32ab4b

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

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

From kbarrett at openjdk.org  Sun Jun 22 22:24:35 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 22 Jun 2025 22:24:35 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v4]
In-Reply-To: <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
Message-ID: <TLXICoci5pVVNQU2vs0eBEWs95Vgpj-o0IKcjgYFgcs=.58f537ca-0b87-4704-b692-8ab20f659c0e@github.com>

On Thu, 19 Jun 2025 12:26:15 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert suggestions

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 894:

> 892: 
> 893:   bool should_expand;
> 894:   size_t resize_bytes = _heap_sizing_policy->full_collection_resize_amount(should_expand, allocation_word_size);

pre-existing:  I wonder why this isn't a function that returns a `ptrdiff_t` delta on the current size,
removing the need for multiple values, one being returned via a by-reference out parameter.
Similarly for the young collection case. Or return the size & direction as a pair-like object.
(Personally, I find by-reference out parameters confusing to read, but maybe that's just me.)

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1028:

> 1026: 
> 1027:   uint num_regions_to_expand = (uint)(aligned_expand_bytes / G1HeapRegion::GrainBytes);
> 1028:   assert(num_regions_to_expand > 0, "Must expand by at least one region");

This assert seems like needless clutter to me. We just aligned up, and then we divided.
A (to me) more useful assert would be up-front that `word_size` > 0.

src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1042:

> 1040:   uint expanded_by = _hrm.expand_by(num_regions_to_expand, pretouch_workers);
> 1041: 
> 1042:   assert(expanded_by > 0, "must have failed during commit.");

pre-existing: Using an assert to detect and "handle" this seems wrong. This seems like something that
simply can happen? And so should be dealt with in some graceful fashion. It actually seems like things
would more or less work if the assert was just removed.

src/hotspot/share/gc/g1/g1CollectedHeap.hpp line 563:

> 561:   void resize_heap_after_young_collection(size_t allocation_word_size);
> 562:   void resize_heap_after_full_collection(size_t allocation_word_size);
> 563:   void resize_heap(size_t resize_bytes, bool should_expand);

I think `resize_heap` is a helper for the other two? So shouldn't be public.

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 1465:

> 1463: 
> 1464:     if (_g1h->last_gc_was_periodic()) {
> 1465:       _g1h->resize_heap_after_full_collection(size_t(0) /* allocation_word_size */);

I don't think a cast is needed here.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 93:

> 91:   // Sigmoid Parameters:
> 92:   double inflection_point = 1.0; // Inflection point where acceleration begins (midpoint of sigmoid).
> 93:   double steepness = 6.0;

Curious as to how these constants were determined. Maybe a comment about that?

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 95:

> 93:   double steepness = 6.0;
> 94: 
> 95:   return 1.0 / (1.0 + pow(M_E, -steepness * (value - inflection_point)));

Can use `exp` rather than `pow`.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 165:

> 163:   // Ensure the expansion size is at least the minimum growth amount
> 164:   // and at most the remaining uncommitted byte size.
> 165:   return clamp((size_t)resize_bytes, min_expand_bytes, uncommitted_bytes);

Don't need a cast of `resize_bytes` here.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 302:

> 300:     if (_g1h->capacity() == _g1h->max_capacity()) {
> 301:       log_resize(short_term_pause_time_ratio, long_term_pause_time_ratio,
> 302:                  lower_threshold, upper_threshold, pause_time_threshold, true, 0, expand);

We're on the expand-side of things, but `expand` hasn't been set to true yet.
Similarly, on the shrink side, we'll be passing in the default initial value for `expand` and
then setting it later. Maybe `expand` should be set earlier on each of the branches.

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

PR Review: https://git.openjdk.org/jdk/pull/25832#pullrequestreview-2935176410
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2152197151
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2160408699
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2160409675
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2160411832
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2160412727
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2160414808
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2160414939
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2160416276
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2160508087

From kbarrett at openjdk.org  Mon Jun 23 01:36:12 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 23 Jun 2025 01:36:12 GMT
Subject: RFR: 8360177: ParallelArguments::initialize has incorrect format
 string
Message-ID: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>

Please review this trivial fix to a jio_fprintf format string. It should be using
"%zu" to print values of type uintx, rather than using "%d".

Testing: mach5 tier1
Locally tested with gcc printf warnings enabled for jio_fprintf, and verified
the warnings for the changed call are no longer present.

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

Commit messages:
 - fix printing in ParallelArguments::initialize

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

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

From tschatzl at openjdk.org  Mon Jun 23 07:10:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 23 Jun 2025 07:10:31 GMT
Subject: RFR: 8360177: ParallelArguments::initialize has incorrect format
 string
In-Reply-To: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
References: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
Message-ID: <VfNdPbVJzksaE_EoAoHcFR3s0xHhVLR2dPkMp22LUT4=.c48fcdf9-84d8-402c-8d29-77ed285eac8e@github.com>

On Mon, 23 Jun 2025 01:30:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial fix to a jio_fprintf format string. It should be using
> "%zu" to print values of type uintx, rather than using "%d".
> 
> Testing: mach5 tier1
> Locally tested with gcc printf warnings enabled for jio_fprintf, and verified
> the warnings for the changed call are no longer present.

Changes requested by tschatzl (Reviewer).

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

> 71:       if (FLAG_IS_CMDLINE(MinSurvivorRatio)) {
> 72:         jio_fprintf(defaultStream::error_stream(),
> 73:           "Inconsistent MinSurvivorRatio vs InitialSurvivorRatio: %zu vs %zu\n", MinSurvivorRatio, InitialSurvivorRatio);

Should probably use `UINTX_FORMAT` instead.

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

PR Review: https://git.openjdk.org/jdk/pull/25926#pullrequestreview-2948909222
PR Review Comment: https://git.openjdk.org/jdk/pull/25926#discussion_r2160873780

From iwalulya at openjdk.org  Mon Jun 23 07:40:33 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 23 Jun 2025 07:40:33 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
Message-ID: <l_021q2gZtUsDC4L53HMmK2uQ0o7Mqf-zANhJD8ezV0=.fe3a36de-b2b0-40cf-b51b-4758e72263b9@github.com>

On Wed, 18 Jun 2025 09:00:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - version
>  - Merge branch 'master' into pgc-size-policy
>  - revert-aliases
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - merge-fix
>  - merge
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/2b94b70e...a21e5363

Do we have other uses of `class AdaptiveSizePolicy` except for parallelGC?

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

PR Comment: https://git.openjdk.org/jdk/pull/25000#issuecomment-2995286022

From tschatzl at openjdk.org  Mon Jun 23 08:01:49 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 23 Jun 2025 08:01:49 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v2]
In-Reply-To: <TgCAMNKAOcpp8YIa5cjtg_DeDyYSADp4_FBSQ3wwOLw=.73d7b7bc-b8ed-4016-87b9-65a3f7674f82@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
 <TgCAMNKAOcpp8YIa5cjtg_DeDyYSADp4_FBSQ3wwOLw=.73d7b7bc-b8ed-4016-87b9-65a3f7674f82@github.com>
Message-ID: <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com>

On Fri, 20 Jun 2025 09:38:56 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.
>> 
>> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.
>> 
>> Proposed changes in the shared class hierarchy:
>> 
>> 
>> //  VM_Operation
>> //    VM_Heap_Sync_Operation
>> //      VM_GC_Operation
>> //        VM_GC_Collect_Operation
>> //          VM_SerialGCCollect
>> //          VM_ParallelGCCollect
>> //          VM_CollectForAllocation
>> //            VM_SerialCollectForAllocation
>> //            VM_ParallelCollectForAllocation
>> //          VM_CollectForMetadataAllocation
>> //        VM_GC_Service_Operation
>> //          VM_GC_HeapInspection
>> //      VM_Verify
>> //      VM_PopulateDynamicDumpSharedSpace
>> //      VM_PopulateDumpSharedSpace
>> 
>> 
>> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".
>> 
>> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.
>> 
>> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.
>> 
>> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it...
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-align arguments

lgtm, but since the comment typos cause re-reviews, requesting changes.

src/hotspot/share/gc/shared/gcVMOperations.hpp line 47:

> 45: //          VM_CollectForAllocation
> 46: //            VM_SerialCollectForAllocation
> 47: //            VM_ParallelCollectForAllocation

Suggestion:

//          e.g. VM_SerialGCCollector
//          VM_CollectForAllocation
//            e.g. VM_SerialCollectForAllocation


This is not a real suggestion, but this hierarchy isn't complete, and I am not sure we should make it complete. Since we already skip Z/G1/Shenandoah operations here, I do not really see that Serial/Parallel specific operations should be here either.

Or maybe explicitly state Serial/Parallel vm ops as examples here as suggested above, but that does not look right either.

However this is kind of unrelated to this PR :)

src/hotspot/share/runtime/vmOperation.hpp line 164:

> 162: 
> 163:   // VMOp_Type may belong to a category of operation
> 164:   // Override is_XX_operation() appropriately in subclasses

Suggestion:

  // VMOp_Type may belong to a category of the operation.
  // Override is_XX_operation() appropriately in subclasses.

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25896#pullrequestreview-2949032479
PR Review Comment: https://git.openjdk.org/jdk/pull/25896#discussion_r2160960642
PR Review Comment: https://git.openjdk.org/jdk/pull/25896#discussion_r2160950023

From tschatzl at openjdk.org  Mon Jun 23 08:03:32 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 23 Jun 2025 08:03:32 GMT
Subject: RFR: 8359924: Deprecate and obsolete ParallelRefProcEnabled
In-Reply-To: <DuEuTPObPfC8YE9gxFMA896tdo5VgWeiaD-Hwg-54fU=.d37466d4-a73e-411a-b5e2-15f9b40496a5@github.com>
References: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
 <R7qZ9SSAwhix_BsnXJGarUpPyNSNXnd8oJWs-BJAy1E=.9c75fa3f-96f9-411b-857a-62560d28aa07@github.com>
 <DuEuTPObPfC8YE9gxFMA896tdo5VgWeiaD-Hwg-54fU=.d37466d4-a73e-411a-b5e2-15f9b40496a5@github.com>
Message-ID: <T1KjDH61TfFMtqiteVd892YhwBHaVA-orEwxhlVhjNA=.0367bc50-953b-4e4b-8cfd-3ec67290e161@github.com>

On Wed, 18 Jun 2025 21:26:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> > Same with `ReferencesPerThread`, again separately, but that does not need a CSR.
> 
> We could remove ReferencesPerThread immediately, without first deprecating, since it's experimental.

I would keep it as diagnostic option just in case, but removing this is also an option.

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

PR Comment: https://git.openjdk.org/jdk/pull/25875#issuecomment-2995361450

From ayang at openjdk.org  Mon Jun 23 08:30:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 23 Jun 2025 08:30:38 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v13]
In-Reply-To: <l_021q2gZtUsDC4L53HMmK2uQ0o7Mqf-zANhJD8ezV0=.fe3a36de-b2b0-40cf-b51b-4758e72263b9@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <76NgHH-m26Nw2paJmIQvNNqio_iKtdQ_bJ2aejMfKEI=.82ff25aa-f5c5-4146-84b5-1aaaefb5efd1@github.com>
 <l_021q2gZtUsDC4L53HMmK2uQ0o7Mqf-zANhJD8ezV0=.fe3a36de-b2b0-40cf-b51b-4758e72263b9@github.com>
Message-ID: <ccirFcIxHT8qELOWVeVYIu4E1FR2X0zDLn9DwPGl3yw=.5e32ad06-e2cd-4aa2-8338-c337ca887990@github.com>

On Mon, 23 Jun 2025 07:38:09 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Do we have other uses of class AdaptiveSizePolicy except for parallelGC?

No. A followup cleanup can be to merge this class into its sole subclass, used by Parallel.

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

PR Comment: https://git.openjdk.org/jdk/pull/25000#issuecomment-2995445820

From ayang at openjdk.org  Mon Jun 23 08:30:43 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 23 Jun 2025 08:30:43 GMT
Subject: RFR: 8359924: Deprecate and obsolete ParallelRefProcEnabled
In-Reply-To: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
References: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
Message-ID: <a_PbrW7r3OGcrSxA6TRONDeogjnUusdblnuKTyO1Xio=.3ad1bd4f-ba23-4556-be0d-675247a02081@github.com>

On Wed, 18 Jun 2025 14:04:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `ParallelRefProcEnabled`, which is used only by Parallel and G1, and both have it enabled by default via:
> 
> 
>   if (FLAG_IS_DEFAULT(ParallelRefProcEnabled) && ParallelGCThreads > 1) {
>     FLAG_SET_DEFAULT(ParallelRefProcEnabled, true);
>   }
> 
> 
> Disabling it offers little benefit and its presence incurs some implementation complexity in the reference-processor.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25875#issuecomment-2995440116

From ayang at openjdk.org  Mon Jun 23 08:30:44 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 23 Jun 2025 08:30:44 GMT
Subject: Integrated: 8359924: Deprecate and obsolete ParallelRefProcEnabled
In-Reply-To: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
References: <iUkA51NXiyZ0EuEwxjx5OSQO-A9Tyx8baopQ3Ifixdk=.356dd381-3413-4f4a-9aae-b63ebc6ba699@github.com>
Message-ID: <ZJ2oLmFNlscR1Yu6bJHOVQ-vy0twrVisYvwo45a10Ws=.e7ac4cb5-8849-4417-9fd2-e751faa47eef@github.com>

On Wed, 18 Jun 2025 14:04:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `ParallelRefProcEnabled`, which is used only by Parallel and G1, and both have it enabled by default via:
> 
> 
>   if (FLAG_IS_DEFAULT(ParallelRefProcEnabled) && ParallelGCThreads > 1) {
>     FLAG_SET_DEFAULT(ParallelRefProcEnabled, true);
>   }
> 
> 
> Disabling it offers little benefit and its presence incurs some implementation complexity in the reference-processor.

This pull request has now been integrated.

Changeset: 516197f5
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/516197f50b079978a4aa1593744cef9d56e01c67
Stats:     19 lines in 3 files changed: 10 ins; 8 del; 1 mod

8359924: Deprecate and obsolete ParallelRefProcEnabled

Reviewed-by: tschatzl, kbarrett, dholmes

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

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

From ayang at openjdk.org  Mon Jun 23 08:34:22 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 23 Jun 2025 08:34:22 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v14]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <9oCyQapT5zkgtiWmLQoPBY10EUD6Q4LIEO4Sr6nyxXI=.963bc30b-a996-4c5a-9594-16c36c6c70db@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - merge
 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - merge-fix
 - ... and 10 more: https://git.openjdk.org/jdk/compare/516197f5...41027bdf

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=13
  Stats: 4371 lines in 31 files changed: 520 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From ayang at openjdk.org  Mon Jun 23 08:36:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 23 Jun 2025 08:36:13 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues
Message-ID: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>

Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.

Test: tier1-3

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

Commit messages:
 - ref-refactor

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

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

From shade at openjdk.org  Mon Jun 23 08:38:29 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 23 Jun 2025 08:38:29 GMT
Subject: [jdk25] RFR: 8357550: GenShen crashes during freeze:
 assert(!chunk->requires_barriers()) failed
In-Reply-To: <jlxaobHjXlpe6zIyAXP9WwORonEeiHSudYjZ4-UUHQs=.650abd09-64a2-47f7-9b40-f79f17e0dceb@github.com>
References: <jlxaobHjXlpe6zIyAXP9WwORonEeiHSudYjZ4-UUHQs=.650abd09-64a2-47f7-9b40-f79f17e0dceb@github.com>
Message-ID: <SkInYtLrZ0Zn_kJJyN6EDhtNZTHnvyaWZ2nr8jAUGK4=.e9c0e8c7-a34a-4f88-bf60-c3c9c630a4ce@github.com>

On Fri, 20 Jun 2025 18:48:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a low risk change that addresses an assertion failure when Shenandoah's generational mode is used with virtual threads.

Looks fine for RDP1.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25918#pullrequestreview-2949172369

From thomas.schatzl at oracle.com  Mon Jun 23 08:57:26 2025
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Mon, 23 Jun 2025 10:57:26 +0200
Subject: RFC: JEP draft: Ergonomics Always Select the G1 Garbage Collector as
 Default
Message-ID: <279a6ba3-9fb6-442c-b059-91a31365704a@oracle.com>

Hi all,

   this is a continuation of an earlier thread [0] where I suggested to 
make G1 as the default collector unconditionally.

As you may know, on very small deployments (1 CPU and 1.8GB of heap), 
ergonomics still select the Serial collector if no GC algorithm is 
selected on the command line.

Since there has not been any pushback to that suggestion, I wrote up a 
JEP draft [1], so I wanted to ask for further feedback before submitting 
it.

Thanks,
   Thomas

[0] 
https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-February/051121.html
[1] https://bugs.openjdk.org/browse/JDK-8359802

From ayang at openjdk.org  Mon Jun 23 09:20:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 23 Jun 2025 09:20:42 GMT
Subject: RFR: 8360220: Deprecate and obsolete ParallelRefProcBalancingEnabled
Message-ID: <AZ1eqJ9Vnat7cWLTlQ3Z2PzGBTk5S5XqjqMYX10nb6Q=.1e4d6765-fade-436f-8e55-0b11b3e6463d@github.com>

Deprecating `ParallelRefProcBalancingEnabled`, which is used only by Parallel and G1, and both have it enabled by default.

Disabling it offers little benefit, so removing it do reduce the number commandline flags.

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

Commit messages:
 - deprecate-balance

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

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

From tschatzl at openjdk.org  Mon Jun 23 10:13:35 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 23 Jun 2025 10:13:35 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v4]
In-Reply-To: <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
Message-ID: <E9ZO9GfSk6Ck3wTC8Q-nz2CE-FRvnNqzklvzdcjESlY=.4d062789-0c01-4eed-a447-96f73dc007d5@github.com>

On Thu, 19 Jun 2025 12:26:15 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert suggestions

Some minor nits I think.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 61:

> 59: 
> 60:   assert(G1ShortTermShrinkThreshold <= long_term_count_limit(),
> 61:          "Shrink threshold count must be less than %u", long_term_count_limit());

I would prefer if these would be part of argument processing.
I see that below we just ignore what the user specified for `G1ShortTermShrinkThreshold` if it is too high when determining `ThresholdForShrink`, but I would prefer to just fail early if the diagnostic option is out of bounds.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 225:

> 223:   // - lower threshold, we do not want to go under.
> 224:   // - mid threshold, halfway between upper and lower threshold, represents the
> 225:   // actual target when resizing the heap.

Suggestion:

  // - actual pause time threshold, halfway between upper and lower threshold, represents the
  // actual target when resizing the heap.


("mid-threshold" is some renmant of the original change)

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 335:

> 333:     // A resize has not been triggered, but the long term counter overflowed.
> 334:     decay_ratio_tracking_data();
> 335:     expand = true; // Does not matter.

Maybe we should return `expand = false` in the cases where `resize_bytes == 0` always? maybe in the log printing below we should suppress the `expand: <bool>` part if `resize_bytes == 0` too.

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

> 160:   product(uint, G1ExpandByPercentOfAvailable, 20, EXPERIMENTAL,             \
> 161:           "When expanding, % of uncommitted space to claim.")               \
> 162:           range(0, 100)                                                     \

Suggestion:

          "When expanding, % of uncommitted space to expand the heap by in a single expand attempt.")               \
          range(0, 100)                                                     \

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

> 164:   product(uint, G1ShrinkByPercentOfAvailable, 50, EXPERIMENTAL,           \
> 165:           "When shrinking, maximum % of free space to claim.")              \
> 166:           range(0, 100)                                                     \

Suggestion:

          "When shrinking, maximum % of free space to free for a single shrink attempt.")              \
          range(0, 100)                                                     \

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

> 167:                                                                             \
> 168:   product(uint, G1MinimumPercentOfGCTimeRatio, 25, EXPERIMENTAL,          \
> 169:           "Percentage of GCTimeRatio G1 will try to avoid going below.")    \

Suggestion:

          "Determines lower and upper thresholds as percentage of GCTimeRatio. G1 compares these thresholds against the current gc cpu usage (gc time ratio?) to register too low or too high cpu usage events for heap resizing.")    \

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

> 172:   product(uint, G1ShortTermShrinkThreshold, 8, EXPERIMENTAL,                \
> 173:           "Number of consecutive GCs with the short term gc time ratio"     \
> 174:           "below the threshold before we attempt to shrink.")               \

I think the description is somewhat confusing.

Suggestion:

          "Number of consecutive GCs where the current gc time ratio"     \
          "below the lower threshold before G1 attempts to shrink.")               \

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

> 174:           "below the threshold before we attempt to shrink.")               \
> 175:           range(0, 10)                                                      \
> 176:                                                                             \

I would make them diagnostic, not experimental. They might need to be tweaked, and it's better to provide them as diagnostic than experimental. Just sounds more "safe" to use for end users when providing them. It's not like they trigger potentially unstable features.

Also, for symmetry I think we should provide a `G1ShortTermExpandThreshold` as well instead of the constant `MinOverThresholdForExpansion` embedded in the code.

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25832#pullrequestreview-2949374369
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2161197065
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2161162327
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2161208940
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2161191299
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2161188405
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2161184827
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2161187759
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2161179316

From tschatzl at openjdk.org  Mon Jun 23 10:13:36 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 23 Jun 2025 10:13:36 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v4]
In-Reply-To: <TLXICoci5pVVNQU2vs0eBEWs95Vgpj-o0IKcjgYFgcs=.58f537ca-0b87-4704-b692-8ab20f659c0e@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
 <TLXICoci5pVVNQU2vs0eBEWs95Vgpj-o0IKcjgYFgcs=.58f537ca-0b87-4704-b692-8ab20f659c0e@github.com>
Message-ID: <XrSIiI4qA2dnkvdNcR0bJgFKKZlJ5NztgwN-cmJWp40=.825c2aba-e5c7-4d2c-a40c-74e13e3d76fc@github.com>

On Sun, 22 Jun 2025 22:15:12 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert suggestions
>
> src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 302:
> 
>> 300:     if (_g1h->capacity() == _g1h->max_capacity()) {
>> 301:       log_resize(short_term_pause_time_ratio, long_term_pause_time_ratio,
>> 302:                  lower_threshold, upper_threshold, pause_time_threshold, true, 0, expand);
> 
> We're on the expand-side of things, but `expand` hasn't been set to true yet.
> Similarly, on the shrink side, we'll be passing in the default initial value for `expand` and
> then setting it later. Maybe `expand` should be set earlier on each of the branches.

It does not matter for this case, ideally the log message would not print the information about whether we expanded or not (because we did not). Maybe you are right, we were trying to expand at least (and just pass `true` here?).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2161205385

From duke at openjdk.org  Mon Jun 23 10:18:10 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 23 Jun 2025 10:18:10 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v3]
In-Reply-To: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
Message-ID: <Yw7Kr_UxllF3h1udyea1YDDTShIuSMuqbqlXwqTYilQ=.01d5e484-9d17-4f4e-9309-7b5b93f7afa6@github.com>

> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.
> 
> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.
> 
> Proposed changes in the shared class hierarchy:
> 
> 
> //  VM_Operation
> //    VM_Heap_Sync_Operation
> //      VM_GC_Operation
> //        VM_GC_Collect_Operation
> //          VM_SerialGCCollect
> //          VM_ParallelGCCollect
> //          VM_CollectForAllocation
> //            VM_SerialCollectForAllocation
> //            VM_ParallelCollectForAllocation
> //          VM_CollectForMetadataAllocation
> //        VM_GC_Service_Operation
> //          VM_GC_HeapInspection
> //      VM_Verify
> //      VM_PopulateDynamicDumpSharedSpace
> //      VM_PopulateDumpSharedSpace
> 
> 
> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".
> 
> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.
> 
> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.
> 
> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot...

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo
  
  Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25896/files
  - new: https://git.openjdk.org/jdk/pull/25896/files/7faaf506..546ad943

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

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

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

From duke at openjdk.org  Mon Jun 23 10:18:10 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 23 Jun 2025 10:18:10 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v2]
In-Reply-To: <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
 <TgCAMNKAOcpp8YIa5cjtg_DeDyYSADp4_FBSQ3wwOLw=.73d7b7bc-b8ed-4016-87b9-65a3f7674f82@github.com>
 <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com>
Message-ID: <w8NGB4u-e4regYQjcwN10xrcO2Nu2r1tNMbcUN_9A4w=.f62777d4-afdf-4c37-8ae3-6ace6d081a58@github.com>

On Mon, 23 Jun 2025 07:58:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-align arguments
>
> lgtm, but since the comment typos cause re-reviews, requesting changes.

Thanks for the review @tschatzl, I fixed the typo.

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

PR Comment: https://git.openjdk.org/jdk/pull/25896#issuecomment-2995818445

From duke at openjdk.org  Mon Jun 23 10:22:29 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 23 Jun 2025 10:22:29 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v2]
In-Reply-To: <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
 <TgCAMNKAOcpp8YIa5cjtg_DeDyYSADp4_FBSQ3wwOLw=.73d7b7bc-b8ed-4016-87b9-65a3f7674f82@github.com>
 <_0FpXJCHvJB_-A62OEcHj5EaMPbrNmUlFxNq-CFnTIs=.09975d8e-b832-4150-94b1-3d905fa4b495@github.com>
Message-ID: <iNQqgKHWSkcUrdr4XSqNewiuyHhrKBVuAM3nEz4LfdY=.4ee869ba-49ea-4657-8aa6-42abc3c03b5c@github.com>

On Mon, 23 Jun 2025 07:56:57 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-align arguments
>
> src/hotspot/share/gc/shared/gcVMOperations.hpp line 47:
> 
>> 45: //          VM_CollectForAllocation
>> 46: //            VM_SerialCollectForAllocation
>> 47: //            VM_ParallelCollectForAllocation
> 
> Suggestion:
> 
> //          e.g. VM_SerialGCCollector
> //          VM_CollectForAllocation
> //            e.g. VM_SerialCollectForAllocation
> 
> 
> This is not a real suggestion, but this hierarchy isn't complete, and I am not sure we should make it complete. Since we already skip Z/G1/Shenandoah operations here, I do not really see that Serial/Parallel specific operations should be here either.
> 
> Or maybe explicitly state Serial/Parallel vm ops as examples here as suggested above, but that does not look right either.
> 
> However this is kind of unrelated to this PR :)

Given that the comment was wrong to begin with, i.e. `VM_PopulateDynamicDumpSharedSpace` was under  `VM_GC_Operation` but actually it inherited from `VM_GC_Sync_Operation`, we migh consider removing the comment? But as you say, this discussion belong in another PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25896#discussion_r2161248592

From tschatzl at openjdk.org  Mon Jun 23 10:32:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 23 Jun 2025 10:32:29 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v3]
In-Reply-To: <Yw7Kr_UxllF3h1udyea1YDDTShIuSMuqbqlXwqTYilQ=.01d5e484-9d17-4f4e-9309-7b5b93f7afa6@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
 <Yw7Kr_UxllF3h1udyea1YDDTShIuSMuqbqlXwqTYilQ=.01d5e484-9d17-4f4e-9309-7b5b93f7afa6@github.com>
Message-ID: <Sko-OY2WFH8-4XVU4CpTeZGnTiGkj-dhJ74nu3dzV1w=.9a7af476-a5c1-43ba-940c-9909b1e24404@github.com>

On Mon, 23 Jun 2025 10:18:10 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.
>> 
>> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.
>> 
>> Proposed changes in the shared class hierarchy:
>> 
>> 
>> //  VM_Operation
>> //    VM_Heap_Sync_Operation
>> //      VM_GC_Operation
>> //        VM_GC_Collect_Operation
>> //          VM_SerialGCCollect
>> //          VM_ParallelGCCollect
>> //          VM_CollectForAllocation
>> //            VM_SerialCollectForAllocation
>> //            VM_ParallelCollectForAllocation
>> //          VM_CollectForMetadataAllocation
>> //        VM_GC_Service_Operation
>> //          VM_GC_HeapInspection
>> //      VM_Verify
>> //      VM_PopulateDynamicDumpSharedSpace
>> //      VM_PopulateDumpSharedSpace
>> 
>> 
>> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".
>> 
>> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.
>> 
>> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.
>> 
>> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it...
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25896#pullrequestreview-2949538397

From kbarrett at openjdk.org  Mon Jun 23 12:14:30 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 23 Jun 2025 12:14:30 GMT
Subject: RFR: 8360220: Deprecate and obsolete
 ParallelRefProcBalancingEnabled
In-Reply-To: <AZ1eqJ9Vnat7cWLTlQ3Z2PzGBTk5S5XqjqMYX10nb6Q=.1e4d6765-fade-436f-8e55-0b11b3e6463d@github.com>
References: <AZ1eqJ9Vnat7cWLTlQ3Z2PzGBTk5S5XqjqMYX10nb6Q=.1e4d6765-fade-436f-8e55-0b11b3e6463d@github.com>
Message-ID: <QPqR5QGEwwXdKE3RJumEpGYVaPZvZsLfOVs14f1la-o=.25766a26-6552-4b56-94e8-9ab92e5c79a7@github.com>

On Mon, 23 Jun 2025 09:14:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `ParallelRefProcBalancingEnabled`, which is used only by Parallel and G1, and both have it enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number commandline flags.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25932#pullrequestreview-2949857471

From duke at openjdk.org  Mon Jun 23 12:19:35 2025
From: duke at openjdk.org (duke)
Date: Mon, 23 Jun 2025 12:19:35 GMT
Subject: RFR: 8360024: Reorganize GC VM operations and implement
 is_gc_operation [v3]
In-Reply-To: <Yw7Kr_UxllF3h1udyea1YDDTShIuSMuqbqlXwqTYilQ=.01d5e484-9d17-4f4e-9309-7b5b93f7afa6@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
 <Yw7Kr_UxllF3h1udyea1YDDTShIuSMuqbqlXwqTYilQ=.01d5e484-9d17-4f4e-9309-7b5b93f7afa6@github.com>
Message-ID: <VYsZGlrPEkne0J60xYlKFsYB70Itlk7NakxqVX2HIL8=.48dc3366-ec3e-49d3-bde7-f7b6ac1b337a@github.com>

On Mon, 23 Jun 2025 10:18:10 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.
>> 
>> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.
>> 
>> Proposed changes in the shared class hierarchy:
>> 
>> 
>> //  VM_Operation
>> //    VM_Heap_Sync_Operation
>> //      VM_GC_Operation
>> //        VM_GC_Collect_Operation
>> //          VM_SerialGCCollect
>> //          VM_ParallelGCCollect
>> //          VM_CollectForAllocation
>> //            VM_SerialCollectForAllocation
>> //            VM_ParallelCollectForAllocation
>> //          VM_CollectForMetadataAllocation
>> //        VM_GC_Service_Operation
>> //          VM_GC_HeapInspection
>> //      VM_Verify
>> //      VM_PopulateDynamicDumpSharedSpace
>> //      VM_PopulateDumpSharedSpace
>> 
>> 
>> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".
>> 
>> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.
>> 
>> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.
>> 
>> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it...
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo
>   
>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

@JonasNorlinder 
Your change (at version 546ad94372c0cc06e1fd7127c89ef682d90ae800) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/25896#issuecomment-2996268758

From tschatzl at openjdk.org  Mon Jun 23 12:47:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 23 Jun 2025 12:47:31 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues
In-Reply-To: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
Message-ID: <Moz7R5qPPqUyyhcryaIDib1u_1IyeLO3NmM2_mqHYwQ=.7d2c8785-177f-4263-8de2-94cdb139217a@github.com>

On Mon, 23 Jun 2025 08:30:26 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
> 
> Test: tier1-3

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25930#pullrequestreview-2949956670

From tschatzl at openjdk.org  Mon Jun 23 12:49:30 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 23 Jun 2025 12:49:30 GMT
Subject: RFR: 8360220: Deprecate and obsolete
 ParallelRefProcBalancingEnabled
In-Reply-To: <AZ1eqJ9Vnat7cWLTlQ3Z2PzGBTk5S5XqjqMYX10nb6Q=.1e4d6765-fade-436f-8e55-0b11b3e6463d@github.com>
References: <AZ1eqJ9Vnat7cWLTlQ3Z2PzGBTk5S5XqjqMYX10nb6Q=.1e4d6765-fade-436f-8e55-0b11b3e6463d@github.com>
Message-ID: <w6uXyQ1phJ0Gsua69n4RXY_3cJTXKzzLi14iKvcuvCE=.8cb15ce9-5175-4e9b-acf9-928445b5bd20@github.com>

On Mon, 23 Jun 2025 09:14:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `ParallelRefProcBalancingEnabled`, which is used only by Parallel and G1, and both have it enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number commandline flags.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25932#pullrequestreview-2949965234

From eosterlund at openjdk.org  Mon Jun 23 12:49:41 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 23 Jun 2025 12:49:41 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
Message-ID: <h4VD2nNf444D2dAPERaMLAEJurbfSEGDNirvDvEtVfk=.3470cc9d-3a5d-4b29-b9ab-a4d287080f3d@github.com>

On Tue, 17 Jun 2025 20:59:46 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
> 
>   2nd try at arm fix

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2949966322

From eosterlund at openjdk.org  Mon Jun 23 12:49:41 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 23 Jun 2025 12:49:41 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <NDd13XSxcbkLkY1hPDt7hlRUAo_3zlHikMaBpAHy8po=.c399c3e1-df5e-4ea8-a667-68d12bac991a@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
 <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
 <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>
 <S_WVqyvsvxDSez9c0syZRE2cr8kQ1yeSOs9w4zBEWAY=.23eec805-97e0-4982-8417-6f0114646fbb@github.com>
 <NDd13XSxcbkLkY1hPDt7hlRUAo_3zlHikMaBpAHy8po=.c399c3e1-df5e-4ea8-a667-68d12bac991a@github.com>
Message-ID: <gQcwrLo4ooSL418-Tl7D_KgnmVMPZ5HdJNJHm8OCFA4=.b3afd47c-2c8b-4bce-a8d1-e0b6c30c694d@github.com>

On Thu, 19 Jun 2025 00:20:05 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Well, yeah sort of. And hence the comment that it's probably fine in terms of correctness. They were also a bit more independent systems then though. Just thought that if we now take the step to merge compiler and GC entry trap mechanisms into the nmethod entry barrier, that we could seemingly also make it a bit less slippery here and establish some sort of invariant that if we while holding the lock protecting the entry barrier find that the nmethod entry barrier is not entrant, for whatever reason, we should not enter it. Would make it easier to understand the code I suspect. What do you think?
>
> I think making it less slippery in one place but still leaving other races gives a false sense of security and makes the code harder to understand.  Arming the barrier is not guaranteed to be visible until there is a safepoint.  Note that AArch64 and RISCV only call increment_patching_epoch() when the guard value is set to the disarmed value, so there is no invalidation of the CPU pipeline or instruction buffer (cross modification fence) when arming.

Okay. I would have preferred to not enter the nmethod when we evaluate the guard bits under the lock that protects it and see that it's supposed to be not entrant. But I won't argue for it further if you prefer not to change that. Other than that, I think this looks good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2161540372

From duke at openjdk.org  Mon Jun 23 12:52:33 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 23 Jun 2025 12:52:33 GMT
Subject: Integrated: 8360024: Reorganize GC VM operations and implement
 is_gc_operation
In-Reply-To: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
References: <PeG3YXWzYAc0y0d_eU2nOlRV-ru72XRdb8JFHL3Aepo=.53e24ba5-0813-45ed-a8e4-2875ed47f4d1@github.com>
Message-ID: <otrbVqtXQpiCg94AOnygjMVvfyXgn2TMhomVjGMjEnE=.5fd5a8fe-7ba8-4848-b8ac-fc3355fce057@github.com>

On Thu, 19 Jun 2025 11:26:26 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> [JDK-8359110](https://bugs.openjdk.org/browse/JDK-8359110) introduces a need to be able to categorize VM operations to be able to track GC activity in the VM thread for CPU time tracking. This patch will reorganize the shared GC VM operations in gcVMOperations.hpp to make a distinction between GC operations and serviceability/CDS etc. operations performed in the VM thread for the GC.
> 
> Additionally the ability to query `is_gc_operation()` is introduced in the base class `VM_Operation` and overridden in appropriate VM operations. This provides a clear and efficient interface to query the category of a VM operation.
> 
> Proposed changes in the shared class hierarchy:
> 
> 
> //  VM_Operation
> //    VM_Heap_Sync_Operation
> //      VM_GC_Operation
> //        VM_GC_Collect_Operation
> //          VM_SerialGCCollect
> //          VM_ParallelGCCollect
> //          VM_CollectForAllocation
> //            VM_SerialCollectForAllocation
> //            VM_ParallelCollectForAllocation
> //          VM_CollectForMetadataAllocation
> //        VM_GC_Service_Operation
> //          VM_GC_HeapInspection
> //      VM_Verify
> //      VM_PopulateDynamicDumpSharedSpace
> //      VM_PopulateDumpSharedSpace
> 
> 
> Renaming `VM_GC_Sync_Operation` to `VM_Heap_Sync_Operation` to make it clear that not all sub-classes is related to GC (shout-out to @kstefanj / @stefank for that suggestion). While `VM_GC_HeapInspection` is a serviceability operation it attempts to trigger a collection, hence it is put underneath `VM_GC_Collect_Operation->VM_GC_Service_Operation`. However only classes that inherits from `VM_GC_Collect_Operation` are considered to return `true` for `is_gc_operation()` as `VM_GC_HeapInspection` is considered to not belong to "GC activity".
> 
> ZGC and Shenandoah do not use sub-classing of `VM_Heap_Sync_Operation`, but their respective base classes and special classes for GC activity are marked as returning `true` for `is_gc_operation()`.
> 
> The only `is_XX_operation` that is specified in `VM_Operation` is `is_gc_operation` to not clutter with cases that are not used (`is_gc_operation` will be used by JDK-8359110). That being said, these behavioral queries may be extended in case we want to explore CPU time tracking beyond the GC component.
> 
> _Note: PR for JDK-8359110 already contains a proposal for `is_gc_operation` but it was deemed that it was more appropriate to bring along that change during reorganization of GC VM operations since implementing it at the correct places without this change would require a lot...

This pull request has now been integrated.

Changeset: c748d358
Author:    Jonas Norlinder <github.jonas.norlinder at norlinder.nu>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c748d358b2569928fb5a03722987c93762c30145
Stats:     84 lines in 12 files changed: 44 ins; 0 del; 40 mod

8360024: Reorganize GC VM operations and implement is_gc_operation

Reviewed-by: tschatzl, dholmes

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

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

From jsikstro at openjdk.org  Mon Jun 23 13:08:18 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 23 Jun 2025 13:08:18 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v8]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <zy0Qh0f-TD62c7_0DbFLK397FjXegNKFZPdPdETwAZk=.f262452d-cad2-4f80-8e88-9a27789c2996@github.com>

> Hello,
> 
> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
> 
> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
> 
> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
> 
> Testing:
> * Oracle's tier 1-5

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

 - Merge branch 'master' into JDK-8358586_zallocator_cleanup
 - Rework ZObjectAllocator
 - Private member variables in ZObjectAlloactorImpl
 - Move implementation to .cpp and static-only interface in .hpp
 - Consistent template friend style
 - Friend class ValueObjBlock
 - AllStatic interface with ZObjectAllocators
 - -Wconversion fixes
 - Intermediate alloc_object in ZHeap
 - 8358586: ZGC: Combine ZAllocator and ZObjectAllocator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/4ef788d7..d2b59317

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

  Stats: 27752 lines in 695 files changed: 15142 ins; 8780 del; 3830 mod
  Patch: https://git.openjdk.org/jdk/pull/25693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25693/head:pull/25693

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

From duke at openjdk.org  Mon Jun 23 13:12:28 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 23 Jun 2025 13:12:28 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v9]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <YLer4W0t8eLT5pUta2WCFfVYCdq7DwswRRFKwsUf0wo=.d4e61f23-d3fa-4523-b2e6-2575d1fb9cbd@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Remove incorrect is_gc_operation call after rebase
 - More clean up, remove virtual
 - Fixes after feedback from @stefank
 - Remove extra whitespace
 - operation_is_gc -> is_gc_operation per @stefank suggestion
 - Only sample if needed
 - Remove explicit super call and minor fixes
 - Add CPU time tracking for string deduplication to log_gc_vtime
 - Replace calls to log_gc_vtime with super-class method calls
 - Add bug fix after refactor and fixes for review
 - ... and 6 more: https://git.openjdk.org/jdk/compare/c748d358...553edc48

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

Changes: https://git.openjdk.org/jdk/pull/25779/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=08
  Stats: 233 lines in 15 files changed: 223 ins; 7 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

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

From duke at openjdk.org  Mon Jun 23 13:23:29 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 23 Jun 2025 13:23:29 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v9]
In-Reply-To: <YLer4W0t8eLT5pUta2WCFfVYCdq7DwswRRFKwsUf0wo=.d4e61f23-d3fa-4523-b2e6-2575d1fb9cbd@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <YLer4W0t8eLT5pUta2WCFfVYCdq7DwswRRFKwsUf0wo=.d4e61f23-d3fa-4523-b2e6-2575d1fb9cbd@github.com>
Message-ID: <MReF2wyWFJszcCtOz-EnbPWLt7bJ8fMQ0lfwXEY4yJQ=.99d8b828-e156-4213-85a5-d390262d7b9f@github.com>

On Mon, 23 Jun 2025 13:12:28 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Remove incorrect is_gc_operation call after rebase
>  - More clean up, remove virtual
>  - Fixes after feedback from @stefank
>  - Remove extra whitespace
>  - operation_is_gc -> is_gc_operation per @stefank suggestion
>  - Only sample if needed
>  - Remove explicit super call and minor fixes
>  - Add CPU time tracking for string deduplication to log_gc_vtime
>  - Replace calls to log_gc_vtime with super-class method calls
>  - Add bug fix after refactor and fixes for review
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/c748d358...553edc48

Changes:
* Fixes after feedback from @stefank 
* Re-based on master so that the integration of [JDK-8360024](https://bugs.openjdk.org/browse/JDK-8360024) is included (apologies for the force-push)
* Removed conditional sampling per @tschatzl request

While CPU time may be slightly incorrect if heap dumping or heap inspection occurs, the risk is small that the number would be skewed in a significant way and we have a plan on how to mitigate with that going forward, therefore I suggest we can go ahead and integrate this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-2996481626

From ayang at openjdk.org  Mon Jun 23 14:10:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 23 Jun 2025 14:10:34 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v9]
In-Reply-To: <YLer4W0t8eLT5pUta2WCFfVYCdq7DwswRRFKwsUf0wo=.d4e61f23-d3fa-4523-b2e6-2575d1fb9cbd@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <YLer4W0t8eLT5pUta2WCFfVYCdq7DwswRRFKwsUf0wo=.d4e61f23-d3fa-4523-b2e6-2575d1fb9cbd@github.com>
Message-ID: <BgaYTXMTce7LBJAfqnll72hjJcuPmWZoSX6_aTXVLJM=.e1b38e72-51b6-4a87-97cd-e01d315050d3@github.com>

On Mon, 23 Jun 2025 13:12:28 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Remove incorrect is_gc_operation call after rebase
>  - More clean up, remove virtual
>  - Fixes after feedback from @stefank
>  - Remove extra whitespace
>  - operation_is_gc -> is_gc_operation per @stefank suggestion
>  - Only sample if needed
>  - Remove explicit super call and minor fixes
>  - Add CPU time tracking for string deduplication to log_gc_vtime
>  - Replace calls to log_gc_vtime with super-class method calls
>  - Add bug fix after refactor and fixes for review
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/c748d358...553edc48

src/hotspot/share/gc/shared/collectedHeap.hpp line 245:

> 243: 
> 244:   // Stop any onging concurrent work and prepare for exit.
> 245:   virtual void stop();

I find it a bit odd to call `log_gc_vtime` inside this method, given the comment and its name. I wonder if `print_tracing_info` can be used instead, which is invoked before exit as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2161728711

From duke at openjdk.org  Mon Jun 23 14:19:32 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 23 Jun 2025 14:19:32 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v9]
In-Reply-To: <BgaYTXMTce7LBJAfqnll72hjJcuPmWZoSX6_aTXVLJM=.e1b38e72-51b6-4a87-97cd-e01d315050d3@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <YLer4W0t8eLT5pUta2WCFfVYCdq7DwswRRFKwsUf0wo=.d4e61f23-d3fa-4523-b2e6-2575d1fb9cbd@github.com>
 <BgaYTXMTce7LBJAfqnll72hjJcuPmWZoSX6_aTXVLJM=.e1b38e72-51b6-4a87-97cd-e01d315050d3@github.com>
Message-ID: <a3IxFvi_7KvwpMj86lxXp2iQFIRAHuINx4AK63kGGlA=.1a7c5dd9-7956-4da3-9a2e-fe860695fa4f@github.com>

On Mon, 23 Jun 2025 14:07:56 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Remove incorrect is_gc_operation call after rebase
>>  - More clean up, remove virtual
>>  - Fixes after feedback from @stefank
>>  - Remove extra whitespace
>>  - operation_is_gc -> is_gc_operation per @stefank suggestion
>>  - Only sample if needed
>>  - Remove explicit super call and minor fixes
>>  - Add CPU time tracking for string deduplication to log_gc_vtime
>>  - Replace calls to log_gc_vtime with super-class method calls
>>  - Add bug fix after refactor and fixes for review
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/c748d358...553edc48
>
> src/hotspot/share/gc/shared/collectedHeap.hpp line 245:
> 
>> 243: 
>> 244:   // Stop any onging concurrent work and prepare for exit.
>> 245:   virtual void stop();
> 
> I find it a bit odd to call `log_gc_vtime` inside this method, given the comment and its name. I wonder if `print_tracing_info` can be used instead, which is invoked before exit as well.

I think it makes sense. We want to log the total GC CPU time before exiting. The latest point we can do that is right before we terminate threads, which we do in when we call `ConcurrentGCThread::stop`. I am open for any suggestions to rename `log_gc_vtime` in case that would help.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2161749278

From kbarrett at openjdk.org  Mon Jun 23 15:29:29 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 23 Jun 2025 15:29:29 GMT
Subject: RFR: 8360177: ParallelArguments::initialize has incorrect format
 string
In-Reply-To: <VfNdPbVJzksaE_EoAoHcFR3s0xHhVLR2dPkMp22LUT4=.c48fcdf9-84d8-402c-8d29-77ed285eac8e@github.com>
References: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
 <VfNdPbVJzksaE_EoAoHcFR3s0xHhVLR2dPkMp22LUT4=.c48fcdf9-84d8-402c-8d29-77ed285eac8e@github.com>
Message-ID: <CTUt0j8nr-6le8WWxODUXnjJdX32G5z5zYsUDyWbwCA=.ab6c61c0-3e0a-44d7-8ed2-2c2fe4c91b97@github.com>

On Mon, 23 Jun 2025 07:07:34 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this trivial fix to a jio_fprintf format string. It should be using
>> "%zu" to print values of type uintx, rather than using "%d".
>> 
>> Testing: mach5 tier1
>> Locally tested with gcc printf warnings enabled for jio_fprintf, and verified
>> the warnings for the changed call are no longer present.
>
> src/hotspot/share/gc/parallel/parallelArguments.cpp line 73:
> 
>> 71:       if (FLAG_IS_CMDLINE(MinSurvivorRatio)) {
>> 72:         jio_fprintf(defaultStream::error_stream(),
>> 73:           "Inconsistent MinSurvivorRatio vs InitialSurvivorRatio: %zu vs %zu\n", MinSurvivorRatio, InitialSurvivorRatio);
> 
> Should probably use `UINTX_FORMAT` instead.

Nope: https://bugs.openjdk.org/browse/JDK-8346990 Remove INTX_FORMAT and UINTX_FORMAT macros

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25926#discussion_r2161899640

From stefank at openjdk.org  Mon Jun 23 19:00:39 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 23 Jun 2025 19:00:39 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v9]
In-Reply-To: <a3IxFvi_7KvwpMj86lxXp2iQFIRAHuINx4AK63kGGlA=.1a7c5dd9-7956-4da3-9a2e-fe860695fa4f@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <YLer4W0t8eLT5pUta2WCFfVYCdq7DwswRRFKwsUf0wo=.d4e61f23-d3fa-4523-b2e6-2575d1fb9cbd@github.com>
 <BgaYTXMTce7LBJAfqnll72hjJcuPmWZoSX6_aTXVLJM=.e1b38e72-51b6-4a87-97cd-e01d315050d3@github.com>
 <a3IxFvi_7KvwpMj86lxXp2iQFIRAHuINx4AK63kGGlA=.1a7c5dd9-7956-4da3-9a2e-fe860695fa4f@github.com>
Message-ID: <_FhdGlOiiWqN_Jpx_7kJZgamyXtgQTUw54t1w38SjxY=.609da7e0-39f9-4525-9836-b56a71c488f6@github.com>

On Mon, 23 Jun 2025 14:17:05 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/collectedHeap.hpp line 245:
>> 
>>> 243: 
>>> 244:   // Stop any onging concurrent work and prepare for exit.
>>> 245:   virtual void stop();
>> 
>> I find it a bit odd to call `log_gc_vtime` inside this method, given the comment and its name. I wonder if `print_tracing_info` can be used instead, which is invoked before exit as well.
>
> I think it makes sense. We want to log the total GC CPU time before exiting. The latest point we can do that is right before we terminate threads, which we do in when we call `ConcurrentGCThread::stop`. I am open for any suggestions to rename `log_gc_vtime` in case that would help.

I'd also prefer to see a small adjustment here. With this change all GCs have to add a back call to `CollectedHeap::stop()`. I think it makes the could a tiny bit less clean.

I wonder if an alternative could be to split `CollectedHeap::stop()` into two functions:

virtual void CollectedHeap::stop() = 0; // Now pure virtual

void CollectedHeap::before_exit() {
  // Log GC CPU usage.
  log_gc_vtime();

  // Stop any on-going concurrent work and prepare for exit.
  stop();
}

And revert the added calls to `CollectedHeap::stop()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2162341225

From dlong at openjdk.org  Mon Jun 23 19:12:29 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 23 Jun 2025 19:12:29 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <gQcwrLo4ooSL418-Tl7D_KgnmVMPZ5HdJNJHm8OCFA4=.b3afd47c-2c8b-4bce-a8d1-e0b6c30c694d@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
 <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
 <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>
 <S_WVqyvsvxDSez9c0syZRE2cr8kQ1yeSOs9w4zBEWAY=.23eec805-97e0-4982-8417-6f0114646fbb@github.com>
 <NDd13XSxcbkLkY1hPDt7hlRUAo_3zlHikMaBpAHy8po=.c399c3e1-df5e-4ea8-a667-68d12bac991a@github.com>
 <gQcwrLo4ooSL418-Tl7D_KgnmVMPZ5HdJNJHm8OCFA4=.b3afd47c-2c8b-4bce-a8d1-e0b6c30c694d@github.com>
Message-ID: <D6_zZm9npWxvfzJaGvqx7z043mGU7Qn-Bfx2aO-soGo=.e7c05ee6-f929-44b4-a2a3-7fbfb201a24b@github.com>

On Mon, 23 Jun 2025 12:47:07 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> I think making it less slippery in one place but still leaving other races gives a false sense of security and makes the code harder to understand.  Arming the barrier is not guaranteed to be visible until there is a safepoint.  Note that AArch64 and RISCV only call increment_patching_epoch() when the guard value is set to the disarmed value, so there is no invalidation of the CPU pipeline or instruction buffer (cross modification fence) when arming.
>
> Okay. I would have preferred to not enter the nmethod when we evaluate the guard bits under the lock that protects it and see that it's supposed to be not entrant. But I won't argue for it further if you prefer not to change that. Other than that, I think this looks good.

I think it's OK if there is a race to have a point of no return, and if one thread gets there first, it wins, and we don't need to check again.  It's tempting to want to do an extra check when we disarm under the lock, but then it would need a comment explaining why we do it, even though the make_not_entrant could come in right after and we would miss it.  And we have already done the work of healing the oops by this point.  Finally, I like the encapsulation that only nmethod_stub_entry_barrier needs to know about not_entrant, and nmethod_entry_barrier doesn't need to know.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2162359865

From dlong at openjdk.org  Mon Jun 23 19:18:31 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 23 Jun 2025 19:18:31 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v8]
In-Reply-To: <aqutosiSmqM1u3TePxEPFdPkM0Apd1XfjY7WXEssO-0=.83eb647e-114f-4b4f-b0f1-d2d89e16a426@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <2gdPUDg-i40xRoO8LZPWszL2-oa6s7GNZEDRfHfDk8s=.4dbfe74a-070b-46c1-b73d-0292824d02e9@github.com>
 <aqutosiSmqM1u3TePxEPFdPkM0Apd1XfjY7WXEssO-0=.83eb647e-114f-4b4f-b0f1-d2d89e16a426@github.com>
Message-ID: <hKRq-y4_rBNb8hxj2UJeN6OEnVUPe7Zft72I5UbhSNQ=.2210767d-3063-4263-9786-5cfb1341a80e@github.com>

On Fri, 20 Jun 2025 08:58:39 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Dean Long has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   2nd try at arm fix
>
>> > Tests look good on our side. I'm only a bit concerned that the lock may become a bottleneck when many Java threads need to patch all nmethods. Especially with ZGC which does that more often. I think we should check performance.
>> 
>> For ZGC I am using a per-nmethod lock: ZLocker locker(ZNMethod::lock_for_nmethod(nm));
> 
> Ah, right. So, ZGC should be fine.
> 
>> I don't know what benchmarks to run to check the performance for functions like Deoptimization::deoptimize_all_marked, so I welcome any help with this.
> 
> I have tried some SPEC benchmarks with G1 on PPC64, but couldn't observe a regression. (If there is one, it was below noise.)
>  
>> One possible optimization that might help is skipping the lock if the make_not_entrant call is done during a safepoint.
> 
> I guess the most critical scenario is when many Java threads need to disarm a large number of nmethod entry barriers. That doesn't happen at a safepoint. Not sure if other scenarios are worth optimizing by this idea.
> 
> I guess this PR is ok as it is. Maybe other reviewers have more comments.

@TheRealMDoerr @fisk @offamitkumar 
Thanks again everyone for the reviews and contributions.  I think this is ready to integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2997672327

From dlong at openjdk.org  Mon Jun 23 19:26:11 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 23 Jun 2025 19:26:11 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into 8358821-patch-verified-entry
 - 2nd try at arm fix
 - rename arm_with to guard_with
 - arm32 fix
 - s390 fix courtesy of Amit Kumar
 - remove is_sigill_not_entrant
 - more cleanup
 - more TheRealMDoerr suggestions
 - TheRealMDoerr suggestions
 - remove trailing space
 - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

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

Changes: https://git.openjdk.org/jdk/pull/25764/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25764&range=08
  Stats: 603 lines in 43 files changed: 97 ins; 459 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/25764.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25764/head:pull/25764

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

From mdoerr at openjdk.org  Mon Jun 23 19:26:11 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 23 Jun 2025 19:26:11 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
Message-ID: <3NeAP1nLxZGaY1zq8RfpkCy3L3KYXNyjN6Eg1vS1DRE=.e43394f9-33f6-48af-937c-48062b6b8125@github.com>

On Mon, 23 Jun 2025 19:22:45 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8358821-patch-verified-entry
>  - 2nd try at arm fix
>  - rename arm_with to guard_with
>  - arm32 fix
>  - s390 fix courtesy of Amit Kumar
>  - remove is_sigill_not_entrant
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2951288332

From tschatzl at openjdk.org  Mon Jun 23 19:44:32 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 23 Jun 2025 19:44:32 GMT
Subject: RFR: 8360177: ParallelArguments::initialize has incorrect format
 string
In-Reply-To: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
References: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
Message-ID: <NeNBT_fXqvIPjj0V2etdR6INmdnhA-tpn-O9AWS_rxU=.1ff3631e-b657-45f1-a1eb-433f8ed4a771@github.com>

On Mon, 23 Jun 2025 01:30:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial fix to a jio_fprintf format string. It should be using
> "%zu" to print values of type uintx, rather than using "%d".
> 
> Testing: mach5 tier1
> Locally tested with gcc printf warnings enabled for jio_fprintf, and verified
> the warnings for the changed call are no longer present.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25926#pullrequestreview-2951338529

From sangheki at openjdk.org  Mon Jun 23 19:58:28 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Mon, 23 Jun 2025 19:58:28 GMT
Subject: RFR: 8360177: ParallelArguments::initialize has incorrect format
 string
In-Reply-To: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
References: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
Message-ID: <apqAtQux7pdmM2pd09xDEmGE1a6oIsZMliQmhXbfS5w=.f1e2bcc5-628c-46f9-bd55-632e7e233b77@github.com>

On Mon, 23 Jun 2025 01:30:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial fix to a jio_fprintf format string. It should be using
> "%zu" to print values of type uintx, rather than using "%d".
> 
> Testing: mach5 tier1
> Locally tested with gcc printf warnings enabled for jio_fprintf, and verified
> the warnings for the changed call are no longer present.

LGTM

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

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25926#pullrequestreview-2951369176

From wkemper at openjdk.org  Mon Jun 23 21:05:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 23 Jun 2025 21:05:35 GMT
Subject: [jdk25] Integrated: 8357550: GenShen crashes during freeze:
 assert(!chunk->requires_barriers()) failed
In-Reply-To: <jlxaobHjXlpe6zIyAXP9WwORonEeiHSudYjZ4-UUHQs=.650abd09-64a2-47f7-9b40-f79f17e0dceb@github.com>
References: <jlxaobHjXlpe6zIyAXP9WwORonEeiHSudYjZ4-UUHQs=.650abd09-64a2-47f7-9b40-f79f17e0dceb@github.com>
Message-ID: <uomurXb6rlRh_QYw7KltPI-udyCaETQ9UtTAeN74Jj4=.01801a84-21bd-4d6c-835a-0c14c33f77df@github.com>

On Fri, 20 Jun 2025 18:48:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a low risk change that addresses an assertion failure when Shenandoah's generational mode is used with virtual threads.

This pull request has now been integrated.

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

8357550: GenShen crashes during freeze: assert(!chunk->requires_barriers()) failed

Reviewed-by: shade
Backport-of: 17cf49746d0c289bdf779c974cdc84a3ab32ab4b

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

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

From fyang at openjdk.org  Tue Jun 24 03:24:38 2025
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 24 Jun 2025 03:24:38 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
Message-ID: <lepaOQS2Lr_TCf8YBIZemOrEsHSDAy4WZeg5WYiv5q0=.a0e322d0-d854-4d41-ae06-2eba9fd59e51@github.com>

On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8358821-patch-verified-entry
>  - 2nd try at arm fix
>  - rename arm_with to guard_with
>  - arm32 fix
>  - s390 fix courtesy of Amit Kumar
>  - remove is_sigill_not_entrant
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

Just FYI: My local tier1-3 test on linux-riscv64 is good. And I didn't witness an obvious change on specjbb performance with g1gc.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-2998661809

From ayang at openjdk.org  Tue Jun 24 07:37:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 24 Jun 2025 07:37:34 GMT
Subject: RFR: 8360220: Deprecate and obsolete
 ParallelRefProcBalancingEnabled
In-Reply-To: <AZ1eqJ9Vnat7cWLTlQ3Z2PzGBTk5S5XqjqMYX10nb6Q=.1e4d6765-fade-436f-8e55-0b11b3e6463d@github.com>
References: <AZ1eqJ9Vnat7cWLTlQ3Z2PzGBTk5S5XqjqMYX10nb6Q=.1e4d6765-fade-436f-8e55-0b11b3e6463d@github.com>
Message-ID: <NtPQB_dMr2OTDq6gswC2m3uIG-D0Ueh_RFMRuv5WSao=.56f6a2b8-2591-4c8e-ada1-d76f10524098@github.com>

On Mon, 23 Jun 2025 09:14:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `ParallelRefProcBalancingEnabled`, which is used only by Parallel and G1, and both have it enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number commandline flags.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25932#issuecomment-2999161923

From ayang at openjdk.org  Tue Jun 24 07:37:35 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 24 Jun 2025 07:37:35 GMT
Subject: Integrated: 8360220: Deprecate and obsolete
 ParallelRefProcBalancingEnabled
In-Reply-To: <AZ1eqJ9Vnat7cWLTlQ3Z2PzGBTk5S5XqjqMYX10nb6Q=.1e4d6765-fade-436f-8e55-0b11b3e6463d@github.com>
References: <AZ1eqJ9Vnat7cWLTlQ3Z2PzGBTk5S5XqjqMYX10nb6Q=.1e4d6765-fade-436f-8e55-0b11b3e6463d@github.com>
Message-ID: <S5ZvCw9W8bgihDy9I3OiYnPzZArdJ-y_BNY9SjP74us=.332c3913-e464-48bc-bc20-c24082c4cbe7@github.com>

On Mon, 23 Jun 2025 09:14:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `ParallelRefProcBalancingEnabled`, which is used only by Parallel and G1, and both have it enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number commandline flags.

This pull request has now been integrated.

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

8360220: Deprecate and obsolete ParallelRefProcBalancingEnabled

Reviewed-by: kbarrett, tschatzl

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

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

From ayang at openjdk.org  Tue Jun 24 07:40:07 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 24 Jun 2025 07:40:07 GMT
Subject: RFR: 8360324: Parallel: Remove unused local variable in
 MutableNUMASpace::set_top
Message-ID: <uUfo8MO3bUAjHEBRYM0QRHIBJK8mfReBGpBQHU1Ihkk=.579fc1e7-6205-42a0-9e0e-48b10878b024@github.com>

Trivial removing dead code.

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

Commit messages:
 - pgc-trivial

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

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

From ayang at openjdk.org  Tue Jun 24 07:45:15 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 24 Jun 2025 07:45:15 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v2]
In-Reply-To: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
Message-ID: <OlrGflKYJyNoMEDjx4b64QoZ57KCIe-70KqrJjSl29w=.0536c301-9441-4038-b5ae-bec57c248eb9@github.com>

> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
> 
> 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 two additional commits since the last revision:

 - Merge branch 'master' into ref-refactor
 - ref-refactor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25930/files
  - new: https://git.openjdk.org/jdk/pull/25930/files/86b2df4a..3216b6ea

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

  Stats: 1713 lines in 107 files changed: 241 ins; 369 del; 1103 mod
  Patch: https://git.openjdk.org/jdk/pull/25930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25930/head:pull/25930

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

From tschatzl at openjdk.org  Tue Jun 24 07:45:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 24 Jun 2025 07:45:28 GMT
Subject: RFR: 8360324: Parallel: Remove unused local variable in
 MutableNUMASpace::set_top
In-Reply-To: <uUfo8MO3bUAjHEBRYM0QRHIBJK8mfReBGpBQHU1Ihkk=.579fc1e7-6205-42a0-9e0e-48b10878b024@github.com>
References: <uUfo8MO3bUAjHEBRYM0QRHIBJK8mfReBGpBQHU1Ihkk=.579fc1e7-6205-42a0-9e0e-48b10878b024@github.com>
Message-ID: <fgwtY_Ufcx7u-ROuCUSI6i8nHLhZVlz0qzJPOYmoQz8=.34c1490a-ef6e-4c13-b569-2d52cfa2c4c4@github.com>

On Tue, 24 Jun 2025 07:35:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25949#pullrequestreview-2952542726

From tschatzl at openjdk.org  Tue Jun 24 08:39:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 24 Jun 2025 08:39:31 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v4]
In-Reply-To: <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
Message-ID: <Y7yqwdaPDszbM3hG1Yk9lbT1WzQYqMfuGXF8Ixelgb4=.c0379e08-69b3-401f-b269-ee93e4ea4cbd@github.com>

On Thu, 19 Jun 2025 12:26:15 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert suggestions

Some typos

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 410:

> 408:   // with respect to the heap max size as it's an upper bound (i.e.,
> 409:   // we'll try to make the capacity smaller than it, not greater).
> 410:   maximum_desired_capacity =  MAX2(maximum_desired_capacity, _g1h->min_capacity());

Suggestion:

  maximum_desired_capacity = MAX2(maximum_desired_capacity, _g1h->min_capacity());

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 39:

> 37: // For young collections, this heuristics is based on gc time ratio, i.e. trying
> 38: // to change the heap so that current gc time ratio stays approximately as
> 39: // selected  by the user.

Suggestion:

// selected by the user.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 44:

> 42: // change.
> 43: //
> 44: // Short term tracking is based on the short-term gc time ratio i.e we  count

Suggestion:

// Short term tracking is based on the short-term gc time ratio i.e we count

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 65:

> 63: // Long term behavior is solely managed by regularly comparing actual long term gc
> 64: // time ratio with the boundaries of above range in regular long term  intervals.
> 65: // If current long term gc time ratio is outside, expand or shrink  respectively.

Suggestion:

// time ratio with the boundaries of above range in regular long term intervals.
// If current long term gc time ratio is outside, expand or shrink respectively.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 79:

> 77:   uint long_term_count_limit() const;
> 78:   // Number of times short-term gc time ratio crossed the lower or upper threshold
> 79:   // recently; every time the upper threshold is exceeded, it is incremented,  and

Suggestion:

  // recently; every time the upper threshold is exceeded, it is incremented, and

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25832#pullrequestreview-2952720651
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2163309395
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2163311368
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2163300891
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2163310414
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2163309782

From sroy at openjdk.org  Tue Jun 24 08:48:45 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 24 Jun 2025 08:48:45 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v7]
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <iRyU5PaJjVJoQIdxbkQsuQAAqCVBztSM0rMFKxpwZUs=.10e52bbe-f8e5-42c8-b47f-9365d10c5833@github.com>

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

   Zgneeration class redundant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25833/files
  - new: https://git.openjdk.org/jdk/pull/25833/files/7bb69a1d..eacbfcdd

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

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

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

From tschatzl at openjdk.org  Tue Jun 24 08:57:31 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 24 Jun 2025 08:57:31 GMT
Subject: RFR: 8350621: Code cache stops scheduling GC
In-Reply-To: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
References: <V0gBSNaaWma0aEZWcPBcpxcsQogzT4yyO9rgVxGTqTQ=.67475f3a-3d2c-4bfb-8650-5af6a18421cd@github.com>
Message-ID: <tbgVTlCFP93HyQ5PvIJyGAT9dY8qoJ8Jw3gcygYF7dI=.e3de1896-e3db-466d-a420-79b602917a66@github.com>

On Sun, 16 Feb 2025 18:39:29 GMT, Alexandre Jacob <duke at openjdk.org> wrote:

> The purpose of this PR is to fix a bug where we can end up in a situation where the GC is not scheduled anymore by `CodeCache`.
> 
> This situation is possible because the `_unloading_threshold_gc_requested` flag is set to `true` when triggering the GC and we expect the GC to call `CodeCache::on_gc_marking_cycle_finish` which in turn will call `CodeCache::update_cold_gc_count`, which will reset the flag `_unloading_threshold_gc_requested` allowing further GC scheduling.
> 
> Unfortunately this can't work properly under certain circumstances.
> For example, if using G1GC, calling `G1CollectedHeap::collect` does no give the guarantee that the GC will actually run as it can be already running (see [here](https://github.com/openjdk/jdk/blob/7d11418c820b46926a25907766d16083a4b349de/src/hotspot/share/gc/g1/g1CollectedHeap.cpp#L1763)).
> 
> I have observed this behavior on JVM in version 21 that were migrated recently from java 17.
> Those JVMs have some pressure on code cache and quite a large heap in comparison to allocation rate, which means that objects are mostly GC'd by young collections and full GC take a long time to happen.
> 
> I have been able to reproduce this issue with ParallelGC and G1GC, and I imagine that other GC can be impacted as well.
> 
> In order to reproduce this issue, I found a very simple and convenient way:
> 
> 
> public class CodeCacheMain {
>     public static void main(String[] args) throws InterruptedException {
>         while (true) {
>             Thread.sleep(100);
>         }
>     }
> }
> 
> 
> Run this simple app with the following JVM flags:
> 
> 
> -Xlog:gc*=info,codecache=info -Xmx512m -XX:ReservedCodeCacheSize=2496k -XX:StartAggressiveSweepingAt=15
> 
> 
> - 512m for the heap just to clarify the intent that we don't want to be bothered by a full GC
> - low `ReservedCodeCacheSize` to put pressure on code cache quickly
> - `StartAggressiveSweepingAt` can be set to 20 or 15 for faster bug reproduction
> 
> Itself, the program will hardly get pressure on code cache, but the good news is that it is sufficient to attach a jconsole on it which will:
> - allows us to monitor code cache
> - indirectly generate activity on the code cache, just what we need to reproduce the bug
> 
> Some logs related to code cache will show up at some point with GC activity:
> 
> 
> [648.733s][info][codecache      ] Triggering aggressive GC due to having only 14.970% free memory
> 
> 
> And then it will stop and we'll end up with the following message:
> 
> 
> [672.714s][info][codecache      ] Code cache is full - disabling compilation
> 
> 
> L...

> Why making sure only one thread calls `collect(...)`? I believe this API can be invoked concurrently.



> I have a question regarding the existing code/logic.
> 
> ```
>     // In case the GC is concurrent, we make sure only one thread requests the GC.
>     if (Atomic::cmpxchg(&_unloading_threshold_gc_requested, false, true) == false) {
>       log_info(codecache)("Triggering aggressive GC due to having only %.3f%% free memory", free_ratio * 100.0);
>       Universe::heap()->collect(GCCause::_codecache_GC_aggressive);
>     }
> ```
> 
> Why making sure only one thread calls `collect(...)`? I believe this API can be invoked concurrently.
> 
> Would removing `_unloading_threshold_gc_requested` resolve this problem?

It does, at the cost of many log messages:


[0.047s][info][gc          ] GC(0) Pause Young (Concurrent Start) (CodeCache GC Threshold) 2M->1M(512M) 4.087ms
[0.047s][info][gc,cpu      ] GC(0) User=0.01s Sys=0.00s Real=0.00s
[0.047s][info][gc          ] GC(1) Concurrent Mark Cycle
[0.047s][info][gc,marking  ] GC(1) Concurrent Scan Root Regions
[0.048s][info][codecache   ] Triggering threshold (7.654%) GC due to allocating 48.973% since last unloading (0.000% used -> 48.973% used)
[0.048s][info][gc,marking  ] GC(1) Concurrent Scan Root Regions 0.147ms
[0.048s][info][gc,marking  ] GC(1) Concurrent Mark
[0.048s][info][gc,marking  ] GC(1) Concurrent Mark From Roots
[0.048s][info][codecache   ] Triggering threshold (7.646%) GC due to allocating 49.028% since last unloading (0.000% used -> 49.028% used)
[0.048s][info][codecache   ] Triggering threshold (7.646%) GC due to allocating 49.028% since last unloading (0.000% used -> 49.028% used)
[0.048s][info][codecache   ] Triggering threshold (7.633%) GC due to allocating 49.114% since last unloading (0.000% used -> 49.114% used)
[0.049s][info][gc,task     ] GC(1) Using 6 workers of 6 for marking
[0.049s][info][codecache   ] Triggering threshold (7.625%) GC due to allocating 49.169% since last unloading (0.000% used -> 49.169% used)
[0.049s][info][codecache   ] Triggering threshold (7.616%) GC due to allocating 49.224% since last unloading (0.000% used -> 49.224% used)

[...repeated 15 times...]

[0.063s][info][codecache   ] Triggering threshold (7.527%) GC due to allocating 49.820% since last unloading (0.000% used -> 49.820% used)
[0.065s][info][codecache   ] Triggering threshold (7.519%) GC due to allocating 49.875% since last unloading (0.000% used -> 49.875% used)
[0.067s][info][codecache   ] Triggering threshold (7.511%) GC due to allocating 49.930% since last unloading (0.000% used -> 49.930% used)
[0.068s][info][gc,marking  ] GC(1) Concurrent Mark From Roots 20.256ms
[0.068s][info][gc,marking  ] GC(1) Concurrent Preclean
[0.068s][info][gc,marking  ] GC(1) Concurrent Preclean 0.016ms
[0.068s][info][gc,start    ] GC(1) Pause Remark



As you can see this is very annoying, particularly if the marking takes seconds all the while compiling is in progress.

> 
> > I have been able to reproduce this issue with ParallelGC and G1GC, and I imagine that other GC can be impacted as well.
> 
> For ParallelGC, `ParallelScavengeHeap::collect` contains the following to ensure `System.gc` gccause and similar ones guarantee a full-gc.
> 
> ```
>     if (!GCCause::is_explicit_full_gc(cause)) {
>       return;
>     }
> ```
> 
> However, the current logic that a young-gc can cancel a full-gc (`_codecache_GC_aggressive` in this case) also seems surprising.

That's a different issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/23656#issuecomment-2999414442

From ayang at openjdk.org  Tue Jun 24 10:37:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 24 Jun 2025 10:37:37 GMT
Subject: RFR: 8360324: Parallel: Remove unused local variable in
 MutableNUMASpace::set_top
In-Reply-To: <uUfo8MO3bUAjHEBRYM0QRHIBJK8mfReBGpBQHU1Ihkk=.579fc1e7-6205-42a0-9e0e-48b10878b024@github.com>
References: <uUfo8MO3bUAjHEBRYM0QRHIBJK8mfReBGpBQHU1Ihkk=.579fc1e7-6205-42a0-9e0e-48b10878b024@github.com>
Message-ID: <ghxtPUS3-AblvkytFRTlZFbYZfKNqBPg1a95_-lvur8=.e770c362-ca68-4e64-b106-048e16d427de@github.com>

On Tue, 24 Jun 2025 07:35:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25949#issuecomment-2999736547

From ayang at openjdk.org  Tue Jun 24 10:37:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 24 Jun 2025 10:37:37 GMT
Subject: Integrated: 8360324: Parallel: Remove unused local variable in
 MutableNUMASpace::set_top
In-Reply-To: <uUfo8MO3bUAjHEBRYM0QRHIBJK8mfReBGpBQHU1Ihkk=.579fc1e7-6205-42a0-9e0e-48b10878b024@github.com>
References: <uUfo8MO3bUAjHEBRYM0QRHIBJK8mfReBGpBQHU1Ihkk=.579fc1e7-6205-42a0-9e0e-48b10878b024@github.com>
Message-ID: <3bL55EI3zp09h0sX28G-kJb_FhXwHVorTtukAV8dU5A=.8856f6bc-87fe-4699-8d17-40b398ad1c9e@github.com>

On Tue, 24 Jun 2025 07:35:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

This pull request has now been integrated.

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

8360324: Parallel: Remove unused local variable in MutableNUMASpace::set_top

Reviewed-by: tschatzl

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

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

From sroy at openjdk.org  Tue Jun 24 12:08:35 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 24 Jun 2025 12:08:35 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v3]
In-Reply-To: <nybLTpuZlfjZf0XUi9MTIJYCfbGrBmfRrS-Lg6ezhIc=.5cd475ea-1863-40d7-9977-b678f0c32fed@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <EGGN6OK2qYZDyxnbli5JzPnQZS7Pp4kxxk6RARdK4RY=.0c15fe00-ee38-4e74-9d1c-6813a0e8e57b@github.com>
 <nybLTpuZlfjZf0XUi9MTIJYCfbGrBmfRrS-Lg6ezhIc=.5cd475ea-1863-40d7-9977-b678f0c32fed@github.com>
Message-ID: <JXeVGylP4OmmcF1QKegjNGCRwvXprq5bMZpoag7Rl2s=.8b899099-3405-4575-ae33-79ce03403fbd@github.com>

On Tue, 17 Jun 2025 08:24:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update capacity only for Generation counter
>>  - Revert "update_capacity exists"
>>    
>>    This reverts commit cf2d66d598d90f1343d1ad7a4f30607c3374a0f8.
>
> Thanks for the revision.
> 
> I believe the one in `ZGenerationCounters` can be removed now.
> 
> 
>   void update_capacity(size_t capacity) {
>     update_all(capacity);
>   }

@albertnetymk @stefank  is the windows failures occurring on every PR today ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25833#issuecomment-3000079045

From sroy at openjdk.org  Tue Jun 24 13:32:04 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 24 Jun 2025 13:32:04 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v8]
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <KS1dwV7KFqChPy-INB8g2KC4cNPf3k-X2iyLTqARur0=.02863109-26f6-4859-b906-59646f4eab11@github.com>

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Suchismith Roy 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:

 - Merge branch 'openjdk:master' into update_memory_state
 -  Zgneeration class redundant
 - g1Monitoring
 - update zgenerationcounter
 - psOldGen
 - update capacity only for Generation counter
 - Revert "update_capacity exists"
   
   This reverts commit cf2d66d598d90f1343d1ad7a4f30607c3374a0f8.
 - Merge branch 'openjdk:master' into update_memory_state
 - update_capacity exists

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25833/files
  - new: https://git.openjdk.org/jdk/pull/25833/files/eacbfcdd..f8ea505a

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

  Stats: 10816 lines in 386 files changed: 3759 ins; 4545 del; 2512 mod
  Patch: https://git.openjdk.org/jdk/pull/25833.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25833/head:pull/25833

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

From kbarrett at openjdk.org  Tue Jun 24 14:32:33 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Jun 2025 14:32:33 GMT
Subject: RFR: 8360177: ParallelArguments::initialize has incorrect format
 string
In-Reply-To: <NeNBT_fXqvIPjj0V2etdR6INmdnhA-tpn-O9AWS_rxU=.1ff3631e-b657-45f1-a1eb-433f8ed4a771@github.com>
References: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
 <NeNBT_fXqvIPjj0V2etdR6INmdnhA-tpn-O9AWS_rxU=.1ff3631e-b657-45f1-a1eb-433f8ed4a771@github.com>
Message-ID: <5PK1NDOQYVSS9_hBR-WeaYwHVwYtlABLhsH9q65kntY=.e08b9e6d-eddd-413e-b32e-b3d8eb066a28@github.com>

On Mon, 23 Jun 2025 19:41:31 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Please review this trivial fix to a jio_fprintf format string. It should be using
>> "%zu" to print values of type uintx, rather than using "%d".
>> 
>> Testing: mach5 tier1
>> Locally tested with gcc printf warnings enabled for jio_fprintf, and verified
>> the warnings for the changed call are no longer present.
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks for reviews @tschatzl and @sangheon

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

PR Comment: https://git.openjdk.org/jdk/pull/25926#issuecomment-3000725568

From kbarrett at openjdk.org  Tue Jun 24 14:32:33 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 24 Jun 2025 14:32:33 GMT
Subject: Integrated: 8360177: ParallelArguments::initialize has incorrect
 format string
In-Reply-To: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
References: <bqQC_2_YFSEeQBKXnB1MS5fONzLWwCrVClg38zAypKw=.daba2b60-4452-4572-9464-fc4d9059f68d@github.com>
Message-ID: <Eyqfmas3ZKAH_fO02QY8sCPB8wZaxmPNDLWmwdHfiR0=.1541ea24-a864-43db-b077-ac60568b2bbd@github.com>

On Mon, 23 Jun 2025 01:30:27 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this trivial fix to a jio_fprintf format string. It should be using
> "%zu" to print values of type uintx, rather than using "%d".
> 
> Testing: mach5 tier1
> Locally tested with gcc printf warnings enabled for jio_fprintf, and verified
> the warnings for the changed call are no longer present.

This pull request has now been integrated.

Changeset: 0514cee6
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0514cee6c884b6d31735551b8a3ce7a2be661094
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8360177: ParallelArguments::initialize has incorrect format string

Reviewed-by: tschatzl, sangheki

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

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

From tschatzl at openjdk.org  Tue Jun 24 15:52:32 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 24 Jun 2025 15:52:32 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v4]
In-Reply-To: <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
Message-ID: <npwkziB2ttDtCWWZCIAUFf1ZgJy03zgXDmpwRYkMNLw=.8888c59c-8fe1-4bbf-ae37-25e3179eb942@github.com>

On Thu, 19 Jun 2025 12:26:15 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert suggestions

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 231:

> 229:   const double min_gc_time_ratio_ratio = G1MinimumPercentOfGCTimeRatio / 100.0;
> 230:   double upper_threshold = pause_time_threshold * (1 + min_gc_time_ratio_ratio);
> 231:   double lower_threshold = pause_time_threshold * (1 - min_gc_time_ratio_ratio);

There are some inconsistencies naming variables in this change: we use `pause_time_threshold`, `pause_time_ratio` and other similar terms that are under(de)fined for, essentially, (parts of) the cpu resources that G1 uses.

Also some things are called "ratio", but are percentages (e.g. `G1MinimumPercentOfGCTimeRatio`), and the comments somewhat interchangeably use cpu usage (in percent) and gctimeratio (the inverse of cpu usage).

I think it is useful to clean this up, also looking forward to making G1 start using actual GC CPU usage (thread user times), e.g.


pause_time_threshold -> gc_cpu_usage_threshold
long_term_pause_time_ratio -> long_term_cpu_usage
[and so on]


I admit that right now `cpu_usage` might be slightly misleading because we only approximate it using pause times and total run times (which do not necessarily reflect actual cpu usage), but it seems good enough for now, and future changes (https://bugs.openjdk.org/browse/JDK-8359348; even with that we might need to fallback to current mechanism).

What do others think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2164372113

From dlong at openjdk.org  Tue Jun 24 16:16:36 2025
From: dlong at openjdk.org (Dean Long)
Date: Tue, 24 Jun 2025 16:16:36 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <lepaOQS2Lr_TCf8YBIZemOrEsHSDAy4WZeg5WYiv5q0=.a0e322d0-d854-4d41-ae06-2eba9fd59e51@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
 <lepaOQS2Lr_TCf8YBIZemOrEsHSDAy4WZeg5WYiv5q0=.a0e322d0-d854-4d41-ae06-2eba9fd59e51@github.com>
Message-ID: <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com>

On Tue, 24 Jun 2025 03:21:39 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into 8358821-patch-verified-entry
>>  - 2nd try at arm fix
>>  - rename arm_with to guard_with
>>  - arm32 fix
>>  - s390 fix courtesy of Amit Kumar
>>  - remove is_sigill_not_entrant
>>  - more cleanup
>>  - more TheRealMDoerr suggestions
>>  - TheRealMDoerr suggestions
>>  - remove trailing space
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c
>
> Just FYI: My local tier1-3 test on linux-riscv64 is good. And I didn't witness an obvious change on specjbb performance with g1gc.

Thanks @RealFYang.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3001102616

From eosterlund at openjdk.org  Tue Jun 24 16:43:35 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 24 Jun 2025 16:43:35 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
Message-ID: <zVm5usg9eP8Ki-aPQrsmwCwIUkGvBFxqHiDW3lhdGtY=.12381dc7-1437-4228-a149-e2a398459d38@github.com>

On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8358821-patch-verified-entry
>  - 2nd try at arm fix
>  - rename arm_with to guard_with
>  - arm32 fix
>  - s390 fix courtesy of Amit Kumar
>  - remove is_sigill_not_entrant
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25764#pullrequestreview-2954594316

From eosterlund at openjdk.org  Tue Jun 24 16:43:35 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 24 Jun 2025 16:43:35 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v4]
In-Reply-To: <D6_zZm9npWxvfzJaGvqx7z043mGU7Qn-Bfx2aO-soGo=.e7c05ee6-f929-44b4-a2a3-7fbfb201a24b@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <QZevAMdLIuBAlx9cyx8w7hUSk6Txz5Mo6C63gQur6pc=.86a4ee03-5665-4f42-bedb-1bee8037ddfe@github.com>
 <ENAa5ub1BOWT5p9ag_BQ4j8NYmjODwJKwGoobXt4j0Y=.b597446f-e654-4083-bf6a-29c3eee0560c@github.com>
 <fpMEJ1QMx9Gwi2hColGPHea1w7wWdBmtZ5gVEissNHs=.4da2e5ad-71e5-4ae5-9dc3-5ebf8bdd0669@github.com>
 <KD4P0rdcNlK59MHt8wQVFgWzyLATB0y85kpCWlzWGRU=.a4b3d5d3-85e2-4691-8cc8-874b679058a2@github.com>
 <d3WpH2Wv-eGVMwG_uUJtTHdeljdIGauAA_x9cynsmVU=.91689b27-840b-4dc4-a0a0-6d48529868c4@github.com>
 <S_WVqyvsvxDSez9c0syZRE2cr8kQ1yeSOs9w4zBEWAY=.23eec805-97e0-4982-8417-6f0114646fbb@github.com>
 <NDd13XSxcbkLkY1hPDt7hlRUAo_3zlHikMaBpAHy8po=.c399c3e1-df5e-4ea8-a667-68d12bac991a@github.com>
 <gQcwrLo4ooSL418-Tl7D_KgnmVMPZ5HdJNJHm8OCFA4=.b3afd47c-2c8b-4bce-a8d1-e0b6c30c694d@github.com>
 <D6_zZm9npWxvfzJaGvqx7z043mGU7Qn-Bfx2aO-soGo=.e7c05ee6-f929-44b4-a2a3-7fbfb201a24b@github.com>
Message-ID: <mqYot0I0qw8LKxzCCrvoHSNIUjFln5r0PCb7DadmLU4=.27bb243d-7cf0-444a-a276-3f694a790906@github.com>

On Mon, 23 Jun 2025 19:10:03 GMT, Dean Long <dlong at openjdk.org> wrote:

> I think it's OK if there is a race to have a point of no return, and if one thread gets there first, it wins, and we don't need to check again.  It's tempting to want to do an extra check when we disarm under the lock, but then it would need a comment explaining why we do it, even though the make_not_entrant could come in right after and we would miss it.  And we have already done the work of healing the oops by this point.  Finally, I like the encapsulation that only nmethod_stub_entry_barrier needs to know about not_entrant, and nmethod_entry_barrier doesn't need to know. 

Fair enough!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2164467913

From duke at openjdk.org  Tue Jun 24 17:19:56 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 24 Jun 2025 17:19:56 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize
Message-ID: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>

Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.

This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.

Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.

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

Commit messages:
 - Remove extra include lines
 - Address comments
 - 8358529: GenShen: Heuristics do not respond to changes in SoftMaxHeapSize

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

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

From wkemper at openjdk.org  Tue Jun 24 17:19:57 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 24 Jun 2025 17:19:57 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <o0HHvbjcpoCDhwCGETC2pCJxgJw1AmqnQqoaud0O1WI=.0f126d1d-a107-4a02-88e5-425819effcd3@github.com>

On Mon, 23 Jun 2025 21:42:36 GMT, Rui Li <duke at openjdk.org> wrote:

> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
> 
> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
> 
> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.

Some nits.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp line 60:

> 58:   size_t min_threshold = capacity / 100 * ShenandoahMinFreeThreshold;
> 59: 
> 60:   log_debug(gc)("should_start_gc? available: %zu, soft_max_capacity: %zu", available, capacity);

Can we remove these, or at least make them `log_develop_debug`?

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

> 1015: size_t ShenandoahGeneration::soft_max_capacity() const {
> 1016:   size_t capacity = ShenandoahGenerationalHeap::heap()->soft_max_capacity();
> 1017:   log_debug(gc)("soft_max_capacity: %zu", capacity);

Can we add a comment here saying that we need this message for the `TestDynamicSoftMaxHeapSize`? Also, this property will be read far more often than it will be written. Can we put the log message in the place where the value changes?

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

> 127:   virtual ShenandoahHeuristics* initialize_heuristics(ShenandoahMode* gc_mode);
> 128: 
> 129:   size_t soft_max_capacity() const override;

Can we take out the `_soft_max_capacity` member from `ShenandoahGeneration` now?

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

> 99: #include "utilities/globalDefinitions.hpp"
> 100: #include "utilities/powerOfTwo.hpp"
> 101: #include "logging/log.hpp"

Let's keep the includes alphabetized.

test/hotspot/jtreg/gc/shenandoah/TestDynamicSoftMaxHeapSize.java line 68:

> 66: 
> 67:             ProcessBuilder satbPb = ProcessTools.createLimitedTestJavaProcessBuilder(satbGCModeArgsNoDegeneratedGC);
> 68:             (new OutputAnalyzer(satbPb.start())).shouldHaveExitValue(0);

I don't think we need parentheses around `new OutputAnalyzer(...)`.

test/hotspot/jtreg/gc/shenandoah/TestDynamicSoftMaxHeapSize.java line 89:

> 87:         genShenGCModeArgs.add("-XX:ShenandoahGCMode=generational");
> 88: 
> 89:         for (String heuristic : HEURISTICS) {

The generational mode will quietly ignore other heuristics: https://bugs.openjdk.org/browse/JDK-8342640

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25943#pullrequestreview-2951652830
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162604159
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162605400
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162605932
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162606483
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162607534
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162612757

From duke at openjdk.org  Tue Jun 24 17:19:57 2025
From: duke at openjdk.org (Rui Li)
Date: Tue, 24 Jun 2025 17:19:57 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize
In-Reply-To: <o0HHvbjcpoCDhwCGETC2pCJxgJw1AmqnQqoaud0O1WI=.0f126d1d-a107-4a02-88e5-425819effcd3@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <o0HHvbjcpoCDhwCGETC2pCJxgJw1AmqnQqoaud0O1WI=.0f126d1d-a107-4a02-88e5-425819effcd3@github.com>
Message-ID: <DHB0jkUkcL0UdSU6ZtTXc7gG4Mm2FPEBQ_n6c0JLdAA=.f31ec6e3-702e-4d29-9427-1fc68a1e90e5@github.com>

On Mon, 23 Jun 2025 22:06:15 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
>> 
>> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
>> 
>> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactHeuristics.cpp line 60:
> 
>> 58:   size_t min_threshold = capacity / 100 * ShenandoahMinFreeThreshold;
>> 59: 
>> 60:   log_debug(gc)("should_start_gc? available: %zu, soft_max_capacity: %zu", available, capacity);
> 
> Can we remove these, or at least make them `log_develop_debug`?

Sure. Removed.

> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 1017:
> 
>> 1015: size_t ShenandoahGeneration::soft_max_capacity() const {
>> 1016:   size_t capacity = ShenandoahGenerationalHeap::heap()->soft_max_capacity();
>> 1017:   log_debug(gc)("soft_max_capacity: %zu", capacity);
> 
> Can we add a comment here saying that we need this message for the `TestDynamicSoftMaxHeapSize`? Also, this property will be read far more often than it will be written. Can we put the log message in the place where the value changes?

Will add a comment. 

There is actually an existing info level log for soft_max_heap change: [code](https://github.com/openjdk/jdk/blob/6df0f5e390ecf874c1eca7284c51efa65ce23737/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L865-L868). (Side note: we can't simply validate this info log line in the test, since gen shen didn't use the value initially)

> src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 129:
> 
>> 127:   virtual ShenandoahHeuristics* initialize_heuristics(ShenandoahMode* gc_mode);
>> 128: 
>> 129:   size_t soft_max_capacity() const override;
> 
> Can we take out the `_soft_max_capacity` member from `ShenandoahGeneration` now?

Yes. Good catch. Removed

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 101:
> 
>> 99: #include "utilities/globalDefinitions.hpp"
>> 100: #include "utilities/powerOfTwo.hpp"
>> 101: #include "logging/log.hpp"
> 
> Let's keep the includes alphabetized.

These two aren't used actually. Removed.

> test/hotspot/jtreg/gc/shenandoah/TestDynamicSoftMaxHeapSize.java line 68:
> 
>> 66: 
>> 67:             ProcessBuilder satbPb = ProcessTools.createLimitedTestJavaProcessBuilder(satbGCModeArgsNoDegeneratedGC);
>> 68:             (new OutputAnalyzer(satbPb.start())).shouldHaveExitValue(0);
> 
> I don't think we need parentheses around `new OutputAnalyzer(...)`.

Right. Removed.

> test/hotspot/jtreg/gc/shenandoah/TestDynamicSoftMaxHeapSize.java line 89:
> 
>> 87:         genShenGCModeArgs.add("-XX:ShenandoahGCMode=generational");
>> 88: 
>> 89:         for (String heuristic : HEURISTICS) {
> 
> The generational mode will quietly ignore other heuristics: https://bugs.openjdk.org/browse/JDK-8342640

Updated the test to only test adaptive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162660601
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162660681
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162663178
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162696482
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162661332
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2162661911

From iwalulya at openjdk.org  Tue Jun 24 17:38:31 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 24 Jun 2025 17:38:31 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v4]
In-Reply-To: <npwkziB2ttDtCWWZCIAUFf1ZgJy03zgXDmpwRYkMNLw=.8888c59c-8fe1-4bbf-ae37-25e3179eb942@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wFwK4prXGPVbsBRHR4aCZ2HLeNpbzlLiBjitECUmYzw=.0afde1ac-ce8e-42df-9fba-e188a7d9a246@github.com>
 <npwkziB2ttDtCWWZCIAUFf1ZgJy03zgXDmpwRYkMNLw=.8888c59c-8fe1-4bbf-ae37-25e3179eb942@github.com>
Message-ID: <76uGVn8M29SoJxIA5AwwfYB13Gb0w8VT-zY5VTn8ymc=.3e1e2bd3-59b6-4d18-925e-bb53561f1cdd@github.com>

On Tue, 24 Jun 2025 15:49:56 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert suggestions
>
> src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 231:
> 
>> 229:   const double min_gc_time_ratio_ratio = G1MinimumPercentOfGCTimeRatio / 100.0;
>> 230:   double upper_threshold = pause_time_threshold * (1 + min_gc_time_ratio_ratio);
>> 231:   double lower_threshold = pause_time_threshold * (1 - min_gc_time_ratio_ratio);
> 
> There are some inconsistencies naming variables in this change: we use `pause_time_threshold`, `pause_time_ratio` and other similar terms that are under(de)fined for, essentially, (parts of) the cpu resources that G1 uses.
> 
> Also some things are called "ratio", but are percentages (e.g. `G1MinimumPercentOfGCTimeRatio`), and the comments somewhat interchangeably use cpu usage (in percent) and gctimeratio (the inverse of cpu usage).
> 
> I think it is useful to clean this up, also looking forward to making G1 start using actual GC CPU usage (thread user times), e.g.
> 
> 
> pause_time_threshold -> gc_cpu_usage_threshold
> long_term_pause_time_ratio -> long_term_cpu_usage
> [and so on]
> 
> 
> I admit that right now `cpu_usage` might be slightly misleading because we only approximate it using pause times and total run times (which do not necessarily reflect actual cpu usage), but it seems good enough for now, and future changes (https://bugs.openjdk.org/browse/JDK-8359348; even with that we might need to fallback to current mechanism).
> 
> What do others think?

Sounds good to me, I may suggest naming it as a `gc_cpu_usage_target` or `target_gc_cpu_usage` then it is easier to reason about the deviations from the target in the model.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2164557309

From kirk at kodewerk.com  Wed Jun 25 04:30:36 2025
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Tue, 24 Jun 2025 21:30:36 -0700
Subject: RFC: JEP draft: Ergonomics Always Select the G1 Garbage Collector
 as Default
In-Reply-To: <279a6ba3-9fb6-442c-b059-91a31365704a@oracle.com>
References: <279a6ba3-9fb6-442c-b059-91a31365704a@oracle.com>
Message-ID: <719AC92C-3274-4FAD-B345-A46C843BD2E2@kodewerk.com>

Hi Thomas,

I believe I did mentioned that I have benchmarks that do better with the serial collector with smaller heaps. It isn?t an outright objection but more of another data point.

Kind regards,
Kirk


> On Jun 23, 2025, at 1:57?AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  this is a continuation of an earlier thread [0] where I suggested to make G1 as the default collector unconditionally.
> 
> As you may know, on very small deployments (1 CPU and 1.8GB of heap), ergonomics still select the Serial collector if no GC algorithm is selected on the command line.
> 
> Since there has not been any pushback to that suggestion, I wrote up a JEP draft [1], so I wanted to ask for further feedback before submitting it.
> 
> Thanks,
>  Thomas
> 
> [0] https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-February/051121.html
> [1] https://bugs.openjdk.org/browse/JDK-8359802


From aboldtch at openjdk.org  Wed Jun 25 05:19:31 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 25 Jun 2025 05:19:31 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v8]
In-Reply-To: <zy0Qh0f-TD62c7_0DbFLK397FjXegNKFZPdPdETwAZk=.f262452d-cad2-4f80-8e88-9a27789c2996@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <zy0Qh0f-TD62c7_0DbFLK397FjXegNKFZPdPdETwAZk=.f262452d-cad2-4f80-8e88-9a27789c2996@github.com>
Message-ID: <WHHMsa56NOc5DeEq5_HOgF3Sl7FOQ9O046klDFjj97g=.ae66e9bc-65ec-4903-8456-31c17f3131fc@github.com>

On Mon, 23 Jun 2025 13:08:18 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
>> 
>> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
>> 
>> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> 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 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8358586_zallocator_cleanup
>  - Rework ZObjectAllocator
>  - Private member variables in ZObjectAlloactorImpl
>  - Move implementation to .cpp and static-only interface in .hpp
>  - Consistent template friend style
>  - Friend class ValueObjBlock
>  - AllStatic interface with ZObjectAllocators
>  - -Wconversion fixes
>  - Intermediate alloc_object in ZHeap
>  - 8358586: ZGC: Combine ZAllocator and ZObjectAllocator

Looks good. I like the new approach with keeping the state as part of ZCollectedHeap better.

Just a small suggestion.

src/hotspot/share/gc/z/zDeferredConstructed.hpp line 33:

> 31: 
> 32: template<typename T>
> 33: class ZDeferredConstructed {

We should move the definitions to zDeferredConstructed.inline.hpp. It is an exceptional case that we have them in the header instead of the inline header file. 

_(We usually only do this when the compiler needs a definition like when creating destructors for types containing none trivial destructors, we would probably also allow it if we would want constexpr creation of variables in header files)_

src/hotspot/share/gc/z/zDeferredConstructed.hpp line 38:

> 36:   };
> 37: 
> 38:   DEBUG_ONLY(bool _initialized);

Suggestion:

  DEBUG_ONLY(bool _initialized;)

src/hotspot/share/gc/z/zDeferredConstructed.hpp line 83:

> 81:   void initialize(Ts&&... args) {
> 82:     assert(!_initialized, "Double initialization forbidden");
> 83:     DEBUG_ONLY(_initialized = true);

Suggestion:

    DEBUG_ONLY(_initialized = true;)

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

Changes requested by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25693#pullrequestreview-2956582351
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2165795004
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2165780778
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2165781100

From jsikstro at openjdk.org  Wed Jun 25 08:00:20 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 25 Jun 2025 08:00:20 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v9]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <tXv1f9r38ZlEL-U3fHUZuElN89f9OFgz_tAM_pyZblg=.ddcc9243-477a-4d41-9b85-6abc688a04d6@github.com>

> Hello,
> 
> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
> 
> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
> 
> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
> 
> Testing:
> * Oracle's tier 1-5

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

 - Copyright year
 - Move definition of ZDeferredConstructed to inline header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/d2b59317..09fd3ef9

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

  Stats: 131 lines in 4 files changed: 88 ins; 32 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/25693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25693/head:pull/25693

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

From jsikstro at openjdk.org  Wed Jun 25 08:00:22 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 25 Jun 2025 08:00:22 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v8]
In-Reply-To: <WHHMsa56NOc5DeEq5_HOgF3Sl7FOQ9O046klDFjj97g=.ae66e9bc-65ec-4903-8456-31c17f3131fc@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <zy0Qh0f-TD62c7_0DbFLK397FjXegNKFZPdPdETwAZk=.f262452d-cad2-4f80-8e88-9a27789c2996@github.com>
 <WHHMsa56NOc5DeEq5_HOgF3Sl7FOQ9O046klDFjj97g=.ae66e9bc-65ec-4903-8456-31c17f3131fc@github.com>
Message-ID: <FY89d48PbjRBCa8ZEkwIgURsYfM12o0XelRa632BZWo=.1a70ef06-eaab-4c02-b6bd-d07d527df15b@github.com>

On Wed, 25 Jun 2025 05:15:03 GMT, Axel Boldt-Christmas <aboldtch 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 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8358586_zallocator_cleanup
>>  - Rework ZObjectAllocator
>>  - Private member variables in ZObjectAlloactorImpl
>>  - Move implementation to .cpp and static-only interface in .hpp
>>  - Consistent template friend style
>>  - Friend class ValueObjBlock
>>  - AllStatic interface with ZObjectAllocators
>>  - -Wconversion fixes
>>  - Intermediate alloc_object in ZHeap
>>  - 8358586: ZGC: Combine ZAllocator and ZObjectAllocator
>
> src/hotspot/share/gc/z/zDeferredConstructed.hpp line 33:
> 
>> 31: 
>> 32: template<typename T>
>> 33: class ZDeferredConstructed {
> 
> We should move the definitions to zDeferredConstructed.inline.hpp. It is an exceptional case that we have them in the header instead of the inline header file. 
> 
> _(We usually only do this when the compiler needs a definition like when creating destructors for types containing none trivial destructors, we would probably also allow it if we would want constexpr creation of variables in header files)_

I agree with you. I've moved the definitions to an inline header.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2166056025

From ayang at openjdk.org  Wed Jun 25 08:28:31 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 25 Jun 2025 08:28:31 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v8]
In-Reply-To: <KS1dwV7KFqChPy-INB8g2KC4cNPf3k-X2iyLTqARur0=.02863109-26f6-4859-b906-59646f4eab11@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <KS1dwV7KFqChPy-INB8g2KC4cNPf3k-X2iyLTqARur0=.02863109-26f6-4859-b906-59646f4eab11@github.com>
Message-ID: <jfAfsnUWjryu9wS-qw-IBBNzVrI6m4vyriKK5EOx0C0=.88840fc1-c496-43a8-b2f9-118057155811@github.com>

On Tue, 24 Jun 2025 13:32:04 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy 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:
> 
>  - Merge branch 'openjdk:master' into update_memory_state
>  -  Zgneeration class redundant
>  - g1Monitoring
>  - update zgenerationcounter
>  - psOldGen
>  - update capacity only for Generation counter
>  - Revert "update_capacity exists"
>    
>    This reverts commit cf2d66d598d90f1343d1ad7a4f30607c3374a0f8.
>  - Merge branch 'openjdk:master' into update_memory_state
>  - update_capacity exists

src/hotspot/share/gc/z/zServiceability.cpp line 57:

> 55: private:
> 56:   GenerationCounters _generation_young_counters;
> 57:   GenerationCounters _generation_old_counters;

These two field names are not aligned any more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25833#discussion_r2166115917

From ayang at openjdk.org  Wed Jun 25 08:39:42 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 25 Jun 2025 08:39:42 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v15]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <YYY-JJeecROuWdlIn4WUdgrG_CesMrVwLKP8jIS7fr0=.cadbcb7c-57a3-49c5-90d5-c1af951f3ee5@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - merge
 - version
 - Merge branch 'master' into pgc-size-policy
 - revert-aliases
 - Merge branch 'master' into pgc-size-policy
 - merge
 - ... and 11 more: https://git.openjdk.org/jdk/compare/75ce44aa...7f733137

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=14
  Stats: 4371 lines in 31 files changed: 520 ins; 3452 del; 399 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From thomas.schatzl at oracle.com  Wed Jun 25 08:46:40 2025
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Wed, 25 Jun 2025 10:46:40 +0200
Subject: RFC: JEP draft: Ergonomics Always Select the G1 Garbage Collector
 as Default
In-Reply-To: <719AC92C-3274-4FAD-B345-A46C843BD2E2@kodewerk.com>
References: <279a6ba3-9fb6-442c-b059-91a31365704a@oracle.com>
 <719AC92C-3274-4FAD-B345-A46C843BD2E2@kodewerk.com>
Message-ID: <932825fb-9344-4cd2-b762-488df722b27b@oracle.com>

Hi,

On 25.06.25 06:30, Kirk Pepperdine wrote:
> Hi Thomas,
> 
> I believe I did mentioned that I have benchmarks that do better with the serial collector with smaller heaps. It isn?t an outright objection but more of another data point.

   are these applications available for public use in some kind of 
benchmark? Or can you categorize and describe them in some way that 
makes it possible to understand the issue.

Particularly with throughput, due to current barrier design, there can 
still be a substantial difference. The new write barriers that are very 
similar to Serial GC's improve these application's throughput a lot.

We are aware that in microbenchmarks (including literally the 
microbenchmarks provided in the JDK sources), G1's throughput will never 
match Serial's throughput due to G1's pre-write barrier (barring 
non-barrier related differences like e.g. reduced GC pauses/footprint 
due to eager reclaim, "better" generation sizing or such).

The advantages are improved latency (G1 avoids full gcs), and less 
confusion about what collector you actually get by default, including 
the need for comments/talks like "Serial is the actual default 
collector". Or surprised questions on the internet that somehow the user 
got Serial GC even after reading that G1 is the default collector.

We've also started working on the AHS for G1 JEP (and obviously the 
functionality), and these two changes synergize: they ease use in e.g. 
container environments. At least by default (no options selected), one 
can then run the VM in any (small to larger) container and it will also 
automatically size itself according to available memory.
That could also resolve the many sizing issues people have when starting 
out with containers.

There will be more internal in-depth performance testing before 
potentially flipping the switch.

As the JEP notes, Serial will not go away.

However to have a remote chance to get all this in for the next release 
(in the happy path), we need to work on the JEP early.

Hth improving your understanding,
   Thomas

From stefank at openjdk.org  Wed Jun 25 08:59:31 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Jun 2025 08:59:31 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v8]
In-Reply-To: <KS1dwV7KFqChPy-INB8g2KC4cNPf3k-X2iyLTqARur0=.02863109-26f6-4859-b906-59646f4eab11@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <KS1dwV7KFqChPy-INB8g2KC4cNPf3k-X2iyLTqARur0=.02863109-26f6-4859-b906-59646f4eab11@github.com>
Message-ID: <lY2rHZVuL0a_m37nYj__8iKOkpmfE7WAo379ikI6f9M=.87317da9-64a0-4fbf-b61d-33ad4540ad49@github.com>

On Tue, 24 Jun 2025 13:32:04 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy 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:
> 
>  - Merge branch 'openjdk:master' into update_memory_state
>  -  Zgneeration class redundant
>  - g1Monitoring
>  - update zgenerationcounter
>  - psOldGen
>  - update capacity only for Generation counter
>  - Revert "update_capacity exists"
>    
>    This reverts commit cf2d66d598d90f1343d1ad7a4f30607c3374a0f8.
>  - Merge branch 'openjdk:master' into update_memory_state
>  - update_capacity exists

I had the same comment as Albert, but my comment was still pending.

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

PR Review: https://git.openjdk.org/jdk/pull/25833#pullrequestreview-2952925374

From stefank at openjdk.org  Wed Jun 25 08:59:32 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Jun 2025 08:59:32 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v7]
In-Reply-To: <iRyU5PaJjVJoQIdxbkQsuQAAqCVBztSM0rMFKxpwZUs=.10e52bbe-f8e5-42c8-b47f-9365d10c5833@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <iRyU5PaJjVJoQIdxbkQsuQAAqCVBztSM0rMFKxpwZUs=.10e52bbe-f8e5-42c8-b47f-9365d10c5833@github.com>
Message-ID: <Rjft-VwmCIJeVlSA9X3H0k0CEd3Kzj0cguWx6acxNWs=.f3201777-e9a5-4e0d-a34b-1cda9df99f7b@github.com>

On Tue, 24 Jun 2025 08:48:45 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>    Zgneeration class redundant

src/hotspot/share/gc/z/zServiceability.cpp line 57:

> 55: private:
> 56:   GenerationCounters _generation_young_counters;
> 57:   GenerationCounters _generation_old_counters;

Suggestion:

  GenerationCounters  _generation_young_counters;
  GenerationCounters  _generation_old_counters;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25833#discussion_r2163420271

From mdoerr at openjdk.org  Wed Jun 25 09:52:37 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Jun 2025 09:52:37 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
Message-ID: <mNH3LWDNZDpg6yPO-6D1-TGjrNPwQF-sZOpzR5MY85o=.ac50a9b9-6b24-424c-8544-5834eb4ec774@github.com>

On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8358821-patch-verified-entry
>  - 2nd try at arm fix
>  - rename arm_with to guard_with
>  - arm32 fix
>  - s390 fix courtesy of Amit Kumar
>  - remove is_sigill_not_entrant
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

src/hotspot/share/gc/shared/barrierSetNMethod.hpp line 52:

> 50: 
> 51: public:
> 52:   BarrierSetNMethod() : _current_phase(initial) {}

@fisk: The initial value doesn't match our initialization in the nmethod entry barrier code were we use 0. That causes all new nmethods to run through the barrier code when they are called for the first time. I think that is unnecessary and it slows down the startup a bit. All oops should already be correct after the nmethod got installed. And for ZGC, we call `nmethod_patch_barriers` in `ZNMethod::register_nmethod`. So, I don't see any need to execute the barrier code. We could change the initialization to use `_current_phase`. Do you agree? Should I file a new JBS issue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2166306862

From mdoerr at openjdk.org  Wed Jun 25 09:59:34 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Jun 2025 09:59:34 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <mNH3LWDNZDpg6yPO-6D1-TGjrNPwQF-sZOpzR5MY85o=.ac50a9b9-6b24-424c-8544-5834eb4ec774@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
 <mNH3LWDNZDpg6yPO-6D1-TGjrNPwQF-sZOpzR5MY85o=.ac50a9b9-6b24-424c-8544-5834eb4ec774@github.com>
Message-ID: <dESOVJeLSHTFdckUZOvMdebfWcbjqBOUxUMSAOrML5M=.9e850fdd-0db5-49f8-bd43-8de6b976f474@github.com>

On Wed, 25 Jun 2025 09:49:25 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into 8358821-patch-verified-entry
>>  - 2nd try at arm fix
>>  - rename arm_with to guard_with
>>  - arm32 fix
>>  - s390 fix courtesy of Amit Kumar
>>  - remove is_sigill_not_entrant
>>  - more cleanup
>>  - more TheRealMDoerr suggestions
>>  - TheRealMDoerr suggestions
>>  - remove trailing space
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c
>
> src/hotspot/share/gc/shared/barrierSetNMethod.hpp line 52:
> 
>> 50: 
>> 51: public:
>> 52:   BarrierSetNMethod() : _current_phase(initial) {}
> 
> @fisk: The initial value doesn't match our initialization in the nmethod entry barrier code were we use 0. That causes all new nmethods to run through the barrier code when they are called for the first time. I think that is unnecessary and it slows down the startup a bit. All oops should already be correct after the nmethod got installed. And for ZGC, we call `nmethod_patch_barriers` in `ZNMethod::register_nmethod`. So, I don't see any need to execute the barrier code. We could change the initialization to use `_current_phase`. Do you agree? Should I file a new JBS issue?

In other words, I think `disarm(nm);` is missing for some GCs. ZGC has it in `ZNMethod::register_nmethod`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2166322229

From sroy at openjdk.org  Wed Jun 25 12:08:12 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 25 Jun 2025 12:08:12 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v9]
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <A41YE0R-BCZNUkVIOtpm0pZxpWFHgVWQmdFeDXwZbf4=.f12b05ef-d4f8-4324-adee-85cd59722673@github.com>

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/gc/z/zServiceability.cpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25833/files
  - new: https://git.openjdk.org/jdk/pull/25833/files/f8ea505a..860c9a7a

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

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

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

From stefank at openjdk.org  Wed Jun 25 12:17:31 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Jun 2025 12:17:31 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v9]
In-Reply-To: <A41YE0R-BCZNUkVIOtpm0pZxpWFHgVWQmdFeDXwZbf4=.f12b05ef-d4f8-4324-adee-85cd59722673@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <A41YE0R-BCZNUkVIOtpm0pZxpWFHgVWQmdFeDXwZbf4=.f12b05ef-d4f8-4324-adee-85cd59722673@github.com>
Message-ID: <KEoFr4vqocQjCmK8B457YshKTJyAeBQHlBOOOJ5U2IE=.4405d5f0-11e0-4c53-91d6-a954217e6063@github.com>

On Wed, 25 Jun 2025 12:08:12 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/z/zServiceability.cpp
>   
>   Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25833#pullrequestreview-2957910759

From stefank at openjdk.org  Wed Jun 25 12:17:32 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Jun 2025 12:17:32 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v3]
In-Reply-To: <JXeVGylP4OmmcF1QKegjNGCRwvXprq5bMZpoag7Rl2s=.8b899099-3405-4575-ae33-79ce03403fbd@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <EGGN6OK2qYZDyxnbli5JzPnQZS7Pp4kxxk6RARdK4RY=.0c15fe00-ee38-4e74-9d1c-6813a0e8e57b@github.com>
 <nybLTpuZlfjZf0XUi9MTIJYCfbGrBmfRrS-Lg6ezhIc=.5cd475ea-1863-40d7-9977-b678f0c32fed@github.com>
 <JXeVGylP4OmmcF1QKegjNGCRwvXprq5bMZpoag7Rl2s=.8b899099-3405-4575-ae33-79ce03403fbd@github.com>
Message-ID: <LIFONqYT30TZQ-yvRBEovaLzV9pLe5RGaa7ofsD9OE4=.0ff695d8-9913-4ada-bf38-df7a278b083b@github.com>

On Tue, 24 Jun 2025 12:06:05 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Thanks for the revision.
>> 
>> I believe the one in `ZGenerationCounters` can be removed now.
>> 
>> 
>>   void update_capacity(size_t capacity) {
>>     update_all(capacity);
>>   }
>
> @albertnetymk @stefank  is the windows failures occurring on every PR today ?

@suchismith1993 Are you working for Red Hat? If you are not you need to revert the changes to the Red Hat copyright lines.

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

PR Comment: https://git.openjdk.org/jdk/pull/25833#issuecomment-3004555244

From sroy at openjdk.org  Wed Jun 25 12:35:47 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 25 Jun 2025 12:35:47 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v10]
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <zpPwqemGFzXKe2AFxMQnbWyL2un0ANBOMosuOS63bDo=.53b97f4a-7b8e-4a1a-90bb-b495fbafb970@github.com>

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:

 - Update shenandoahMonitoringSupport.cpp
 - Update epsilonMonitoringSupport.cpp
 - Update epsilonMonitoringSupport.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25833/files
  - new: https://git.openjdk.org/jdk/pull/25833/files/860c9a7a..ed4e2277

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

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

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

From sroy at openjdk.org  Wed Jun 25 12:35:47 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 25 Jun 2025 12:35:47 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v3]
In-Reply-To: <JXeVGylP4OmmcF1QKegjNGCRwvXprq5bMZpoag7Rl2s=.8b899099-3405-4575-ae33-79ce03403fbd@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <EGGN6OK2qYZDyxnbli5JzPnQZS7Pp4kxxk6RARdK4RY=.0c15fe00-ee38-4e74-9d1c-6813a0e8e57b@github.com>
 <nybLTpuZlfjZf0XUi9MTIJYCfbGrBmfRrS-Lg6ezhIc=.5cd475ea-1863-40d7-9977-b678f0c32fed@github.com>
 <JXeVGylP4OmmcF1QKegjNGCRwvXprq5bMZpoag7Rl2s=.8b899099-3405-4575-ae33-79ce03403fbd@github.com>
Message-ID: <DL2TqcEuWpm4hYcbJFkSPp0GEDFesWKfhC8jxAl0Iqg=.7c90b36f-01bf-4262-ab6c-698854755201@github.com>

On Tue, 24 Jun 2025 12:06:05 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> Thanks for the revision.
>> 
>> I believe the one in `ZGenerationCounters` can be removed now.
>> 
>> 
>>   void update_capacity(size_t capacity) {
>>     update_all(capacity);
>>   }
>
> @albertnetymk @stefank  is the windows failures occurring on every PR today ?

> @suchismith1993 Are you working for Red Hat? If you are not you need to revert the changes to the Red Hat copyright lines.

I work for IBM, so I need to add a new line with IBM Corp ?

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

PR Comment: https://git.openjdk.org/jdk/pull/25833#issuecomment-3004608395

From ayang at openjdk.org  Wed Jun 25 12:46:04 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 25 Jun 2025 12:46:04 GMT
Subject: RFR: 8360523: Parallel: Remove unused local variable in
 MutableNUMASpace::initialize
Message-ID: <6voKNVpl-Y4PLAAr5qbSjS9u6JlaE1424Eh9ff0fIqU=.04e930c3-0a9e-4a8b-a461-01e3ee9e80a5@github.com>

Trivial removing dead code.

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

Commit messages:
 - trivial

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

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

From stefank at openjdk.org  Wed Jun 25 13:08:33 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Jun 2025 13:08:33 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v10]
In-Reply-To: <zpPwqemGFzXKe2AFxMQnbWyL2un0ANBOMosuOS63bDo=.53b97f4a-7b8e-4a1a-90bb-b495fbafb970@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <zpPwqemGFzXKe2AFxMQnbWyL2un0ANBOMosuOS63bDo=.53b97f4a-7b8e-4a1a-90bb-b495fbafb970@github.com>
Message-ID: <Ev1E4lt-GnSvC6EPzleaK-6rEd9_jSOXcbwbD8QgWMo=.2f9ec4d6-5524-433b-8714-fa57349919da@github.com>

On Wed, 25 Jun 2025 12:35:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update shenandoahMonitoringSupport.cpp
>  - Update epsilonMonitoringSupport.cpp
>  - Update epsilonMonitoringSupport.cpp

Marked as reviewed by stefank (Reviewer).

Some extra info about copyrights:
https://openjdk.org/guide/#copyright-headers

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

PR Review: https://git.openjdk.org/jdk/pull/25833#pullrequestreview-2958085034
PR Comment: https://git.openjdk.org/jdk/pull/25833#issuecomment-3004701364

From stefank at openjdk.org  Wed Jun 25 13:08:34 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Jun 2025 13:08:34 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v3]
In-Reply-To: <DL2TqcEuWpm4hYcbJFkSPp0GEDFesWKfhC8jxAl0Iqg=.7c90b36f-01bf-4262-ab6c-698854755201@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <EGGN6OK2qYZDyxnbli5JzPnQZS7Pp4kxxk6RARdK4RY=.0c15fe00-ee38-4e74-9d1c-6813a0e8e57b@github.com>
 <nybLTpuZlfjZf0XUi9MTIJYCfbGrBmfRrS-Lg6ezhIc=.5cd475ea-1863-40d7-9977-b678f0c32fed@github.com>
 <JXeVGylP4OmmcF1QKegjNGCRwvXprq5bMZpoag7Rl2s=.8b899099-3405-4575-ae33-79ce03403fbd@github.com>
 <DL2TqcEuWpm4hYcbJFkSPp0GEDFesWKfhC8jxAl0Iqg=.7c90b36f-01bf-4262-ab6c-698854755201@github.com>
Message-ID: <F_1adPugbIkjzGCA4dJzCzw5GX4vD6mAxQ2wbjsQCaY=.124a8a1d-3523-4c2a-b4e0-5850059023d2@github.com>

On Wed, 25 Jun 2025 12:33:07 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > @suchismith1993 Are you working for Red Hat? If you are not you need to revert the changes to the Red Hat copyright lines.
> 
> I work for IBM, so I need to add a new line with IBM Corp ?

I think you need to ask your company about that.

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

PR Comment: https://git.openjdk.org/jdk/pull/25833#issuecomment-3004697577

From stefank at openjdk.org  Wed Jun 25 13:09:27 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Jun 2025 13:09:27 GMT
Subject: RFR: 8360523: Parallel: Remove unused local variable in
 MutableNUMASpace::initialize
In-Reply-To: <6voKNVpl-Y4PLAAr5qbSjS9u6JlaE1424Eh9ff0fIqU=.04e930c3-0a9e-4a8b-a461-01e3ee9e80a5@github.com>
References: <6voKNVpl-Y4PLAAr5qbSjS9u6JlaE1424Eh9ff0fIqU=.04e930c3-0a9e-4a8b-a461-01e3ee9e80a5@github.com>
Message-ID: <39JsSHKrCrVK8nwf7qLSGdKAQT_nKlBfhR2dqivt75g=.64b19391-b8b5-4626-8282-c9f833fd6257@github.com>

On Wed, 25 Jun 2025 12:41:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25977#pullrequestreview-2958088349

From ayang at openjdk.org  Wed Jun 25 13:12:30 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 25 Jun 2025 13:12:30 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v10]
In-Reply-To: <zpPwqemGFzXKe2AFxMQnbWyL2un0ANBOMosuOS63bDo=.53b97f4a-7b8e-4a1a-90bb-b495fbafb970@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <zpPwqemGFzXKe2AFxMQnbWyL2un0ANBOMosuOS63bDo=.53b97f4a-7b8e-4a1a-90bb-b495fbafb970@github.com>
Message-ID: <najwShm8Wtn_ipk26WJ4QDSUYHxeRXVe5wcUAIaK39I=.09b32528-973b-4c40-8d63-79f924daf648@github.com>

On Wed, 25 Jun 2025 12:35:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update shenandoahMonitoringSupport.cpp
>  - Update epsilonMonitoringSupport.cpp
>  - Update epsilonMonitoringSupport.cpp

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25833#pullrequestreview-2958097221

From duke at openjdk.org  Wed Jun 25 13:36:31 2025
From: duke at openjdk.org (duke)
Date: Wed, 25 Jun 2025 13:36:31 GMT
Subject: RFR: JDK-8349077 : Rename GenerationCounters::update_all [v10]
In-Reply-To: <zpPwqemGFzXKe2AFxMQnbWyL2un0ANBOMosuOS63bDo=.53b97f4a-7b8e-4a1a-90bb-b495fbafb970@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
 <zpPwqemGFzXKe2AFxMQnbWyL2un0ANBOMosuOS63bDo=.53b97f4a-7b8e-4a1a-90bb-b495fbafb970@github.com>
Message-ID: <u3GctLKNU9NFk1nST5aatblYT0ybP2hPfI3iSa9hKf4=.730e996c-9e5f-486d-b62a-b98eb4ecc64f@github.com>

On Wed, 25 Jun 2025 12:35:47 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
>> 
>> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
>> 
>> 
>> 
>> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update shenandoahMonitoringSupport.cpp
>  - Update epsilonMonitoringSupport.cpp
>  - Update epsilonMonitoringSupport.cpp

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

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

PR Comment: https://git.openjdk.org/jdk/pull/25833#issuecomment-3004802247

From kbarrett at openjdk.org  Wed Jun 25 13:45:28 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 25 Jun 2025 13:45:28 GMT
Subject: RFR: 8360523: Parallel: Remove unused local variable in
 MutableNUMASpace::initialize
In-Reply-To: <6voKNVpl-Y4PLAAr5qbSjS9u6JlaE1424Eh9ff0fIqU=.04e930c3-0a9e-4a8b-a461-01e3ee9e80a5@github.com>
References: <6voKNVpl-Y4PLAAr5qbSjS9u6JlaE1424Eh9ff0fIqU=.04e930c3-0a9e-4a8b-a461-01e3ee9e80a5@github.com>
Message-ID: <kaW31NpyfYt4F0roUJMIC50-KKFgY4XrT2nGwDt6iE4=.b846abc4-e6b9-43b1-a4ed-dd6ad9b10216@github.com>

On Wed, 25 Jun 2025 12:41:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Looks good, and trivial.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25977#pullrequestreview-2958217018

From aboldtch at openjdk.org  Wed Jun 25 13:49:31 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 25 Jun 2025 13:49:31 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v9]
In-Reply-To: <tXv1f9r38ZlEL-U3fHUZuElN89f9OFgz_tAM_pyZblg=.ddcc9243-477a-4d41-9b85-6abc688a04d6@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <tXv1f9r38ZlEL-U3fHUZuElN89f9OFgz_tAM_pyZblg=.ddcc9243-477a-4d41-9b85-6abc688a04d6@github.com>
Message-ID: <ExzQ8ZcYthvbY0z-0KuTJqJon7VgESbuG9vFfM2BcZ8=.66c0a2cb-f344-496a-9abc-84cf361ba416@github.com>

On Wed, 25 Jun 2025 08:00:20 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
>> 
>> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
>> 
>> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Copyright year
>  - Move definition of ZDeferredConstructed to inline header

Marked as reviewed by aboldtch (Reviewer).

src/hotspot/share/gc/z/zDeferredConstructed.hpp line 30:

> 28: #include "utilities/globalDefinitions.hpp"
> 29: 
> 30: template<typename T>

Suggestion:

template <typename T>

src/hotspot/share/gc/z/zDeferredConstructed.hpp line 53:

> 51:   const T* operator->() const;
> 52: 
> 53:   template<typename... Ts>

Suggestion:

  template <typename... Ts>

src/hotspot/share/gc/z/zDeferredConstructed.inline.hpp line 79:

> 77: 
> 78: template <typename T>
> 79: template<typename... Ts>

Suggestion:

template <typename... Ts>


We added a few of these without a space in 7e69b98e0548803b85b04b518929c073f8ffaf8c as well. Will have to clean them up at some point :)

src/hotspot/share/gc/z/zDeferredConstructed.inline.hpp line 82:

> 80: inline void ZDeferredConstructed<T>::initialize(Ts&&... args) {
> 81:   assert(!_initialized, "Double initialization forbidden");
> 82:   DEBUG_ONLY(_initialized = true;);

Suggestion:

  DEBUG_ONLY(_initialized = true;)

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

PR Review: https://git.openjdk.org/jdk/pull/25693#pullrequestreview-2958223558
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2166761972
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2166761520
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2166759204
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2166759490

From jsikstro at openjdk.org  Wed Jun 25 14:05:47 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 25 Jun 2025 14:05:47 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v10]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <UyaOmuP-wZ6c9Nm_-KBGOM6ECgAPmdBFlHsHwCSY8iY=.a12d1bda-42b0-4da1-975b-15ed3c1683dd@github.com>

> Hello,
> 
> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
> 
> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
> 
> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
> 
> Testing:
> * Oracle's tier 1-5

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

  Add template spacing and remove extra semicolon

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/09fd3ef9..9f949d3c

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

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

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

From jsikstro at openjdk.org  Wed Jun 25 14:05:48 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 25 Jun 2025 14:05:48 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v9]
In-Reply-To: <ExzQ8ZcYthvbY0z-0KuTJqJon7VgESbuG9vFfM2BcZ8=.66c0a2cb-f344-496a-9abc-84cf361ba416@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <tXv1f9r38ZlEL-U3fHUZuElN89f9OFgz_tAM_pyZblg=.ddcc9243-477a-4d41-9b85-6abc688a04d6@github.com>
 <ExzQ8ZcYthvbY0z-0KuTJqJon7VgESbuG9vFfM2BcZ8=.66c0a2cb-f344-496a-9abc-84cf361ba416@github.com>
Message-ID: <-vfRi-0fT6HXFHhWZqxI6FJptMsAytih_8OY8VGr0KY=.b011c900-12f4-4f93-a7da-93afd6f63fe8@github.com>

On Wed, 25 Jun 2025 13:44:12 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Copyright year
>>  - Move definition of ZDeferredConstructed to inline header
>
> src/hotspot/share/gc/z/zDeferredConstructed.inline.hpp line 79:
> 
>> 77: 
>> 78: template <typename T>
>> 79: template<typename... Ts>
> 
> Suggestion:
> 
> template <typename... Ts>
> 
> 
> We added a few of these without a space in 7e69b98e0548803b85b04b518929c073f8ffaf8c as well. Will have to clean them up at some point :)

Ah, good catch. I see that we have the following to fix at some point:

src/hotspot/share/gc/z/zPhysicalMemoryManager.cpp:162:1:template<>            
src/hotspot/share/gc/z/zValue.hpp:117:1:template<typename S, typename T>      
src/hotspot/share/gc/z/zArray.hpp:35:1:template<typename T> class ZArray;     
src/hotspot/share/gc/z/zPhysicalMemoryManager.cpp:171:1:template<typename... 
src/hotspot/share/gc/z/zPhysicalMemoryManager.cpp:156:3:  template<typename...
src/hotspot/share/gc/z/zPhysicalMemoryManager.cpp:164:3:  template<typename...
 ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2166802891

From iwalulya at openjdk.org  Wed Jun 25 14:16:39 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 25 Jun 2025 14:16:39 GMT
Subject: RFR: 8360522: G1: Flag constraint functions for G1SATBBufferSize and
 G1UpdateBufferSize are skipped during argument validation
Message-ID: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>

Hi,

Please review this change to move constraint function execution for  G1SATBBufferSize and G1UpdateBufferSize  to AfterErgo. These functions rely on the UseG1GC flag to determine whether to apply checks. However, during the AtParse phase of argument handling, UseG1GC may not yet be processed, which causes the constraints to be skipped.

Testing:
`java -XX:G1SATBBufferSize=0 -version`
`G1SATBBufferSize (0) must be in range [1, 4294967295]`
`Error: Could not create the Java Virtual Machine.`
`Error: A fatal exception has occurred. Program will exit.`

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

Commit messages:
 - move to AfterErgo phase

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

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

From ayang at openjdk.org  Wed Jun 25 14:20:28 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 25 Jun 2025 14:20:28 GMT
Subject: RFR: 8360522: G1: Flag constraint functions for G1SATBBufferSize
 and G1UpdateBufferSize are skipped during argument validation
In-Reply-To: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
References: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
Message-ID: <yUm_O1NcoPo55vlx98QO1fw1dfKnweyWU2b_Lpk5M28=.d3bd7bd3-b0f8-4361-9d33-8ba8f1b1578c@github.com>

On Wed, 25 Jun 2025 12:53:03 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi,
> 
> Please review this change to move constraint function execution for  G1SATBBufferSize and G1UpdateBufferSize  to AfterErgo. These functions rely on the UseG1GC flag to determine whether to apply checks. However, during the AtParse phase of argument handling, UseG1GC may not yet be processed, which causes the constraints to be skipped.
> 
> Testing:
> `java -XX:G1SATBBufferSize=0 -version`
> `G1SATBBufferSize (0) must be in range [1, 4294967295]`
> `Error: Could not create the Java Virtual Machine.`
> `Error: A fatal exception has occurred. Program will exit.`

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25979#pullrequestreview-2958373343

From aboldtch at openjdk.org  Wed Jun 25 14:29:30 2025
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 25 Jun 2025 14:29:30 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v10]
In-Reply-To: <UyaOmuP-wZ6c9Nm_-KBGOM6ECgAPmdBFlHsHwCSY8iY=.a12d1bda-42b0-4da1-975b-15ed3c1683dd@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <UyaOmuP-wZ6c9Nm_-KBGOM6ECgAPmdBFlHsHwCSY8iY=.a12d1bda-42b0-4da1-975b-15ed3c1683dd@github.com>
Message-ID: <HR_-bM3uyPMPEDRF9Ag_Ifow_wrNgU6Y5JUqRIa2T54=.30b7a3ce-001d-4ca1-8122-7d1540493167@github.com>

On Wed, 25 Jun 2025 14:05:47 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
>> 
>> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
>> 
>> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add template spacing and remove extra semicolon

Marked as reviewed by aboldtch (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25693#pullrequestreview-2958428429

From mdoerr at openjdk.org  Wed Jun 25 14:51:33 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Jun 2025 14:51:33 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <dESOVJeLSHTFdckUZOvMdebfWcbjqBOUxUMSAOrML5M=.9e850fdd-0db5-49f8-bd43-8de6b976f474@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
 <mNH3LWDNZDpg6yPO-6D1-TGjrNPwQF-sZOpzR5MY85o=.ac50a9b9-6b24-424c-8544-5834eb4ec774@github.com>
 <dESOVJeLSHTFdckUZOvMdebfWcbjqBOUxUMSAOrML5M=.9e850fdd-0db5-49f8-bd43-8de6b976f474@github.com>
Message-ID: <vPJStWUl4Mk_lThBlxQkeuQPWUhbAs7qvaFl_WWCdns=.9f516096-5b8f-4118-ad67-354f5896c4b7@github.com>

On Wed, 25 Jun 2025 09:56:52 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/barrierSetNMethod.hpp line 52:
>> 
>>> 50: 
>>> 51: public:
>>> 52:   BarrierSetNMethod() : _current_phase(initial) {}
>> 
>> @fisk: The initial value doesn't match our initialization in the nmethod entry barrier code were we use 0. That causes all new nmethods to run through the barrier code when they are called for the first time. I think that is unnecessary and it slows down the startup a bit. All oops should already be correct after the nmethod got installed. And for ZGC, we call `nmethod_patch_barriers` in `ZNMethod::register_nmethod`. So, I don't see any need to execute the barrier code. We could change the initialization to use `_current_phase`. Do you agree? Should I file a new JBS issue?
>
> In other words, I think `disarm(nm);` is missing for some GCs. ZGC has it in `ZNMethod::register_nmethod`.

I've filed https://bugs.openjdk.org/browse/JDK-8360540. We don't need to discuss it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25764#discussion_r2166924488

From mdoerr at openjdk.org  Wed Jun 25 15:01:40 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 25 Jun 2025 15:01:40 GMT
Subject: RFR: 8360540: nmethod entry barriers of new nmethods should be
 disarmed
Message-ID: <L7tMbCHWV7uyQxO-XB1peTZID_QrtDpYeZRNnOsiI5I=.721febbc-5439-414b-b889-d404dd2912a6@github.com>

Adding `disarm` calls as ZGC and ShenandoahGC already have. I will need reviews from GC experts. Tier1 tests have passed and I'll run more tests, but experts may know about potential problematic side effects.

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

Commit messages:
 - 8360540: nmethod entry barriers of new nmethods should be disarmed

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

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

From ayang at openjdk.org  Wed Jun 25 15:39:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 25 Jun 2025 15:39:34 GMT
Subject: RFR: 8360523: Parallel: Remove unused local variable in
 MutableNUMASpace::initialize
In-Reply-To: <6voKNVpl-Y4PLAAr5qbSjS9u6JlaE1424Eh9ff0fIqU=.04e930c3-0a9e-4a8b-a461-01e3ee9e80a5@github.com>
References: <6voKNVpl-Y4PLAAr5qbSjS9u6JlaE1424Eh9ff0fIqU=.04e930c3-0a9e-4a8b-a461-01e3ee9e80a5@github.com>
Message-ID: <1KHrtHWtB9aOpX7TwvrKutyzWD2Pz91Z8gqC2ioXKhs=.89053f01-52e1-44ab-bc0b-3b07eb5e1f81@github.com>

On Wed, 25 Jun 2025 12:41:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25977#issuecomment-3005226107

From ayang at openjdk.org  Wed Jun 25 15:39:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 25 Jun 2025 15:39:34 GMT
Subject: Integrated: 8360523: Parallel: Remove unused local variable in
 MutableNUMASpace::initialize
In-Reply-To: <6voKNVpl-Y4PLAAr5qbSjS9u6JlaE1424Eh9ff0fIqU=.04e930c3-0a9e-4a8b-a461-01e3ee9e80a5@github.com>
References: <6voKNVpl-Y4PLAAr5qbSjS9u6JlaE1424Eh9ff0fIqU=.04e930c3-0a9e-4a8b-a461-01e3ee9e80a5@github.com>
Message-ID: <P05uvuQTBN4VQqhaSvh7LaKxCgtZYkJo3hfwLKKqlb4=.fc256943-2347-4d00-92ec-1d5be62e150d@github.com>

On Wed, 25 Jun 2025 12:41:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing dead code.

This pull request has now been integrated.

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

8360523: Parallel: Remove unused local variable in MutableNUMASpace::initialize

Reviewed-by: stefank, kbarrett

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

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

From sroy at openjdk.org  Wed Jun 25 15:42:35 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 25 Jun 2025 15:42:35 GMT
Subject: Integrated: JDK-8349077 : Rename GenerationCounters::update_all
In-Reply-To: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
References: <GrGmGuAc_LX6Jk9asMq3v9oo-SguTPvyGDrtezm9Kr8=.71e87459-9529-455d-96a3-ce6d3c05c336@github.com>
Message-ID: <euXhI_Vyn2IlKlItBvqHnYIk0ENKrne6S5oe8vmp1Hw=.b86a63de-f016-48f5-b505-aa19f0eea1bf@github.com>

On Mon, 16 Jun 2025 14:39:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8349077](https://bugs.openjdk.org/browse/JDK-8349077)
> 
> we found the method names update_all of the class GenerationCounters and its subclasses are not so good. It is better to rename it to something like update_capacity (such as ZGenerationCounters::update_capacity).
> 
> 
> 
> Update_capacity exists, since update_all updates the size and used , I found update_memory_state as a better name for this method.

This pull request has now been integrated.

Changeset: 52c6044f
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/52c6044fe48f2e964be4c4603a865143f0d43f90
Stats:     34 lines in 10 files changed: 0 ins; 20 del; 14 mod

8349077: Rename GenerationCounters::update_all

Reviewed-by: ayang, stefank

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

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

From ayang at openjdk.org  Wed Jun 25 15:55:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 25 Jun 2025 15:55:40 GMT
Subject: RFR: 8360548: Parallel: Remove outdated comments in
 MutableNUMASpace::bias_region
Message-ID: <wgNbQtf0UQ71vd545YhT93-41GD316QQZ0PjFF-vzzQ=.bf0c9a9c-5071-43b0-a7a0-e6e330cb0241@github.com>

Trivial removing outdated comments.

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

Commit messages:
 - trivial

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

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

From tschatzl at openjdk.org  Wed Jun 25 16:36:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 25 Jun 2025 16:36:27 GMT
Subject: RFR: 8360548: Parallel: Remove outdated comments in
 MutableNUMASpace::bias_region
In-Reply-To: <wgNbQtf0UQ71vd545YhT93-41GD316QQZ0PjFF-vzzQ=.bf0c9a9c-5071-43b0-a7a0-e6e330cb0241@github.com>
References: <wgNbQtf0UQ71vd545YhT93-41GD316QQZ0PjFF-vzzQ=.bf0c9a9c-5071-43b0-a7a0-e6e330cb0241@github.com>
Message-ID: <7JcuxHLsFhAOkEe9KwqBmlxPTpjXXPpinGECajq4nCQ=.235f01b9-a8a0-4596-a6a8-cbaca06f0867@github.com>

On Wed, 25 Jun 2025 15:51:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing outdated comments.

Trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25984#pullrequestreview-2958891182

From tschatzl at openjdk.org  Wed Jun 25 16:48:28 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 25 Jun 2025 16:48:28 GMT
Subject: RFR: 8360522: G1: Flag constraint functions for G1SATBBufferSize
 and G1UpdateBufferSize are skipped during argument validation
In-Reply-To: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
References: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
Message-ID: <1sQsT619mm8lybuo7-OJGPmJM1B-V4Ydw_BBhK5ACwc=.ca64b91f-bf81-419a-9bfa-e9da70e9d3e8@github.com>

On Wed, 25 Jun 2025 12:53:03 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi,
> 
> Please review this change to move constraint function execution for  G1SATBBufferSize and G1UpdateBufferSize  to AfterErgo. These functions rely on the UseG1GC flag to determine whether to apply checks. However, during the AtParse phase of argument handling, UseG1GC may not yet be processed, which causes the constraints to be skipped.
> 
> Testing:
> `java -XX:G1SATBBufferSize=0 -version`
> `G1SATBBufferSize (0) must be in range [1, 4294967295]`
> `Error: Could not create the Java Virtual Machine.`
> `Error: A fatal exception has occurred. Program will exit.`

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25979#pullrequestreview-2958931380

From dlong at openjdk.org  Wed Jun 25 19:28:35 2025
From: dlong at openjdk.org (Dean Long)
Date: Wed, 25 Jun 2025 19:28:35 GMT
Subject: Integrated: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead
In-Reply-To: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
Message-ID: <fJR90jL9S5GHv2UcyO9z3ZgMe8tPRe7710L-mr8ytXs=.ba34c122-6d56-4fa5-afcb-a5dfe1e1b8a2@github.com>

On Thu, 12 Jun 2025 01:51:09 GMT, Dean Long <dlong at openjdk.org> wrote:

> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
> 
> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
> 
> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
> 
> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
> 
> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.

This pull request has now been integrated.

Changeset: cf75f1f9
Author:    Dean Long <dlong at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf75f1f9c6d2bc70c7133cb81c73a0ce0946dff9
Stats:     603 lines in 43 files changed: 97 ins; 459 del; 47 mod

8358821: patch_verified_entry causes problems, use nmethod entry barriers instead

Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Co-authored-by: Amit Kumar <amitkumar at openjdk.org>
Reviewed-by: mdoerr, eosterlund

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

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

From duke at openjdk.org  Wed Jun 25 21:14:01 2025
From: duke at openjdk.org (Rui Li)
Date: Wed, 25 Jun 2025 21:14:01 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v2]
In-Reply-To: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
Message-ID: <o1wfwjjIJEcEOxI7ZNeNapByyhJsEBi22iu2nDNm3Lw=.954ab02a-5582-4474-ae82-d9a64fa41123@github.com>

> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
> 
> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
> 
> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.

Rui Li has updated the pull request incrementally with one additional commit since the last revision:

  No need atomic load in initialization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25943/files
  - new: https://git.openjdk.org/jdk/pull/25943/files/d5dda920..49bda04e

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

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

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

From kbarrett at openjdk.org  Wed Jun 25 23:01:38 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 25 Jun 2025 23:01:38 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v2]
In-Reply-To: <OlrGflKYJyNoMEDjx4b64QoZ57KCIe-70KqrJjSl29w=.0536c301-9441-4038-b5ae-bec57c248eb9@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
 <OlrGflKYJyNoMEDjx4b64QoZ57KCIe-70KqrJjSl29w=.0536c301-9441-4038-b5ae-bec57c248eb9@github.com>
Message-ID: <KpPotFPojmVxhCyur_iTtame5aJnw7M2L4L7nc-MMCk=.4c02046f-9c1e-485d-b542-e817e96d9087@github.com>

On Tue, 24 Jun 2025 07:45:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
>> 
>> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into ref-refactor
>  - ref-refactor

src/hotspot/share/gc/shared/referenceProcessor.cpp line 638:

> 636:     if (from_len == 0) {
> 637:       // empty
> 638:       continue;

Kind of waffling over this, but I'm not sure this is worthwhile. The result falls out of the 
`remaining_to_move` calculation and use, and it's kind of cluttering.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 644:

> 642:     size_t remaining_to_move = move_all
> 643:       ? from_len
> 644:       : (from_len > avg_refs ? from_len - avg_refs : 0);

`move_all` is (now) only used in the immediately following complicated
conditional expression. I think this would be more readable as something like

  // If from_idx >= _num_queues, move all.
  // Otherwise, only move excess above avg_refs.
  size_t keep = 0;
  if (from_idx < _num_queues) {
    keep = MIN2(from_len, avg_refs);
  }
  size_t remaining_to_move = from_len - keep;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25930#discussion_r2167773359
PR Review Comment: https://git.openjdk.org/jdk/pull/25930#discussion_r2167769088

From syan at openjdk.org  Thu Jun 26 01:23:29 2025
From: syan at openjdk.org (SendaoYan)
Date: Thu, 26 Jun 2025 01:23:29 GMT
Subject: RFR: 8360522: G1: Flag constraint functions for G1SATBBufferSize
 and G1UpdateBufferSize are skipped during argument validation
In-Reply-To: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
References: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
Message-ID: <CMKgf8D4bSfWWTSDxL0LMWwYuaWH7rI4Y3L8qPRkngs=.1a1a3d1a-308f-4c28-b3c6-396edf746aba@github.com>

On Wed, 25 Jun 2025 12:53:03 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi,
> 
> Please review this change to move constraint function execution for  G1SATBBufferSize and G1UpdateBufferSize  to AfterErgo. These functions rely on the UseG1GC flag to determine whether to apply checks. However, during the AtParse phase of argument handling, UseG1GC may not yet be processed, which causes the constraints to be skipped.
> 
> Testing:
> `java -XX:G1SATBBufferSize=0 -version`
> `G1SATBBufferSize (0) must be in range [1, 4294967295]`
> `Error: Could not create the Java Virtual Machine.`
> `Error: A fatal exception has occurred. Program will exit.`

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

> 145:   product(size_t, G1SATBBufferSize, 1*K,                                    \
> 146:           "Number of entries in an SATB log buffer.")                       \
> 147:           constraint(G1SATBBufferSizeConstraintFunc, AfterErgo)             \

Should we update the copyrighy year from 2024 to 2025

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25979#discussion_r2167905971

From stefank at openjdk.org  Thu Jun 26 06:20:30 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 26 Jun 2025 06:20:30 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v10]
In-Reply-To: <UyaOmuP-wZ6c9Nm_-KBGOM6ECgAPmdBFlHsHwCSY8iY=.a12d1bda-42b0-4da1-975b-15ed3c1683dd@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <UyaOmuP-wZ6c9Nm_-KBGOM6ECgAPmdBFlHsHwCSY8iY=.a12d1bda-42b0-4da1-975b-15ed3c1683dd@github.com>
Message-ID: <k9bFzwn610MSyRhsD0Gy4kOA3Bsh30YwB0BH-aZ2RuA=.6ac0b12e-4103-467f-88e1-9d087a998045@github.com>

On Wed, 25 Jun 2025 14:05:47 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
>> 
>> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
>> 
>> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add template spacing and remove extra semicolon

src/hotspot/share/gc/z/zDeferredConstructed.hpp line 39:

> 37: 
> 38: public:
> 39:   NONCOPYABLE(ZDeferredConstructed);

Could you hide this in the private section?

src/hotspot/share/gc/z/zObjectAllocator.cpp line 207:

> 205:   : _allocators() {
> 206: 
> 207:   for (ZPageAge age : ZPageAgeRange()) {

Could this be using `ZPageAgeRangeAll`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2168197965
PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2168221759

From sangheki at openjdk.org  Thu Jun 26 06:46:28 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Thu, 26 Jun 2025 06:46:28 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v2]
In-Reply-To: <OlrGflKYJyNoMEDjx4b64QoZ57KCIe-70KqrJjSl29w=.0536c301-9441-4038-b5ae-bec57c248eb9@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
 <OlrGflKYJyNoMEDjx4b64QoZ57KCIe-70KqrJjSl29w=.0536c301-9441-4038-b5ae-bec57c248eb9@github.com>
Message-ID: <YHNoIwJrxLWJZ45gsk9VymSkWsiFNkpU799przTG0bs=.e26ec702-49bb-4ebb-bb65-adeac3317ab1@github.com>

On Tue, 24 Jun 2025 07:45:15 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
>> 
>> 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 two additional commits since the last revision:
> 
>  - Merge branch 'master' into ref-refactor
>  - ref-refactor

Changes requested by sangheki (Reviewer).

src/hotspot/share/gc/shared/referenceProcessor.cpp line 652:

> 650:       if (to_len >= avg_refs) {
> 651:         // this list is full enough; move on to next
> 652:         to_idx++;

As you will keep line 647 assert, keeping '(to_idx  + 1) % _num_queues' will make safer?

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

PR Review: https://git.openjdk.org/jdk/pull/25930#pullrequestreview-2960832844
PR Review Comment: https://git.openjdk.org/jdk/pull/25930#discussion_r2168267653

From jsikstro at openjdk.org  Thu Jun 26 07:32:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 26 Jun 2025 07:32:58 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v11]
In-Reply-To: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
Message-ID: <gLWyPClgkamYZ0i9svMED-bv4hsDLaNOHHWXQbOSq4Q=.867c5caf-e59a-43df-8afd-a07eff3e9d23@github.com>

> Hello,
> 
> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
> 
> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
> 
> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
> 
> Testing:
> * Oracle's tier 1-5

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

  Make NONCOPYABLE(ZDeferredConstructed) private

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25693/files
  - new: https://git.openjdk.org/jdk/pull/25693/files/9f949d3c..39958186

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

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

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

From jsikstro at openjdk.org  Thu Jun 26 07:32:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 26 Jun 2025 07:32:58 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v10]
In-Reply-To: <k9bFzwn610MSyRhsD0Gy4kOA3Bsh30YwB0BH-aZ2RuA=.6ac0b12e-4103-467f-88e1-9d087a998045@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <UyaOmuP-wZ6c9Nm_-KBGOM6ECgAPmdBFlHsHwCSY8iY=.a12d1bda-42b0-4da1-975b-15ed3c1683dd@github.com>
 <k9bFzwn610MSyRhsD0Gy4kOA3Bsh30YwB0BH-aZ2RuA=.6ac0b12e-4103-467f-88e1-9d087a998045@github.com>
Message-ID: <86ZZZyqQ1-ibUNvivq9r-_ehSqD-565Ma63WJEDTFW4=.dddd553b-7a24-4a1d-b814-35eba39b9414@github.com>

On Thu, 26 Jun 2025 06:14:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add template spacing and remove extra semicolon
>
> src/hotspot/share/gc/z/zObjectAllocator.cpp line 207:
> 
>> 205:   : _allocators() {
>> 206: 
>> 207:   for (ZPageAge age : ZPageAgeRange()) {
> 
> Could this be using `ZPageAgeRangeAll`?

I remember we discussed a `ZPageAgeRangeAll`, but it's not in the code right now. I agree that it becomes clearer that we're iterating over *all* ages with a `ZPageRangeAll` instead of `ZPageAgeRange()`.

constexpr ZPageAgeRange ZPageAgeRangeAll = ZPageAgeRange();


I don't have anything against adding `ZPageAgeRangeAll` and replacing all the other usages of `ZPageRange()` in this patch, but we could also do that in a follow up.

The other usages:

src/hotspot/share/gc/z/zRelocationSetSelector.cpp
243:  for (ZPageAge age : ZPageAgeRange()) {

src/hotspot/share/gc/z/zStat.cpp
1503:  for (ZPageAge age : ZPageAgeRange()) {
1564:  for (ZPageAge age : ZPageAgeRange()) {
1793:  for (ZPageAge age : ZPageAgeRange()) {

src/hotspot/share/gc/z/zRelocationSetSelector.inline.hpp
192:  for (ZPageAge age : ZPageAgeRange()) {
200:  for (ZPageAge age : ZPageAgeRange()) {
208:  for (ZPageAge age : ZPageAgeRange()) {

src/hotspot/share/gc/z/zGeneration.cpp
703:  for (ZPageAge age : ZPageAgeRange()) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2168375730

From stefank at openjdk.org  Thu Jun 26 07:39:31 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 26 Jun 2025 07:39:31 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v11]
In-Reply-To: <gLWyPClgkamYZ0i9svMED-bv4hsDLaNOHHWXQbOSq4Q=.867c5caf-e59a-43df-8afd-a07eff3e9d23@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <gLWyPClgkamYZ0i9svMED-bv4hsDLaNOHHWXQbOSq4Q=.867c5caf-e59a-43df-8afd-a07eff3e9d23@github.com>
Message-ID: <uMM3O1L_Kb7FqD3JAUBHo-5d5TEcla3zs3RQEuQ_Pow=.b6f55632-e802-46b7-b11b-c6ff7a817a64@github.com>

On Thu, 26 Jun 2025 07:32:58 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> After [JDK-8353184](https://bugs.openjdk.org/browse/JDK-8353184), ZAllocator has essentially become a mirror of ZObjectAllocator, questioning the relevance of ZAllocator. The purpose of this RFE is to combine ZAllocator and ZObjectAllocator into a single class ZObjectAllocator.
>> 
>> The solution I propose moves the new ZObjectAllocator as a data member in ZHeap, and is accessed solely from ZHeap. ZObjectAllocator stores a number of allocators, one for each age. Instead of storing eden and relocation allocators separately, all allocators are now in a single array, which makes it more straightforward to iterate over all allocators (when retiring pages for example). Since the underlying allocator (called PerAge) needs to be constructed with different ages, we can't use the default constructor/initialization, so I have a solution in-place for dealing with this.
>> 
>> Undoing an object allocation has been moved in its entirety (not calling into ZObjectAllocator) to ZHeap, where it fits much better.
>> 
>> Testing:
>> * Oracle's tier 1-5
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make NONCOPYABLE(ZDeferredConstructed) private

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25693#pullrequestreview-2961055589

From stefank at openjdk.org  Thu Jun 26 07:39:33 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 26 Jun 2025 07:39:33 GMT
Subject: RFR: 8358586: ZGC: Combine ZAllocator and ZObjectAllocator [v10]
In-Reply-To: <86ZZZyqQ1-ibUNvivq9r-_ehSqD-565Ma63WJEDTFW4=.dddd553b-7a24-4a1d-b814-35eba39b9414@github.com>
References: <2h9eRrAysZOlrgnHFy9daTRoxPEmlIHamrYiiv21R7U=.fc19debd-c797-454d-b599-5202ef0907b5@github.com>
 <UyaOmuP-wZ6c9Nm_-KBGOM6ECgAPmdBFlHsHwCSY8iY=.a12d1bda-42b0-4da1-975b-15ed3c1683dd@github.com>
 <k9bFzwn610MSyRhsD0Gy4kOA3Bsh30YwB0BH-aZ2RuA=.6ac0b12e-4103-467f-88e1-9d087a998045@github.com>
 <86ZZZyqQ1-ibUNvivq9r-_ehSqD-565Ma63WJEDTFW4=.dddd553b-7a24-4a1d-b814-35eba39b9414@github.com>
Message-ID: <OmmRIcv1bnJ8VfGUpgGF8Anvc5s7it1qJA7_uYmyaLE=.31471a8d-d7ae-40e6-90e1-bafa21726f13@github.com>

On Thu, 26 Jun 2025 07:26:09 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> src/hotspot/share/gc/z/zObjectAllocator.cpp line 207:
>> 
>>> 205:   : _allocators() {
>>> 206: 
>>> 207:   for (ZPageAge age : ZPageAgeRange()) {
>> 
>> Could this be using `ZPageAgeRangeAll`?
>
> I remember we discussed a `ZPageAgeRangeAll`, but it's not in the code right now. I agree that it becomes clearer that we're iterating over *all* ages with a `ZPageRangeAll` instead of `ZPageAgeRange()`.
> 
> constexpr ZPageAgeRange ZPageAgeRangeAll = ZPageAgeRange();
> 
> 
> I don't have anything against adding `ZPageAgeRangeAll` and replacing all the other usages of `ZPageRange()` in this patch, but we could also do that in a follow up.
> 
> The other usages:
> 
> src/hotspot/share/gc/z/zRelocationSetSelector.cpp
> 243:  for (ZPageAge age : ZPageAgeRange()) {
> 
> src/hotspot/share/gc/z/zStat.cpp
> 1503:  for (ZPageAge age : ZPageAgeRange()) {
> 1564:  for (ZPageAge age : ZPageAgeRange()) {
> 1793:  for (ZPageAge age : ZPageAgeRange()) {
> 
> src/hotspot/share/gc/z/zRelocationSetSelector.inline.hpp
> 192:  for (ZPageAge age : ZPageAgeRange()) {
> 200:  for (ZPageAge age : ZPageAgeRange()) {
> 208:  for (ZPageAge age : ZPageAgeRange()) {
> 
> src/hotspot/share/gc/z/zGeneration.cpp
> 703:  for (ZPageAge age : ZPageAgeRange()) {

OK. I thought that you had already added that. Let's keep the current version of the code in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25693#discussion_r2168400300

From thomas.schatzl at oracle.com  Thu Jun 26 07:45:46 2025
From: thomas.schatzl at oracle.com (Thomas Schatzl)
Date: Thu, 26 Jun 2025 09:45:46 +0200
Subject: RFC: JEP draft: Automatic Heap Sizing for G1
Message-ID: <ec32ed1d-7b5b-4085-b572-10711cd328bc@oracle.com>

Hi all,

   with this email I would like to collect feedback for the "Automatic 
Heap Sizing for G1" JEP draft I started writing recently [0].

The purpose of this JEP is to have G1 automatically and dynamically 
adapt the maximum heap size according to the environment.

We think there is fair possibility to complete the implementation by 
next JDK's feature complete date as the main preparatory change [1] is 
currently under review (fwiw, please chime in if interested, more 
feedback is always appreciated).

G1 AHS is somewhat different to ZGC's Automatic Heap Sizing proposal as 
part of the functionality proposed there has already been available in 
G1 for a long time.

It should be fairly complete, although I'm still a bit conflicted about 
the usefulness of the proposed G1GCIntensity flag, but we can always 
change that area as needed.

Thanks,
   Thomas

[0] https://bugs.openjdk.org/browse/JDK-8359211
[1] https://bugs.openjdk.org/browse/JDK-8238687 / 
https://git.openjdk.org/jdk/pull/25832


From tschatzl at openjdk.org  Thu Jun 26 08:12:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 26 Jun 2025 08:12:41 GMT
Subject: RFR: 8277394: Remove the use of safepoint_workers in reference
 processor
Message-ID: <RrtFq3ad8Biz9tWbHwGxvvpbkIBNoYjv9lfmbTeha4I=.869a5cea-cc0e-4205-a396-0519e8d4a277@github.com>

Hi all,

  please review this alternate implementation of 8277394. During the review of the first implementation (https://github.com/openjdk/jdk/pull/6453) the reviews did not like that the `WorkerThreads` were stashed away in the `ReferenceProcessor`.

This is an alternate implementation that implements the suggestion in the review comments, passing them along through the callers. While this requires a bit more changes, imo it better separates reference processor logic from the execution resources.

Testing: tier1-5

Thanks,
  Thomas

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

Commit messages:
 - 8277394

Changes: https://git.openjdk.org/jdk/pull/25995/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25995&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8277394
  Stats: 63 lines in 9 files changed: 18 ins; 26 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/25995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25995/head:pull/25995

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

From ayang at openjdk.org  Thu Jun 26 09:20:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 09:20:32 GMT
Subject: RFR: 8360548: Parallel: Remove outdated comments in
 MutableNUMASpace::bias_region
In-Reply-To: <wgNbQtf0UQ71vd545YhT93-41GD316QQZ0PjFF-vzzQ=.bf0c9a9c-5071-43b0-a7a0-e6e330cb0241@github.com>
References: <wgNbQtf0UQ71vd545YhT93-41GD316QQZ0PjFF-vzzQ=.bf0c9a9c-5071-43b0-a7a0-e6e330cb0241@github.com>
Message-ID: <fNpz-xb5qO7KzYPqCe91vU2-PNvQvFLSbAIKDD028Sc=.2899bd88-69b3-47ec-969c-b2c350607124@github.com>

On Wed, 25 Jun 2025 15:51:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing outdated comments.

Thanks for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/25984#issuecomment-3007782990

From ayang at openjdk.org  Thu Jun 26 09:20:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 09:20:32 GMT
Subject: Integrated: 8360548: Parallel: Remove outdated comments in
 MutableNUMASpace::bias_region
In-Reply-To: <wgNbQtf0UQ71vd545YhT93-41GD316QQZ0PjFF-vzzQ=.bf0c9a9c-5071-43b0-a7a0-e6e330cb0241@github.com>
References: <wgNbQtf0UQ71vd545YhT93-41GD316QQZ0PjFF-vzzQ=.bf0c9a9c-5071-43b0-a7a0-e6e330cb0241@github.com>
Message-ID: <a9k9EqPcTXRay9A1MwpmUvj6T7l-HK-9SONn4i3AufU=.76314e13-ab3c-40d8-9fcf-4dc8e0705675@github.com>

On Wed, 25 Jun 2025 15:51:07 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing outdated comments.

This pull request has now been integrated.

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

8360548: Parallel: Remove outdated comments in MutableNUMASpace::bias_region

Reviewed-by: tschatzl

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

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

From ayang at openjdk.org  Thu Jun 26 09:40:16 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 09:40:16 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v3]
In-Reply-To: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
Message-ID: <mKBBaFvg_XuM7OTVcn3CHeZhZhnMrRH2TAgZfB9_A90=.c32cdf34-d5f2-49f0-a878-a3a01830a1fb@github.com>

> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
> 
> 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 four additional commits since the last revision:

 - review
 - Merge branch 'master' into ref-refactor
 - Merge branch 'master' into ref-refactor
 - ref-refactor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25930/files
  - new: https://git.openjdk.org/jdk/pull/25930/files/3216b6ea..85a857e7

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

  Stats: 3745 lines in 188 files changed: 1366 ins; 1952 del; 427 mod
  Patch: https://git.openjdk.org/jdk/pull/25930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25930/head:pull/25930

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

From ayang at openjdk.org  Thu Jun 26 09:40:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 09:40:17 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v2]
In-Reply-To: <KpPotFPojmVxhCyur_iTtame5aJnw7M2L4L7nc-MMCk=.4c02046f-9c1e-485d-b542-e817e96d9087@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
 <OlrGflKYJyNoMEDjx4b64QoZ57KCIe-70KqrJjSl29w=.0536c301-9441-4038-b5ae-bec57c248eb9@github.com>
 <KpPotFPojmVxhCyur_iTtame5aJnw7M2L4L7nc-MMCk=.4c02046f-9c1e-485d-b542-e817e96d9087@github.com>
Message-ID: <4vS-_mkRekfO37wyIhVEZnzCxVPPd-pnhzOdYmoM5dU=.2f73ea4f-807e-4da6-bc11-73560c2bf0ba@github.com>

On Wed, 25 Jun 2025 22:51:45 GMT, Kim Barrett <kbarrett 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into ref-refactor
>>  - ref-refactor
>
> src/hotspot/share/gc/shared/referenceProcessor.cpp line 638:
> 
>> 636:     if (from_len == 0) {
>> 637:       // empty
>> 638:       continue;
> 
> Kind of waffling over this, but I'm not sure this is worthwhile. The result falls out of the 
> `remaining_to_move` calculation and use, and it's kind of cluttering.

I thought it's clearer to handle the empty-case explicitly. No strong feelings either way; removed.

> src/hotspot/share/gc/shared/referenceProcessor.cpp line 644:
> 
>> 642:     size_t remaining_to_move = move_all
>> 643:       ? from_len
>> 644:       : (from_len > avg_refs ? from_len - avg_refs : 0);
> 
> `move_all` is (now) only used in the immediately following complicated
> conditional expression. I think this would be more readable as something like
> 
>   // If from_idx >= _num_queues, move all.
>   // Otherwise, only move excess above avg_refs.
>   size_t keep = 0;
>   if (from_idx < _num_queues) {
>     keep = MIN2(from_len, avg_refs);
>   }
>   size_t remaining_to_move = from_len - keep;

I don't think so.

Your suggested comment:


// If from_idx >= _num_queues, move all.
// Otherwise, only move excess above avg_refs.

can almost directly map to the actual code:


    size_t remaining_to_move = move_all
      ? from_len
      : (from_len > avg_refs ? from_len - avg_refs : 0);


OTOH, the suggested snippet of using `keep` requires some thinking to connect the dots, IMO.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25930#discussion_r2168628359
PR Review Comment: https://git.openjdk.org/jdk/pull/25930#discussion_r2168641643

From ayang at openjdk.org  Thu Jun 26 09:40:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 09:40:17 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v2]
In-Reply-To: <YHNoIwJrxLWJZ45gsk9VymSkWsiFNkpU799przTG0bs=.e26ec702-49bb-4ebb-bb65-adeac3317ab1@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
 <OlrGflKYJyNoMEDjx4b64QoZ57KCIe-70KqrJjSl29w=.0536c301-9441-4038-b5ae-bec57c248eb9@github.com>
 <YHNoIwJrxLWJZ45gsk9VymSkWsiFNkpU799przTG0bs=.e26ec702-49bb-4ebb-bb65-adeac3317ab1@github.com>
Message-ID: <Xndq5goyLmFk5gWIuyLhkNyb7DX8UpNTknqEnSU85vo=.c4137621-63d5-40b8-aac0-2fc3778d9abb@github.com>

On Thu, 26 Jun 2025 06:35:24 GMT, Sangheon Kim <sangheki 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into ref-refactor
>>  - ref-refactor
>
> src/hotspot/share/gc/shared/referenceProcessor.cpp line 652:
> 
>> 650:       if (to_len >= avg_refs) {
>> 651:         // this list is full enough; move on to next
>> 652:         to_idx++;
> 
> As you will keep line 647 assert, keeping '(to_idx  + 1) % _num_queues' will make safer?

It's safer in the sense of suppressing potential errors. The `%` should be redundant -- if it's required to not fail, it's actually a bug and I'd prefer it fails fast. (I have run it through tier1-5, and we are at the very beginning of jdk26, so should be plenty of time for testing/fixing.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25930#discussion_r2168617315

From ayang at openjdk.org  Thu Jun 26 10:17:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 10:17:13 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v16]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <0FO5rCVeYxxJCB8J7GD-4WOtG7E6MA8gcja1YxGvWus=.22bd07e1-c3c3-40d1-b251-cc855ea48704@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

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

  remove-young-resize-after-full-gc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/7f733137..271a8916

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

  Stats: 59 lines in 3 files changed: 9 ins; 40 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From ayang at openjdk.org  Thu Jun 26 10:17:13 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 10:17:13 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <0l1GXiRVXTfUaPsDPyirWY0RnyyjxO95GfqnED2O1nw=.6f9d7504-3708-48f0-9e28-689772339276@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
 <0l1GXiRVXTfUaPsDPyirWY0RnyyjxO95GfqnED2O1nw=.6f9d7504-3708-48f0-9e28-689772339276@github.com>
Message-ID: <9F00iiZ3YclXm-0yJsaCC5z_MqZjUqvlKg8a8UvpRnE=.d010c44c-10d8-4ab8-8af2-77db2952d128@github.com>

On Mon, 19 May 2025 11:05:40 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Added checking for `from_space`.
>> 
>> If all live-objs don't fit in old-gen, leftovers will be kept in its own space.
>> 
>> 
>>   // Summarize the remaining spaces in the young gen.  The initial target space
>>   // is the old gen.  If a space does not fit entirely into the target, then the
>>   // remainder is compacted into the space itself and that space becomes the new
>>   // target.
>
>> If all live-objs don't fit in old-gen, leftovers will be kept in its own space.
> 
> Thanks for clarifying.

I removed this method, and added comments why it's undesirable to do young-gen resizing after a full-gc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2168706034

From iwalulya at openjdk.org  Thu Jun 26 11:42:12 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 26 Jun 2025 11:42:12 GMT
Subject: RFR: 8360522: G1: Flag constraint functions for G1SATBBufferSize
 and G1UpdateBufferSize are skipped during argument validation [v2]
In-Reply-To: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
References: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
Message-ID: <RFY61HOUxdEWZ5d9XHB1QNhoYtAtJSslPUpIGFtWbEk=.5565a6d8-47d0-4de3-83a6-3691cf337a24@github.com>

> Hi,
> 
> Please review this change to move constraint function execution for  G1SATBBufferSize and G1UpdateBufferSize  to AfterErgo. These functions rely on the UseG1GC flag to determine whether to apply checks. However, during the AtParse phase of argument handling, UseG1GC may not yet be processed, which causes the constraints to be skipped.
> 
> Testing:
> `java -XX:G1SATBBufferSize=0 -version`
> `G1SATBBufferSize (0) must be in range [1, 4294967295]`
> `Error: Could not create the Java Virtual Machine.`
> `Error: A fatal exception has occurred. Program will exit.`

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25979/files
  - new: https://git.openjdk.org/jdk/pull/25979/files/e4efe8de..0ebf48bb

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

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

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

From tschatzl at openjdk.org  Thu Jun 26 11:59:27 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 26 Jun 2025 11:59:27 GMT
Subject: RFR: 8360522: G1: Flag constraint functions for G1SATBBufferSize
 and G1UpdateBufferSize are skipped during argument validation [v2]
In-Reply-To: <RFY61HOUxdEWZ5d9XHB1QNhoYtAtJSslPUpIGFtWbEk=.5565a6d8-47d0-4de3-83a6-3691cf337a24@github.com>
References: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
 <RFY61HOUxdEWZ5d9XHB1QNhoYtAtJSslPUpIGFtWbEk=.5565a6d8-47d0-4de3-83a6-3691cf337a24@github.com>
Message-ID: <4Ne89OSXZGstLrlyDWZLsAn0r1hs7Cql6MFfIEPf-Po=.b3d1d931-5939-4bf1-bc0b-03673c86916e@github.com>

On Thu, 26 Jun 2025 11:42:12 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this change to move constraint function execution for  G1SATBBufferSize and G1UpdateBufferSize  to AfterErgo. These functions rely on the UseG1GC flag to determine whether to apply checks. However, during the AtParse phase of argument handling, UseG1GC may not yet be processed, which causes the constraints to be skipped.
>> 
>> Testing:
>> `java -XX:G1SATBBufferSize=0 -version`
>> `G1SATBBufferSize (0) must be in range [1, 4294967295]`
>> `Error: Could not create the Java Virtual Machine.`
>> `Error: A fatal exception has occurred. Program will exit.`
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25979#pullrequestreview-2961827113

From iwalulya at openjdk.org  Thu Jun 26 13:28:13 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 26 Jun 2025 13:28:13 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v5]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <nTRw067Cwg5E0OzKWYk-_otrLPP79Nc9z3OXvh5euIg=.35fe762f-9ce1-4d56-81d6-5608f3b97e9d@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25832/files
  - new: https://git.openjdk.org/jdk/pull/25832/files/df4f7ce5..8781a113

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

  Stats: 316 lines in 9 files changed: 112 ins; 65 del; 139 mod
  Patch: https://git.openjdk.org/jdk/pull/25832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25832/head:pull/25832

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

From kdnilsen at openjdk.org  Thu Jun 26 14:39:36 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 26 Jun 2025 14:39:36 GMT
Subject: Integrated: 8359947: GenShen: use smaller TLABs by default
In-Reply-To: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
References: <1072g2RnSN--eWgcAOHvElE0OI03fCdGJNGIgFNDnOQ=.21aca821-59c9-47b5-b1a2-6214f85dd5d3@github.com>
Message-ID: <-kLPrhiDLbGDw6qTD91bxiMDqD3Zr9ExjqNHOEGtOis=.6c3c8d49-3998-4c40-9f27-be6c5c3f6577@github.com>

On Fri, 23 May 2025 20:13:21 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> We have found with certain workloads that the initial and maximum tlab sizes result in very high latencies for the first few invocations of particular methods for certain threads.  The root cause is that TLABs are too large.  This is causing allocatable memory to be depleted too quickly.  When large numbers of threads are trying to startup at the same time, some of the threads end up with no TLABs or very small TLABs and their efforts run hundreds of times slower than the threads that were able to grab very large TLABs.
> 
> This PR reduces the maximum TLAB size and adjusts the initial TLAB size in order to reduce the impact of this problem.
> 
> This PR also changes the value of TLABAllocationWeight from 90 to 35 when we are running in generational mode.  35 is the default value used for G1 GC, which is also generational.  The default value of 90 was established years ago for non-generational Shenandoah because it tends to have less frequent GC cycles than generational collectors.
> 
> We have exercised this PR with three different workloads, which we identify as small, medium, and huge.  We have also exercised in two different configurations: with and without 30s warmup before latency measurements are taken.  Finally, we have applied this PR to both tip and to a development branch identified as adaptive-evac-with-surge.
> 
> The initial motivation for this PR was identified during testing of the adaptive-evac-with-surge branch.  That branch runs more aggressive GCs (larger evacuation workloads, with delayed (slightly more risky) triggers).  The objectives of this branch are to make GCs more efficient and to reduce CPU consumption.
> 
> We report 6 results for each experiment.  We sort these according to P100 latencies, and average results from the bottom four (best performing) samples, tossing out the two high outliers from the averages.  Workload results are subject to noise from elastic computing and operating system interference.
> 
> The benefits of this PR are most notable with the p99.999 and p100 small configuration of adaptive-evac-with-surge and the huge configuration of tip: 
> 
> ![image](https://github.com/user-attachments/assets/def49a3c-4142-48f7-a946-33527e6985d0)
> 
> ![image](https://github.com/user-attachments/assets/b0df27b3-f7b0-4fd2-82c3-ac84b0ad380e)
> 
> ![image](https://github.com/user-attachments/assets/471c1292-96dc-46c1-9bcc-b851be07867d)
> 
> Note also the degradation in p50 and other lower percentile latencies.  The effect of this PR is to require each mutator thre...

This pull request has now been integrated.

Changeset: a0c3efa6
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0c3efa6a80fe95e22faf5a732e42f1e1291fb4c
Stats:     13 lines in 3 files changed: 7 ins; 0 del; 6 mod

8359947: GenShen: use smaller TLABs by default

Reviewed-by: phh, xpeng

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

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

From iwalulya at openjdk.org  Thu Jun 26 15:04:40 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 26 Jun 2025 15:04:40 GMT
Subject: Integrated: 8360522: G1: Flag constraint functions for
 G1SATBBufferSize and G1UpdateBufferSize are skipped during argument validation
In-Reply-To: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
References: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
Message-ID: <GsCZwH6p8-pQjs48lMHtejMeI6ApxiWCnsmKtMpLcGc=.fb6c892a-84a0-49ab-aacc-aa15dfed4f1f@github.com>

On Wed, 25 Jun 2025 12:53:03 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi,
> 
> Please review this change to move constraint function execution for  G1SATBBufferSize and G1UpdateBufferSize  to AfterErgo. These functions rely on the UseG1GC flag to determine whether to apply checks. However, during the AtParse phase of argument handling, UseG1GC may not yet be processed, which causes the constraints to be skipped.
> 
> Testing:
> `java -XX:G1SATBBufferSize=0 -version`
> `G1SATBBufferSize (0) must be in range [1, 4294967295]`
> `Error: Could not create the Java Virtual Machine.`
> `Error: A fatal exception has occurred. Program will exit.`

This pull request has now been integrated.

Changeset: bd666f90
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd666f90eb7325c5a8c51cb2b9c28e177c5fe3a3
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8360522: G1: Flag constraint functions for G1SATBBufferSize and G1UpdateBufferSize are skipped during argument validation

Reviewed-by: tschatzl, ayang

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

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

From iwalulya at openjdk.org  Thu Jun 26 15:04:39 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 26 Jun 2025 15:04:39 GMT
Subject: RFR: 8360522: G1: Flag constraint functions for G1SATBBufferSize
 and G1UpdateBufferSize are skipped during argument validation [v2]
In-Reply-To: <RFY61HOUxdEWZ5d9XHB1QNhoYtAtJSslPUpIGFtWbEk=.5565a6d8-47d0-4de3-83a6-3691cf337a24@github.com>
References: <z9BsMWh4l9NSa0hXz1mulrr18UR5ITu-wQMaAb47KPM=.1f1990d9-2ce6-4a57-996c-5c4be09ef7d2@github.com>
 <RFY61HOUxdEWZ5d9XHB1QNhoYtAtJSslPUpIGFtWbEk=.5565a6d8-47d0-4de3-83a6-3691cf337a24@github.com>
Message-ID: <I04-lgmotobRiT8l6movYLmGYZozJ2LY573uBLTIUNA=.6586a633-a55f-4523-bc36-0c9cf293182f@github.com>

On Thu, 26 Jun 2025 11:42:12 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this change to move constraint function execution for  G1SATBBufferSize and G1UpdateBufferSize  to AfterErgo. These functions rely on the UseG1GC flag to determine whether to apply checks. However, during the AtParse phase of argument handling, UseG1GC may not yet be processed, which causes the constraints to be skipped.
>> 
>> Testing:
>> `java -XX:G1SATBBufferSize=0 -version`
>> `G1SATBBufferSize (0) must be in range [1, 4294967295]`
>> `Error: Could not create the Java Virtual Machine.`
>> `Error: A fatal exception has occurred. Program will exit.`
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25979#issuecomment-3008806933

From iwalulya at openjdk.org  Thu Jun 26 15:40:30 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 26 Jun 2025 15:40:30 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v16]
In-Reply-To: <0FO5rCVeYxxJCB8J7GD-4WOtG7E6MA8gcja1YxGvWus=.22bd07e1-c3c3-40d1-b251-cc855ea48704@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <0FO5rCVeYxxJCB8J7GD-4WOtG7E6MA8gcja1YxGvWus=.22bd07e1-c3c3-40d1-b251-cc855ea48704@github.com>
Message-ID: <P2i4hJfjR2uZwFXcdIcj28i8LDvMlLM6aQsRolnXlNc=.5622e075-fbc1-426c-b8fc-fd4045cea656@github.com>

On Thu, 26 Jun 2025 10:17:13 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove-young-resize-after-full-gc

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/parallel/psYoungGen.cpp line 305:

> 303:                                                eden_space()->top(),
> 304:                                                sizeof(HeapWord));
> 305:     if (word_size > available_word_size) {

Would it be useful to `log_trace` this situaton?

src/hotspot/share/gc/parallel/psYoungGen.cpp line 321:

> 319: }
> 320: 
> 321: void PSYoungGen::compute_desired_sizes(bool is_survivor_overflowing,

Probably subjective, but as suggested on a recent review, is it easier to read if you returned the results in a Pair<size_t, size_t>?

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

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2950871762
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169356093
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169350754

From iwalulya at openjdk.org  Thu Jun 26 15:40:33 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 26 Jun 2025 15:40:33 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v14]
In-Reply-To: <9oCyQapT5zkgtiWmLQoPBY10EUD6Q4LIEO4Sr6nyxXI=.963bc30b-a996-4c5a-9594-16c36c6c70db@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <9oCyQapT5zkgtiWmLQoPBY10EUD6Q4LIEO4Sr6nyxXI=.963bc30b-a996-4c5a-9594-16c36c6c70db@github.com>
Message-ID: <rdBFXf7-F7TgNvzjJrqZ5727MT7-B7bAvZb-gXuM4Oc=.0216769c-da6c-4b0f-81c6-c051debfac15@github.com>

On Mon, 23 Jun 2025 08:34:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:
> 
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - version
>  - Merge branch 'master' into pgc-size-policy
>  - revert-aliases
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - merge-fix
>  - ... and 10 more: https://git.openjdk.org/jdk/compare/516197f5...41027bdf

src/hotspot/share/gc/parallel/psScavenge.cpp line 539:

> 537:   if (!young_gen->to_space()->is_empty()) {
> 538:     // To-space is not empty; should run full-gc instead.
> 539:     log_debug(gc, ergo)("non-empty to-space; full-gc instead");

"To-space is not empty; should run full-gc instead" seems like a better log string if we need logging here

src/hotspot/share/gc/parallel/psVirtualspace.cpp line 66:

> 64:     _committed_high_addr += bytes;
> 65:   } else {
> 66:     log_warning(gc)("expand_by commit %zu bytes failed", bytes);

probably leftover from debugging, if not, then maybe improve the log string

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2162115342
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2162111028

From tschatzl at openjdk.org  Thu Jun 26 16:06:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 26 Jun 2025 16:06:07 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime()
Message-ID: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>

Hi all,

  please review this change that removes the `*vtime()` methods from G1, replacing them with the appropriate `os::thread_cpu_time()` calls. They completely supersede the former ones.

Further I made support for `os::thread_cpu_time()` mandatory for G1, it will fail if not available. All platforms implement them, only non-OSX *BSD do not in mainline sources. However in the [official fork](https://github.com/freebsd/openjdk/blob/jdk24u-freebsd/src/hotspot/os/bsd/os_bsd.cpp#L2609) it already does.

There are upstreaming efforts underway too, so I do not see this as blocker for this behavior. 

One other change is that the various getters directly use the time returned by the OS function as cpu time, only counting the main work (marking steps, actual refinement) as used cpu time. I do not think this is honest to discount random cpu time spent in other work these threads must do (like getting to and leaving the main work described above).

There has been some effort to make naming a bit more consistent: cpu times were all named with `_cpu_time` with all non-standard units that unit appended (`_s`for seconds and so on).

Testing: tier1-3

Thanks,
  Thomas

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

Commit messages:
 - * whitespace removal
 - * renamings
 - * fix build
 - * initial version

Changes: https://git.openjdk.org/jdk/pull/26001/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26001&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8274051
  Stats: 188 lines in 18 files changed: 29 ins; 96 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/26001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26001/head:pull/26001

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

From ayang at openjdk.org  Thu Jun 26 19:17:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 19:17:11 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v17]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <lCCR-o-A90dC3X_RMzVp3lZ6ttwv-drSPIaAplMe9w0=.5bea2111-d462-4786-85b7-1ac516d1ad9a@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:

 - Merge branch 'master' into pgc-size-policy
 - review
 - cast
 - remove-young-resize-after-full-gc
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - merge
 - version
 - ... and 15 more: https://git.openjdk.org/jdk/compare/20e0055e...eeda1eb8

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=16
  Stats: 4362 lines in 31 files changed: 506 ins; 3470 del; 386 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From ayang at openjdk.org  Thu Jun 26 19:25:32 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 19:25:32 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v14]
In-Reply-To: <rdBFXf7-F7TgNvzjJrqZ5727MT7-B7bAvZb-gXuM4Oc=.0216769c-da6c-4b0f-81c6-c051debfac15@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <9oCyQapT5zkgtiWmLQoPBY10EUD6Q4LIEO4Sr6nyxXI=.963bc30b-a996-4c5a-9594-16c36c6c70db@github.com>
 <rdBFXf7-F7TgNvzjJrqZ5727MT7-B7bAvZb-gXuM4Oc=.0216769c-da6c-4b0f-81c6-c051debfac15@github.com>
Message-ID: <1VCKQ3DB7qOy2FYZRgJ1MsjgJn4V0HRjz4jb4qPfYus=.3d9d8374-c422-48b7-a058-cd27f20c9e76@github.com>

On Mon, 23 Jun 2025 17:26:29 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 pull request now contains 20 commits:
>> 
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - version
>>  - Merge branch 'master' into pgc-size-policy
>>  - revert-aliases
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - merge-fix
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/516197f5...41027bdf
>
> src/hotspot/share/gc/parallel/psVirtualspace.cpp line 66:
> 
>> 64:     _committed_high_addr += bytes;
>> 65:   } else {
>> 66:     log_warning(gc)("expand_by commit %zu bytes failed", bytes);
> 
> probably leftover from debugging, if not, then maybe improve the log string

Revised.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169803226

From ayang at openjdk.org  Thu Jun 26 19:25:34 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 26 Jun 2025 19:25:34 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v16]
In-Reply-To: <P2i4hJfjR2uZwFXcdIcj28i8LDvMlLM6aQsRolnXlNc=.5622e075-fbc1-426c-b8fc-fd4045cea656@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <0FO5rCVeYxxJCB8J7GD-4WOtG7E6MA8gcja1YxGvWus=.22bd07e1-c3c3-40d1-b251-cc855ea48704@github.com>
 <P2i4hJfjR2uZwFXcdIcj28i8LDvMlLM6aQsRolnXlNc=.5622e075-fbc1-426c-b8fc-fd4045cea656@github.com>
Message-ID: <xAY1UgL6gCJsaj692vUllQx1ZTDyGF66zFTp7HTBf-Y=.e681460e-cbf7-4f45-ab22-8a13516a4119@github.com>

On Thu, 26 Jun 2025 15:35:25 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove-young-resize-after-full-gc
>
> src/hotspot/share/gc/parallel/psYoungGen.cpp line 305:
> 
>> 303:                                                eden_space()->top(),
>> 304:                                                sizeof(HeapWord));
>> 305:     if (word_size > available_word_size) {
> 
> Would it be useful to `log_trace` this situaton?

You mean we are probably approaching OOM here? However, we can reach here from diff calling-context, we don't know if we are near OOM or not.

> src/hotspot/share/gc/parallel/psYoungGen.cpp line 321:
> 
>> 319: }
>> 320: 
>> 321: void PSYoungGen::compute_desired_sizes(bool is_survivor_overflowing,
> 
> Probably subjective, but as suggested on a recent review, is it easier to read if you returned the results in a Pair<size_t, size_t>?

It probably doesn't make much difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169802849
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169790986

From kbarrett at openjdk.org  Thu Jun 26 20:00:46 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 26 Jun 2025 20:00:46 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime()
In-Reply-To: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
Message-ID: <zwPEDArlUkL7chFysUljZ1jx6Nj13mROEf1STlB32Rg=.574a340a-d2d0-483e-a333-a75224b5835e@github.com>

On Thu, 26 Jun 2025 12:53:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that removes the `*vtime()` methods from G1, replacing them with the appropriate `os::thread_cpu_time()` calls. They completely supersede the former ones.
> 
> Further I made support for `os::thread_cpu_time()` mandatory for G1, it will fail if not available. All platforms implement them, only non-OSX *BSD do not in mainline sources. However in the [official fork](https://github.com/freebsd/openjdk/blob/jdk24u-freebsd/src/hotspot/os/bsd/os_bsd.cpp#L2609) it already does.
> 
> There are upstreaming efforts underway too, so I do not see this as blocker for this behavior. 
> 
> One other change is that the various getters directly use the time returned by the OS function as cpu time, only counting the main work (marking steps, actual refinement) as used cpu time. I do not think this is honest to discount random cpu time spent in other work these threads must do (like getting to and leaving the main work described above).
> 
> There has been some effort to make naming a bit more consistent: cpu times were all named with `_cpu_time` with all non-standard units that unit appended (`_s`for seconds and so on).
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

It makes me happy to see the vtime stuff removed.

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2090:

> 2088: 
> 2089:     void do_thread(Thread* t) {
> 2090:       _total_cpu_time = os::thread_cpu_time(t);

Shouldn't this be `+=` rather than just `+`?

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2272:

> 2270:   }
> 2271: 
> 2272:   jlong curr_time_ns = os::current_thread_cpu_time();

pre-existing: I wonder why this is here, rather than a few lines later, near where it's used.

src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2283:

> 2281:   // (5) We check whether we've reached our time quota. If we have,
> 2282:   // then we abort.
> 2283:   double elapsed_time_ms = (double)(curr_time_ns - _start_cpu_time_ns) / NANOSECS_PER_MILLISEC;

Maybe there should be a helper for this calculation, since there are several occurrences of it?

src/hotspot/share/gc/g1/g1RemSetSummary.cpp line 47:

> 45:     virtual void do_thread(Thread* t) {
> 46:       G1ConcurrentRefineThread* crt = static_cast<G1ConcurrentRefineThread*>(t);
> 47:       _summary->set_rs_thread_vtime(_counter, crt->cpu_time_s());

There's still a bunch of "vtime" nomenclature in this file. Is the plan to clean that up later?

src/hotspot/share/gc/g1/g1ServiceThread.cpp line 157:

> 155: 
> 156: void G1ServiceThread::update_perf_counter_cpu_time() {
> 157:   if (UsePerfData ) {

Stray space before close-paren.

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

PR Review: https://git.openjdk.org/jdk/pull/26001#pullrequestreview-2963322877
PR Review Comment: https://git.openjdk.org/jdk/pull/26001#discussion_r2169814422
PR Review Comment: https://git.openjdk.org/jdk/pull/26001#discussion_r2169819983
PR Review Comment: https://git.openjdk.org/jdk/pull/26001#discussion_r2169827699
PR Review Comment: https://git.openjdk.org/jdk/pull/26001#discussion_r2169865330
PR Review Comment: https://git.openjdk.org/jdk/pull/26001#discussion_r2169869495

From dholmes at openjdk.org  Fri Jun 27 00:47:38 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 27 Jun 2025 00:47:38 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime()
In-Reply-To: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
Message-ID: <r9hf3XDUXD7cv8VKaS-A1hSWTiwvX5p9X-4SWPUa-PQ=.52fa03c6-fc6d-47c0-a8e1-4f848b307423@github.com>

On Thu, 26 Jun 2025 12:53:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that removes the `*vtime()` methods from G1, replacing them with the appropriate `os::thread_cpu_time()` calls. They completely supersede the former ones.
> 
> Further I made support for `os::thread_cpu_time()` mandatory for G1, it will fail if not available. All platforms implement them, only non-OSX *BSD do not in mainline sources. However in the [official fork](https://github.com/freebsd/openjdk/blob/jdk24u-freebsd/src/hotspot/os/bsd/os_bsd.cpp#L2609) it already does.
> 
> There are upstreaming efforts underway too, so I do not see this as blocker for this behavior. 
> 
> One other change is that the various getters directly use the time returned by the OS function as cpu time, only counting the main work (marking steps, actual refinement) as used cpu time. I do not think this is honest to discount random cpu time spent in other work these threads must do (like getting to and leaving the main work described above).
> 
> There has been some effort to make naming a bit more consistent: cpu times were all named with `_cpu_time` with all non-standard units that unit appended (`_s`for seconds and so on).
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

Runtime changes look good - nice to see vtime go away!

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

PR Review: https://git.openjdk.org/jdk/pull/26001#pullrequestreview-2964219658

From tschatzl at openjdk.org  Fri Jun 27 09:39:33 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 27 Jun 2025 09:39:33 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime() [v2]
In-Reply-To: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
Message-ID: <mzHXiyuuafn0j8rijRoldfjjEwDVgLXJU48pqRqyzdY=.b192aed1-d4a9-40ae-ad42-7d39161294e4@github.com>

> Hi all,
> 
>   please review this change that removes the `*vtime()` methods from G1, replacing them with the appropriate `os::thread_cpu_time()` calls. They completely supersede the former ones.
> 
> Further I made support for `os::thread_cpu_time()` mandatory for G1, it will fail if not available. All platforms implement them, only non-OSX *BSD do not in mainline sources. However in the [official fork](https://github.com/freebsd/openjdk/blob/jdk24u-freebsd/src/hotspot/os/bsd/os_bsd.cpp#L2609) it already does.
> 
> There are upstreaming efforts underway too, so I do not see this as blocker for this behavior. 
> 
> One other change is that the various getters directly use the time returned by the OS function as cpu time, only counting the main work (marking steps, actual refinement) as used cpu time. I do not think this is honest to discount random cpu time spent in other work these threads must do (like getting to and leaving the main work described above).
> 
> There has been some effort to make naming a bit more consistent: cpu times were all named with `_cpu_time` with all non-standard units that unit appended (`_s`for seconds and so on).
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

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

  * kbarrett review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26001/files
  - new: https://git.openjdk.org/jdk/pull/26001/files/b615ddbd..9662ba1e

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

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

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

From tschatzl at openjdk.org  Fri Jun 27 09:39:34 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 27 Jun 2025 09:39:34 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime() [v2]
In-Reply-To: <zwPEDArlUkL7chFysUljZ1jx6Nj13mROEf1STlB32Rg=.574a340a-d2d0-483e-a333-a75224b5835e@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
 <zwPEDArlUkL7chFysUljZ1jx6Nj13mROEf1STlB32Rg=.574a340a-d2d0-483e-a333-a75224b5835e@github.com>
Message-ID: <QIkKMu7IZKoo54z0brIk6Umo3ttxmEu1A0YDBTQIoY4=.17bba743-51d0-4b71-a340-10929e0d36d7@github.com>

On Thu, 26 Jun 2025 19:27:57 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * kbarrett review
>
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2090:
> 
>> 2088: 
>> 2089:     void do_thread(Thread* t) {
>> 2090:       _total_cpu_time = os::thread_cpu_time(t);
> 
> Shouldn't this be `+=` rather than just `+`?

nice catch! Fixed.

> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2272:
> 
>> 2270:   }
>> 2271: 
>> 2272:   jlong curr_time_ns = os::current_thread_cpu_time();
> 
> pre-existing: I wonder why this is here, rather than a few lines later, near where it's used.

I do not know either, and found it confusing too. I fixed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26001#discussion_r2171406859
PR Review Comment: https://git.openjdk.org/jdk/pull/26001#discussion_r2171409629

From tschatzl at openjdk.org  Fri Jun 27 09:48:07 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 27 Jun 2025 09:48:07 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime() [v3]
In-Reply-To: <zwPEDArlUkL7chFysUljZ1jx6Nj13mROEf1STlB32Rg=.574a340a-d2d0-483e-a333-a75224b5835e@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
 <zwPEDArlUkL7chFysUljZ1jx6Nj13mROEf1STlB32Rg=.574a340a-d2d0-483e-a333-a75224b5835e@github.com>
Message-ID: <yohL1qwPL4PsQq-sOS_H4R2K9f-N95fNJUo1ZTxqUZ0=.ce42543f-c930-48ad-b454-358260d9473d@github.com>

On Thu, 26 Jun 2025 19:34:58 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   * more kbarrett review
>
> src/hotspot/share/gc/g1/g1ConcurrentMark.cpp line 2283:
> 
>> 2281:   // (5) We check whether we've reached our time quota. If we have,
>> 2282:   // then we abort.
>> 2283:   double elapsed_time_ms = (double)(curr_time_ns - _start_cpu_time_ns) / NANOSECS_PER_MILLISEC;
> 
> Maybe there should be a helper for this calculation, since there are several occurrences of it?

I considered a helper, but could not find a good name. 

There is `nanos_to_millis()`, but it truncates the result (using integer division).

Do you have a suggestion?

> src/hotspot/share/gc/g1/g1RemSetSummary.cpp line 47:
> 
>> 45:     virtual void do_thread(Thread* t) {
>> 46:       G1ConcurrentRefineThread* crt = static_cast<G1ConcurrentRefineThread*>(t);
>> 47:       _summary->set_rs_thread_vtime(_counter, crt->cpu_time_s());
> 
> There's still a bunch of "vtime" nomenclature in this file. Is the plan to clean that up later?

I originally wanted to clean this up later, but added it now as I changed the internal time base to ns too. There is some additional cleanup about the `HRRSIter` class, I filed an issue for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26001#discussion_r2171420856
PR Review Comment: https://git.openjdk.org/jdk/pull/26001#discussion_r2171422301

From tschatzl at openjdk.org  Fri Jun 27 09:48:06 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 27 Jun 2025 09:48:06 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime() [v3]
In-Reply-To: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
Message-ID: <tGWA9VXEfR4MSinKfuL6VubXgi4KcE3F1WVPUWBkUKs=.fd881eec-e9af-440e-9426-8ce53eeb818a@github.com>

> Hi all,
> 
>   please review this change that removes the `*vtime()` methods from G1, replacing them with the appropriate `os::thread_cpu_time()` calls. They completely supersede the former ones.
> 
> Further I made support for `os::thread_cpu_time()` mandatory for G1, it will fail if not available. All platforms implement them, only non-OSX *BSD do not in mainline sources. However in the [official fork](https://github.com/freebsd/openjdk/blob/jdk24u-freebsd/src/hotspot/os/bsd/os_bsd.cpp#L2609) it already does.
> 
> There are upstreaming efforts underway too, so I do not see this as blocker for this behavior. 
> 
> One other change is that the various getters directly use the time returned by the OS function as cpu time, only counting the main work (marking steps, actual refinement) as used cpu time. I do not think this is honest to discount random cpu time spent in other work these threads must do (like getting to and leaving the main work described above).
> 
> There has been some effort to make naming a bit more consistent: cpu times were all named with `_cpu_time` with all non-standard units that unit appended (`_s`for seconds and so on).
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

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

  * more kbarrett review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26001/files
  - new: https://git.openjdk.org/jdk/pull/26001/files/9662ba1e..8e303735

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

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

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

From tschatzl at openjdk.org  Fri Jun 27 11:02:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 27 Jun 2025 11:02:40 GMT
Subject: RFR: 8342382: Implementation of JEP G1: Improve Application
 Throughput with a More Efficient Write-Barrier [v40]
In-Reply-To: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
References: <tt7smwtk5Lj4CC0R41IyWe6aLXA2JZPrJT3Bq1ILHr0=.abd86704-19f0-4350-b218-184ee0917f1f@github.com>
Message-ID: <gB2HyEd9IBluICZZ_ZseDVPjimtNBeKkiX7DJYmhEJw=.ebb6e9a5-13aa-4664-b9cb-46bb383419dd@github.com>

> Hi all,
> 
>   please review this change that implements (currently Draft) JEP: G1: Improve Application Throughput with a More Efficient Write-Barrier.
> 
> The reason for posting this early is that this is a large change, and the JEP process is already taking very long with no end in sight but we would like to have this ready by JDK 25.
> 
> ### Current situation
> 
> With this change, G1 will reduce the post write barrier to much more resemble Parallel GC's as described in the JEP. The reason is that G1 lacks in throughput compared to Parallel/Serial GC due to larger barrier.
> 
> The main reason for the current barrier is how g1 implements concurrent refinement:
> * g1 tracks dirtied cards using sets (dirty card queue set - dcqs) of buffers (dirty card queues - dcq) containing the location of dirtied cards. Refinement threads pick up their contents to re-refine. The barrier needs to enqueue card locations.
> * For correctness dirty card updates requires fine-grained synchronization between mutator and refinement threads,
> * Finally there is generic code to avoid dirtying cards altogether (filters), to avoid executing the synchronization and the enqueuing as much as possible.
> 
> These tasks require the current barrier to look as follows for an assignment `x.a = y` in pseudo code:
> 
> 
> // Filtering
> if (region(@x.a) == region(y)) goto done; // same region check
> if (y == null) goto done;     // null value check
> if (card(@x.a) == young_card) goto done;  // write to young gen check
> StoreLoad;                // synchronize
> if (card(@x.a) == dirty_card) goto done;
> 
> *card(@x.a) = dirty
> 
> // Card tracking
> enqueue(card-address(@x.a)) into thread-local-dcq;
> if (thread-local-dcq is not full) goto done;
> 
> call runtime to move thread-local-dcq into dcqs
> 
> done:
> 
> 
> Overall this post-write barrier alone is in the range of 40-50 total instructions, compared to three or four(!) for parallel and serial gc.
> 
> The large size of the inlined barrier not only has a large code footprint, but also prevents some compiler optimizations like loop unrolling or inlining.
> 
> There are several papers showing that this barrier alone can decrease throughput by 10-20% ([Yang12](https://dl.acm.org/doi/10.1145/2426642.2259004)), which is corroborated by some benchmarks (see links).
> 
> The main idea for this change is to not use fine-grained synchronization between refinement and mutator threads, but coarse grained based on atomically switching card tables. Mutators only work on the "primary" card table, refinement threads on a se...

Thomas Schatzl 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 branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review: remove sweep_epoch
 - Merge branch 'master' into card-table-as-dcq-merge
 - Merge branch 'master' into 8342382-card-table-instead-of-dcq
 - * ayang review (part 2 - yield duration changes)
 - * ayang review (part 1)
 - * indentation fix
 - * remove support for 32 bit x86 in the barrier generation code, following latest changes from @shade
 - ... and 46 more: https://git.openjdk.org/jdk/compare/aa26cede...750ed2d0

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

Changes: https://git.openjdk.org/jdk/pull/23739/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23739&range=39
  Stats: 7085 lines in 111 files changed: 2568 ins; 3599 del; 918 mod
  Patch: https://git.openjdk.org/jdk/pull/23739.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23739/head:pull/23739

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

From mdoerr at openjdk.org  Fri Jun 27 13:02:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 27 Jun 2025 13:02:47 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
 <lepaOQS2Lr_TCf8YBIZemOrEsHSDAy4WZeg5WYiv5q0=.a0e322d0-d854-4d41-ae06-2eba9fd59e51@github.com>
 <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com>
Message-ID: <TWIcaBQMluxnlyAaXKisX99tGaQvY1VUR9NzjWZIhsY=.c8743a6e-3fa4-4d5c-a939-98926e67e941@github.com>

On Tue, 24 Jun 2025 16:13:26 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Just FYI: My local tier1-3 test on linux-riscv64 is good. And I didn't witness an obvious change on specjbb performance with g1gc.
>
> Thanks @RealFYang.

@dean-long: Are you planning to do a jdk25 backport? We still see the crashes, there.

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3013002469

From kbarrett at openjdk.org  Fri Jun 27 14:17:40 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 27 Jun 2025 14:17:40 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime() [v3]
In-Reply-To: <tGWA9VXEfR4MSinKfuL6VubXgi4KcE3F1WVPUWBkUKs=.fd881eec-e9af-440e-9426-8ce53eeb818a@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
 <tGWA9VXEfR4MSinKfuL6VubXgi4KcE3F1WVPUWBkUKs=.fd881eec-e9af-440e-9426-8ce53eeb818a@github.com>
Message-ID: <uLvISV84C3TkwN0lA-p4X-nc2FdrSspJR4xhw-6uVuo=.7cf862ff-87cb-408f-9d6f-9d1eb7195283@github.com>

On Fri, 27 Jun 2025 09:48:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that removes the `*vtime()` methods from G1, replacing them with the appropriate `os::thread_cpu_time()` calls. They completely supersede the former ones.
>> 
>> Further I made support for `os::thread_cpu_time()` mandatory for G1, it will fail if not available. All platforms implement them, only non-OSX *BSD do not in mainline sources. However in the [official fork](https://github.com/freebsd/openjdk/blob/jdk24u-freebsd/src/hotspot/os/bsd/os_bsd.cpp#L2609) it already does.
>> 
>> There are upstreaming efforts underway too, so I do not see this as blocker for this behavior. 
>> 
>> One other change is that the various getters directly use the time returned by the OS function as cpu time, only counting the main work (marking steps, actual refinement) as used cpu time. I do not think this is honest to discount random cpu time spent in other work these threads must do (like getting to and leaving the main work described above).
>> 
>> There has been some effort to make naming a bit more consistent: cpu times were all named with `_cpu_time` with all non-standard units that unit appended (`_s`for seconds and so on).
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * more kbarrett review

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26001#pullrequestreview-2966751660

From kirk at kodewerk.com  Fri Jun 27 14:40:33 2025
From: kirk at kodewerk.com (Kirk Pepperdine)
Date: Fri, 27 Jun 2025 07:40:33 -0700
Subject: RFC: JEP draft: Automatic Heap Sizing for G1
In-Reply-To: <ec32ed1d-7b5b-4085-b572-10711cd328bc@oracle.com>
References: <ec32ed1d-7b5b-4085-b572-10711cd328bc@oracle.com>
Message-ID: <4CD04E2B-1171-4DD7-9C65-F38572867F97@kodewerk.com>

Hi Thomas,

I like the proposal. The only questions I have is with regards to the section on "Responding to machine memory pressure? and testing. How do you see testing the features that respond to increased memory pressure?

Kind regards,
Kirk


> On Jun 26, 2025, at 12:45?AM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
> 
> Hi all,
> 
>  with this email I would like to collect feedback for the "Automatic Heap Sizing for G1" JEP draft I started writing recently [0].
> 
> The purpose of this JEP is to have G1 automatically and dynamically adapt the maximum heap size according to the environment.
> 
> We think there is fair possibility to complete the implementation by next JDK's feature complete date as the main preparatory change [1] is currently under review (fwiw, please chime in if interested, more feedback is always appreciated).
> 
> G1 AHS is somewhat different to ZGC's Automatic Heap Sizing proposal as part of the functionality proposed there has already been available in G1 for a long time.
> 
> It should be fairly complete, although I'm still a bit conflicted about the usefulness of the proposed G1GCIntensity flag, but we can always change that area as needed.
> 
> Thanks,
>  Thomas
> 
> [0] https://bugs.openjdk.org/browse/JDK-8359211
> [1] https://bugs.openjdk.org/browse/JDK-8238687 / https://git.openjdk.org/jdk/pull/25832
> 


From tschatzl at openjdk.org  Fri Jun 27 15:33:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 27 Jun 2025 15:33:44 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v5]
In-Reply-To: <nTRw067Cwg5E0OzKWYk-_otrLPP79Nc9z3OXvh5euIg=.35fe762f-9ce1-4d56-81d6-5608f3b97e9d@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <nTRw067Cwg5E0OzKWYk-_otrLPP79Nc9z3OXvh5euIg=.35fe762f-9ce1-4d56-81d6-5608f3b97e9d@github.com>
Message-ID: <9v1jBPYDFtMgYobu23T98bBXDSXRks8QJg67QB-z7K4=.1cd915ad-2ada-4282-a14e-e44f04af751c@github.com>

On Thu, 26 Jun 2025 13:28:13 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reviews

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 104:

> 102: }
> 103: 
> 104: // Computes a smooth scaling factor based on the relative deviation of observed gc_cpu_usage

Typically the code uses "actual" instead of "observed". There are also a few "current" `gc_cpu_usage`thrown in. If possible, it would be nice to harmonize usage in the documentation.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 129:

> 127: //
> 128: // This helps avoid overreacting to small gc_cpu_usage deviations but respond appropriately
> 129: // when necessary.

This sentence seems to be a repeat of the one above ("This ensures appropriate heap resizing when deviations become significant, while avoiding overreacting to minor deviations.")

I would remove the first occurrence (maybe keeping the first version).

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 151:

> 149:   size_t uncommitted_bytes = reserved_bytes - committed_bytes;
> 150:   size_t expand_bytes_via_pct =
> 151:     uncommitted_bytes * G1ExpandByPercentOfAvailable / 100;

I think this linebreak is unnecessary, feel free to keep though.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 190:

> 188:   uint target_regions_to_shrink = _g1h->num_free_regions();
> 189: 
> 190:   uint reserve_regions = ceil(_g1h->num_committed_regions() * G1ReservePercent / 100.0);

This is unused except for the log message. I think we once discussed this value, and removed its use because we did not know its reason. It should be removed completely, even from the log message.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.cpp line 268:

> 266: 
> 267:   log_debug(gc, ergo, heap)("Heap triggers: pauses-since-start: %u num-prev-pauses-for-heuristics: %u GC CPU usage deviation counter: %d",
> 268:                             _recent_cpu_usage_deltas.num(), long_term_count_limit(), _gc_cpu_usage_deviation_counter);

`pauses-since-start` is a misnomer, it's how many deltas were collectors; the second is a maximum (maybe print that once as precious log among other relevant information for this kind of ergonomics?).

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 49:

> 47: // If below that range, we decrement that counter, if above, we increment it.
> 48: // The intent of this mechanism is to filter short term events because heap sizing has
> 49: // some overhead.

I think that sentence should move just before the full collection handling description.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 54:

> 52: // if that counter reaches -G1CPUUsageShrinkThreshold we consider shrinking the heap.
> 53: //
> 54: // While doing so, we accumulate the relative difference to the gc_cpu_usage_target

`gc_cpu_usage_target` has not been defined before, although above mentions "the target GC CPU usage". It seems better to just use the words here too.

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 64:

> 62: // Long term behavior is solely managed by regularly comparing actual long term
> 63: // GC CPU usage with the boundaries of above range in regular long term intervals.
> 64: // If current long term GC CPU usage is outside, expand or shrink respectively.

Suggestion:

// If current long term GC CPU usage is different to the target, expand or shrink respectively.

src/hotspot/share/gc/g1/jvmFlagConstraintsG1.cpp line 215:

> 213: }
> 214: 
> 215: JVMFlag::Error gc_cpu_usage_threshold_healper(JVMFlagsEnum flagid,

Suggestion:

JVMFlag::Error gc_cpu_usage_threshold_helper(JVMFlagsEnum flagid,

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

PR Review: https://git.openjdk.org/jdk/pull/25832#pullrequestreview-2962629782
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2172058191
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2172065270
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2172066367
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2172071149
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2172080088
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2172040409
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2172043739
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2172045132
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2169389589

From kbarrett at openjdk.org  Fri Jun 27 16:01:59 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 27 Jun 2025 16:01:59 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v2]
In-Reply-To: <4vS-_mkRekfO37wyIhVEZnzCxVPPd-pnhzOdYmoM5dU=.2f73ea4f-807e-4da6-bc11-73560c2bf0ba@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
 <OlrGflKYJyNoMEDjx4b64QoZ57KCIe-70KqrJjSl29w=.0536c301-9441-4038-b5ae-bec57c248eb9@github.com>
 <KpPotFPojmVxhCyur_iTtame5aJnw7M2L4L7nc-MMCk=.4c02046f-9c1e-485d-b542-e817e96d9087@github.com>
 <4vS-_mkRekfO37wyIhVEZnzCxVPPd-pnhzOdYmoM5dU=.2f73ea4f-807e-4da6-bc11-73560c2bf0ba@github.com>
Message-ID: <MovJH3c6Jvcen6HFYDMv03c9Rasfgg4RaOGPmJVYArQ=.a9a77cb3-f4ef-43f2-87a7-422828924f81@github.com>

On Thu, 26 Jun 2025 09:35:40 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/referenceProcessor.cpp line 644:
>> 
>>> 642:     size_t remaining_to_move = move_all
>>> 643:       ? from_len
>>> 644:       : (from_len > avg_refs ? from_len - avg_refs : 0);
>> 
>> `move_all` is (now) only used in the immediately following complicated
>> conditional expression. I think this would be more readable as something like
>> 
>>   // If from_idx >= _num_queues, move all.
>>   // Otherwise, only move excess above avg_refs.
>>   size_t keep = 0;
>>   if (from_idx < _num_queues) {
>>     keep = MIN2(from_len, avg_refs);
>>   }
>>   size_t remaining_to_move = from_len - keep;
>
> I don't think so.
> 
> Your suggested comment:
> 
> 
> // If from_idx >= _num_queues, move all.
> // Otherwise, only move excess above avg_refs.
> 
> can almost directly map to the actual code:
> 
> 
>     size_t remaining_to_move = move_all
>       ? from_len
>       : (from_len > avg_refs ? from_len - avg_refs : 0);
> 
> 
> OTOH, the suggested snippet of using `keep` requires some thinking to connect the dots, IMO.

I find nested ternary conditional operators hard to parse, and I seem to not
be alone in that. Some style guides recommend against ternary conditional
operators at all, though I'm not of that camp. Others allow them but call out
nesting them as one kind of problematically complex form, which I agree with.

Perhaps this?


size_t remaining_to_move = move_all
    ? from_len
    : (from_len - MIN2(from_len, avg_refs));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25930#discussion_r2172338348

From iwalulya at openjdk.org  Fri Jun 27 16:56:17 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 27 Jun 2025 16:56:17 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v6]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <knhSsdsVInqshiHo_YhCDA-AwqMNpMAOQXpBWXAYKyg=.fa6e8ef7-f7ee-4392-a9fa-d9f4d0715c94@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Thomas Review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25832/files
  - new: https://git.openjdk.org/jdk/pull/25832/files/8781a113..1a566b0b

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

  Stats: 40 lines in 3 files changed: 5 ins; 12 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/25832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25832/head:pull/25832

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

From ayang at openjdk.org  Fri Jun 27 19:01:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 27 Jun 2025 19:01:38 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v4]
In-Reply-To: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
Message-ID: <9rBfmwlk3NgNPtcbwQduzm143Rj8JqZFPp2091Uo-EM=.06209243-d0d2-484f-84df-e73d8ba36926@github.com>

> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
> 
> 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:

 - Merge branch 'master' into ref-refactor
 - review
 - review
 - Merge branch 'master' into ref-refactor
 - Merge branch 'master' into ref-refactor
 - ref-refactor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25930/files
  - new: https://git.openjdk.org/jdk/pull/25930/files/85a857e7..33a30b95

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

  Stats: 4295 lines in 200 files changed: 2546 ins; 637 del; 1112 mod
  Patch: https://git.openjdk.org/jdk/pull/25930.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25930/head:pull/25930

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

From ayang at openjdk.org  Fri Jun 27 19:01:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 27 Jun 2025 19:01:39 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v2]
In-Reply-To: <MovJH3c6Jvcen6HFYDMv03c9Rasfgg4RaOGPmJVYArQ=.a9a77cb3-f4ef-43f2-87a7-422828924f81@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
 <OlrGflKYJyNoMEDjx4b64QoZ57KCIe-70KqrJjSl29w=.0536c301-9441-4038-b5ae-bec57c248eb9@github.com>
 <KpPotFPojmVxhCyur_iTtame5aJnw7M2L4L7nc-MMCk=.4c02046f-9c1e-485d-b542-e817e96d9087@github.com>
 <4vS-_mkRekfO37wyIhVEZnzCxVPPd-pnhzOdYmoM5dU=.2f73ea4f-807e-4da6-bc11-73560c2bf0ba@github.com>
 <MovJH3c6Jvcen6HFYDMv03c9Rasfgg4RaOGPmJVYArQ=.a9a77cb3-f4ef-43f2-87a7-422828924f81@github.com>
Message-ID: <2_sarDy8tD9Xw1LqobbrjzuneQSXsaa6y99krWUSWv4=.47895511-a304-4ce9-8e58-12a9375f91ca@github.com>

On Fri, 27 Jun 2025 15:58:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I find nested ternary conditional operators hard to parse

OK; used `if` to remove the outer layer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25930#discussion_r2172685149

From dlong at openjdk.org  Fri Jun 27 21:22:57 2025
From: dlong at openjdk.org (Dean Long)
Date: Fri, 27 Jun 2025 21:22:57 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
 <lepaOQS2Lr_TCf8YBIZemOrEsHSDAy4WZeg5WYiv5q0=.a0e322d0-d854-4d41-ae06-2eba9fd59e51@github.com>
 <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com>
Message-ID: <z9Uj-c_D403nEasRNS3QBJFlCaJf89-zUBFJ14zEdIQ=.1c6d81e0-2012-4054-bad0-4e3b2ccebf4f@github.com>

On Tue, 24 Jun 2025 16:13:26 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Just FYI: My local tier1-3 test on linux-riscv64 is good. And I didn't witness an obvious change on specjbb performance with g1gc.
>
> Thanks @RealFYang.

> @dean-long: Are you planning to do a jdk25 backport? We still see the crashes, there.

I was going to let it bake in jdk26 for a while before deciding.  It seems a bit risky to me.  I am leaning towards not backporting it to Oracle JDK.  For OpenJDK 25, it might make more sense to do a PPC-specific fix like adding a NOP at the verified entry point.  What do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3014307981

From mdoerr at openjdk.org  Fri Jun 27 21:22:57 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 27 Jun 2025 21:22:57 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <z9Uj-c_D403nEasRNS3QBJFlCaJf89-zUBFJ14zEdIQ=.1c6d81e0-2012-4054-bad0-4e3b2ccebf4f@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
 <lepaOQS2Lr_TCf8YBIZemOrEsHSDAy4WZeg5WYiv5q0=.a0e322d0-d854-4d41-ae06-2eba9fd59e51@github.com>
 <2hLKCRKzNs19ZW_ntM7yJ2ynW0Hj7SwBrN9hlcOSxTM=.555bb43a-8fb4-4157-9cdb-a18b28178932@github.com>
 <z9Uj-c_D403nEasRNS3QBJFlCaJf89-zUBFJ14zEdIQ=.1c6d81e0-2012-4054-bad0-4e3b2ccebf4f@github.com>
Message-ID: <8NphJ347zBj0q5YG-K0Mq_vh9LPfhM_Jo-mcH94re3o=.0830a87e-7d9c-4907-86b2-c13a29893c7d@github.com>

On Fri, 27 Jun 2025 20:43:30 GMT, Dean Long <dlong at openjdk.org> wrote:

> > @dean-long: Are you planning to do a jdk25 backport? We still see the crashes, there.
> 
> I was going to let it bake in jdk26 for a while before deciding. It seems a bit risky to me. I am leaning towards not backporting it to Oracle JDK. For OpenJDK 25, it might make more sense to do a PPC-specific fix like adding a NOP at the verified entry point. What do you think?

I'm not convinced that only PPC64 is affected. [JDK-8258229](https://bugs.openjdk.org/browse/JDK-8258229) looks wrong for all platforms except x86 and may be even problematic on that platform as you had mentioned (due to NMethodState_lock). Would it make sense to backout JDK-8258229 in jdk25 and live with it? That issue doesn't look so critical.
Or maybe guard the code with #ifdef x86?

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

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3014360978

From kbarrett at openjdk.org  Sat Jun 28 01:17:48 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 28 Jun 2025 01:17:48 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v4]
In-Reply-To: <9rBfmwlk3NgNPtcbwQduzm143Rj8JqZFPp2091Uo-EM=.06209243-d0d2-484f-84df-e73d8ba36926@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
 <9rBfmwlk3NgNPtcbwQduzm143Rj8JqZFPp2091Uo-EM=.06209243-d0d2-484f-84df-e73d8ba36926@github.com>
Message-ID: <zWFkn9WXDGrKCCNrH7cIg-r2YsGfR7lgMSGyW_IXyLM=.c7c3297d-94ad-44df-9944-7240ee053a3e@github.com>

On Fri, 27 Jun 2025 19:01:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
>> 
>> 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:
> 
>  - Merge branch 'master' into ref-refactor
>  - review
>  - review
>  - Merge branch 'master' into ref-refactor
>  - Merge branch 'master' into ref-refactor
>  - ref-refactor

There's a small bit of code where @albertnetymk and I have some stylistic
differences, but they aren't so critical as to make me want to block this change.
Other parts of the change seem worthwhile.

src/hotspot/share/gc/shared/referenceProcessor.cpp line 645:

> 643:       remaining_to_move = from_len > avg_refs
> 644:                         ? from_len - avg_refs
> 645:                         : 0;

Continuing the discussion about this snippet.

I think that use of the ternary operator here looks weird to me, being
combined with the if-statement that way. I might write

size_t remaining_to_move = from_len;
if (from_idx < _num_queues) {
  if (from_len <= avg_refs) {
    remaining_to_move = 0;
  } else {
    remaining_to_move = from_len - avg_refs;
  }
}

or more likely

size_t remaining_to_move = from_len;
if (from_idx < _num_queues) {
  remaining_to_move -= MIN2(from_len, avg_refs);
}

The calculation in line 3 is an ancient and venerable idiom for "subtract,
clipping to non-negative".

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25930#pullrequestreview-2968296823
PR Review Comment: https://git.openjdk.org/jdk/pull/25930#discussion_r2173070770

From ayang at openjdk.org  Mon Jun 30 08:29:50 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 08:29:50 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots
Message-ID: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>

Refactor roots processing in Serial (young-gc and full-gc) to clean up the control-flow and make is clearer what roots and closures are used in each context.

Test: tier1-8

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

Commit messages:
 - sgc-roots

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

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

From ayang at openjdk.org  Mon Jun 30 08:42:17 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 08:42:17 GMT
Subject: RFR: 8361056: Parallel: Use correct is_par argument in
 ScavengeRootsTask
Message-ID: <TVTW4V_C_qEGLgomaiZjjn2JDFMqT3VNLhi8308t8f4=.e045344b-588b-46b4-bc7f-25ca9f7af485@github.com>

Trivial fixing the hardcoded `is_par` arg used during young-gc.

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

Commit messages:
 - pgc-trivial

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

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

From tschatzl at openjdk.org  Mon Jun 30 08:52:39 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 08:52:39 GMT
Subject: RFR: 8361056: Parallel: Use correct is_par argument in
 ScavengeRootsTask
In-Reply-To: <TVTW4V_C_qEGLgomaiZjjn2JDFMqT3VNLhi8308t8f4=.e045344b-588b-46b4-bc7f-25ca9f7af485@github.com>
References: <TVTW4V_C_qEGLgomaiZjjn2JDFMqT3VNLhi8308t8f4=.e045344b-588b-46b4-bc7f-25ca9f7af485@github.com>
Message-ID: <Jo-lnmh7cNQkUCOk6TGsabb3tvcfOfi0rGDz4TcJl_0=.d0341e85-1484-4b3d-b811-1aebf047f397@github.com>

On Mon, 30 Jun 2025 08:37:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial fixing the hardcoded `is_par` arg used during young-gc.

Nice catch.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26039#pullrequestreview-2970422135

From tschatzl at openjdk.org  Mon Jun 30 08:56:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 08:56:42 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots
In-Reply-To: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
Message-ID: <Tao3DTBDZYamstgrngOiPLNiKaCuaUChB-OnuMtjm90=.12932e74-7741-4ab9-8284-938e3c328cae@github.com>

On Mon, 30 Jun 2025 08:25:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Refactor roots processing in Serial (young-gc and full-gc) to clean up the control-flow and make is clearer what roots and closures are used in each context.
> 
> Test: tier1-8

Not really convinced about this change: if there is need to add a root now, you need to look at three places instead of one.
The parameter to select particular additional roots seems clear enough to me.

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

PR Review: https://git.openjdk.org/jdk/pull/26038#pullrequestreview-2970434177

From tschatzl at openjdk.org  Mon Jun 30 08:58:40 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 08:58:40 GMT
Subject: RFR: 8338474: Parallel: Deprecate and obsolete PSChunkLargeArrays
In-Reply-To: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
References: <1ZjYlg9V9HUV0H2Tk2222vuMl1rOAGJdSqFivaez1LU=.9f7213d9-34db-48c9-9faa-8e042eaadaf6@github.com>
Message-ID: <KrfkiA8Xd4JbjEImm3syI1yuUbCtPABhV-2A86tPNdE=.d1dff324-b67b-4e29-8195-6e6872ce9985@github.com>

On Thu, 26 Jun 2025 09:55:46 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Deprecating `PSChunkLargeArrays`, which is used only by Parallel and it is enabled by default.
> 
> Disabling it offers little benefit, so removing it do reduce the number of commandline flags.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25997#pullrequestreview-2970441071

From stefank at openjdk.org  Mon Jun 30 08:59:40 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 30 Jun 2025 08:59:40 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots
In-Reply-To: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
Message-ID: <FG0aAZ9B1COw_cnTO9-98VgzcmvMp31h9exjS1WHOdY=.6e7ab790-2ca8-4def-8553-13a1c98bf709@github.com>

On Mon, 30 Jun 2025 08:25:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Refactor roots processing in Serial (young-gc and full-gc) to clean up the control-flow and make is clearer what roots and closures are used in each context.
> 
> Test: tier1-8

Changes requested by stefank (Reviewer).

src/hotspot/share/gc/serial/defNewGeneration.cpp line 619:

> 617: 
> 618:     _old_gen->scan_old_to_young_refs(_old_gen->space()->top());
> 619:     // During young-gc, visit all (strong+weak) clds with the same closure.

Suggestion:

    _old_gen->scan_old_to_young_refs(_old_gen->space()->top());

    // During young-gc, visit all (strong+weak) clds with the same closure.


I also wonder if the previous placement of `scan_old_to_young_refs` after the other roots were intentional and this PR changes that?

src/hotspot/share/gc/serial/serialFullGC.cpp line 492:

> 490:                                             true);
> 491: 
> 492:     ClassLoaderDataGraph::always_strong_cld_do(&follow_cld_closure);

The old code treated `!ClassUnloading` differently. It's not clear to me why this change is correct.

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

PR Review: https://git.openjdk.org/jdk/pull/26038#pullrequestreview-2970440186
PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2174571747
PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2174574043

From ayang at openjdk.org  Mon Jun 30 09:16:40 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 09:16:40 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots
In-Reply-To: <FG0aAZ9B1COw_cnTO9-98VgzcmvMp31h9exjS1WHOdY=.6e7ab790-2ca8-4def-8553-13a1c98bf709@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <FG0aAZ9B1COw_cnTO9-98VgzcmvMp31h9exjS1WHOdY=.6e7ab790-2ca8-4def-8553-13a1c98bf709@github.com>
Message-ID: <g-3AW0eciN3nZes2e1kBsAL6awpS4YIkoSSr_wFjFQE=.cbee3225-10b0-46cf-91a3-a148c2e7b6d5@github.com>

On Mon, 30 Jun 2025 08:56:04 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Refactor roots processing in Serial (young-gc and full-gc) to clean up the control-flow and make is clearer what roots and closures are used in each context.
>> 
>> Test: tier1-8
>
> src/hotspot/share/gc/serial/defNewGeneration.cpp line 619:
> 
>> 617: 
>> 618:     _old_gen->scan_old_to_young_refs(_old_gen->space()->top());
>> 619:     // During young-gc, visit all (strong+weak) clds with the same closure.
> 
> Suggestion:
> 
>     _old_gen->scan_old_to_young_refs(_old_gen->space()->top());
> 
>     // During young-gc, visit all (strong+weak) clds with the same closure.
> 
> 
> I also wonder if the previous placement of `scan_old_to_young_refs` after the other roots were intentional and this PR changes that?

Both orderings are fine. (`ScavengeRootsTask` processes old-to-young pointers first). I changed that to avoid a local variable. Can revert it back if you prefers that.

> src/hotspot/share/gc/serial/serialFullGC.cpp line 492:
> 
>> 490:                                             true);
>> 491: 
>> 492:     ClassLoaderDataGraph::always_strong_cld_do(&follow_cld_closure);
> 
> The old code treated `!ClassUnloading` differently. It's not clear to me why this change is correct.

`always_strong_cld_do` does `ClassUnloading` checking internally.

Semantically, for full-gc marking, we process always-strong clds only. (Ofc, if class unloading is off, all clds are always-strong.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2174601186
PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2174607249

From ayang at openjdk.org  Mon Jun 30 09:22:39 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 09:22:39 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots
In-Reply-To: <Tao3DTBDZYamstgrngOiPLNiKaCuaUChB-OnuMtjm90=.12932e74-7741-4ab9-8284-938e3c328cae@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <Tao3DTBDZYamstgrngOiPLNiKaCuaUChB-OnuMtjm90=.12932e74-7741-4ab9-8284-938e3c328cae@github.com>
Message-ID: <bsao9ajZYHEZTJv3q_TqZv_Tr1KRQ1SVM8h9FA0vaLw=.c5773821-f1c8-4722-a9ba-600d689d8a21@github.com>

On Mon, 30 Jun 2025 08:54:07 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Not really convinced about this change: if there is need to add a root now, you need to look at three places instead of one.

That's true and IMO desirable. If a new kind of roots are added, we need to think carefully, how (young/old) gcs and different phases process it.

> The parameter to select particular additional roots seems clear enough to me.

Well, I guess it's different style. For example, with this refactoring (untanglement), I noticed that for young-gc, `Threads::oops_do` doesn't need the second argument (`nmethod_cl` can be set to null) to skip nmethod scanning. I suspect this redundancy will be hard to spot in the original style. (I will do that after this refactoring.)

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

PR Comment: https://git.openjdk.org/jdk/pull/26038#issuecomment-3018419173

From iwalulya at openjdk.org  Mon Jun 30 09:45:43 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 30 Jun 2025 09:45:43 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v17]
In-Reply-To: <lCCR-o-A90dC3X_RMzVp3lZ6ttwv-drSPIaAplMe9w0=.5bea2111-d462-4786-85b7-1ac516d1ad9a@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <lCCR-o-A90dC3X_RMzVp3lZ6ttwv-drSPIaAplMe9w0=.5bea2111-d462-4786-85b7-1ac516d1ad9a@github.com>
Message-ID: <QIkll-XpnhjdS3WJnSynfj90ithzeTtQimWZag7VXBE=.faaaf4e9-6db4-4212-9829-ebf8f0be0ee9@github.com>

On Thu, 26 Jun 2025 19:17:11 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits:
> 
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - cast
>  - remove-young-resize-after-full-gc
>  - Merge branch 'master' into pgc-size-policy
>  - Merge branch 'master' into pgc-size-policy
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - merge
>  - version
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/20e0055e...eeda1eb8

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 354:

> 352: 
> 353: static bool check_gc_heap_free_limit(size_t free_bytes, size_t capacity_bytes) {
> 354:   return free_bytes * 100 / capacity_bytes < GCHeapFreeLimit;

Suggestion:

  return (free_bytes * 100 / capacity_bytes) < GCHeapFreeLimit;

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 425:

> 423:   }
> 424: 
> 425:   if (check_gc_overhead_limit()) {

What is the effect of calling this method twice? Line 400 above, and then again here on line 425. Does that increment `_gc_overhead_counter` twice? More reason why i think the name is confusing.

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 756:

> 754: }
> 755: 
> 756: static size_t calculate_free_from_free_ratio_flag(size_t live, uintx free_percent) {

Why refer to the `free_ratio_flag` instead of just `calculate_free_from_free_percent`?

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

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2970469808
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174590762
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174637996
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174646534

From iwalulya at openjdk.org  Mon Jun 30 09:45:44 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 30 Jun 2025 09:45:44 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
Message-ID: <2kNEq2gNwn7YKpY5Wj5yAxyKS7J0I64hQ_snRWbPayQ=.b9e3d87e-cb04-423e-b56d-e7a722c16ed5@github.com>

On Mon, 19 May 2025 06:00:09 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 363:
>> 
>>> 361: }
>>> 362: 
>>> 363: bool ParallelScavengeHeap::check_gc_overhead_limit() {
>> 
>> In main-line code, the method `check_gc_overhead_limit` is invoked by `PSScavenge::invoke` and `PSParallelCompact::invoke_no_policy` so that we can do the check after all the GCs. But now you only use `check_gc_overhead_limit` in `ParallelScavengeHeap::satisfy_failed_allocation`. I suspect whether it can check the gc overhead limit accurately.
>
>> so that we can do the check after all the GCs
> 
> Well, not really. In the old impl, `GCOverheadChecker::check_gc_overhead_limit` calls `set_gc_overhead_limit_exceeded` only for full-gc.
> 
>  > But now you only use check_gc_overhead_limit in ParallelScavengeHeap::satisfy_failed_allocation. I suspect whether it can check the gc overhead limit accurately.
> 
> I believe so.  In the old impl, we don't check gc-overhead for explicit gcs. Only allocation-failure caused gcs are interesting, which all go through `satisfy_failed_allocation`.
> 
> 
>   // Ignore explicit GC's.  Exiting here does not set the flag and
>   // does not reset the count.
>   if (GCCause::is_user_requested_gc(gc_cause) ||
>       GCCause::is_serviceability_requested_gc(gc_cause)) {
>     return;
>   }

`check_gc_overhead_limit` does more than `check`, can we find a more appropriate method name?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174596366

From stefank at openjdk.org  Mon Jun 30 09:50:40 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 30 Jun 2025 09:50:40 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots
In-Reply-To: <g-3AW0eciN3nZes2e1kBsAL6awpS4YIkoSSr_wFjFQE=.cbee3225-10b0-46cf-91a3-a148c2e7b6d5@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <FG0aAZ9B1COw_cnTO9-98VgzcmvMp31h9exjS1WHOdY=.6e7ab790-2ca8-4def-8553-13a1c98bf709@github.com>
 <g-3AW0eciN3nZes2e1kBsAL6awpS4YIkoSSr_wFjFQE=.cbee3225-10b0-46cf-91a3-a148c2e7b6d5@github.com>
Message-ID: <UM5jKvGApizARKg9ShEUDG6A8y4ZeaiArJqaZmb365U=.c094ea39-5cbf-4b46-a752-ffa02557121d@github.com>

On Mon, 30 Jun 2025 09:10:55 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/defNewGeneration.cpp line 619:
>> 
>>> 617: 
>>> 618:     _old_gen->scan_old_to_young_refs(_old_gen->space()->top());
>>> 619:     // During young-gc, visit all (strong+weak) clds with the same closure.
>> 
>> Suggestion:
>> 
>>     _old_gen->scan_old_to_young_refs(_old_gen->space()->top());
>> 
>>     // During young-gc, visit all (strong+weak) clds with the same closure.
>> 
>> 
>> I also wonder if the previous placement of `scan_old_to_young_refs` after the other roots were intentional and this PR changes that?
>
> Both orderings are fine. (`ScavengeRootsTask` processes old-to-young pointers first). I changed that to avoid a local variable. Can revert it back if you prefers that.

OK. I understand. It could be worth adding a comment explaining that we're scanning objects that were old before relocation started. FWIW, if you want to keep it at the top then I think you can get rid of "_old_gen->space()->top()" from this function and extract it inside scan_old_to_young_refs instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2174674549

From stefank at openjdk.org  Mon Jun 30 09:54:44 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 30 Jun 2025 09:54:44 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots
In-Reply-To: <g-3AW0eciN3nZes2e1kBsAL6awpS4YIkoSSr_wFjFQE=.cbee3225-10b0-46cf-91a3-a148c2e7b6d5@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <FG0aAZ9B1COw_cnTO9-98VgzcmvMp31h9exjS1WHOdY=.6e7ab790-2ca8-4def-8553-13a1c98bf709@github.com>
 <g-3AW0eciN3nZes2e1kBsAL6awpS4YIkoSSr_wFjFQE=.cbee3225-10b0-46cf-91a3-a148c2e7b6d5@github.com>
Message-ID: <DIacRc16qp3djyxLGceM9FRitxfKyg7LDlr4eUHxzd4=.455b0aa4-60fd-439c-af20-2bead7950744@github.com>

On Mon, 30 Jun 2025 09:14:00 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/serial/serialFullGC.cpp line 492:
>> 
>>> 490:                                             true);
>>> 491: 
>>> 492:     ClassLoaderDataGraph::always_strong_cld_do(&follow_cld_closure);
>> 
>> The old code treated `!ClassUnloading` differently. It's not clear to me why this change is correct.
>
> `always_strong_cld_do` does `ClassUnloading` checking internally.
> 
> Semantically, for full-gc marking, we process always-strong clds only. (Ofc, if class unloading is off, all clds are always-strong.)

I see.

After having not looked at this for a while I find the "always" part of the name both redundant and even slightly misleading. This function could be named "strong_cld_do" (or even strong_clds_do, but the other functions are also miss the s). This could be a cleanup for the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2174683077

From stefank at openjdk.org  Mon Jun 30 09:58:37 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 30 Jun 2025 09:58:37 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots
In-Reply-To: <bsao9ajZYHEZTJv3q_TqZv_Tr1KRQ1SVM8h9FA0vaLw=.c5773821-f1c8-4722-a9ba-600d689d8a21@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <Tao3DTBDZYamstgrngOiPLNiKaCuaUChB-OnuMtjm90=.12932e74-7741-4ab9-8284-938e3c328cae@github.com>
 <bsao9ajZYHEZTJv3q_TqZv_Tr1KRQ1SVM8h9FA0vaLw=.c5773821-f1c8-4722-a9ba-600d689d8a21@github.com>
Message-ID: <8BXklj6QEYQszFeBkajTbQZCPsS1TDdt-pTF7UqqIKs=.fffcee34-9eaa-4823-bd17-911b9f36bc6e@github.com>

On Mon, 30 Jun 2025 09:20:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > Not really convinced about this change: if there is need to add a root now, you need to look at three places instead of one.
> 
> That's true and IMO desirable. If a new kind of roots are added, we need to think carefully, how (young/old) gcs and different phases process it.
> 
> > The parameter to select particular additional roots seems clear enough to me.
> 
> Well, I guess it's different style. For example, with this refactoring (untanglement), I noticed that for young-gc, `Threads::oops_do` doesn't need the second argument (`nmethod_cl` can be set to null) to skip nmethod scanning. I suspect this redundancy will be hard to spot in the original style. (I will do that after this refactoring.)

FWIW, I tend to like these kind of untanglements. We've gone back and forth w.r.t. the style in the root processors and making them more generic tends to make the code harder to understand, IMHO.

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

PR Comment: https://git.openjdk.org/jdk/pull/26038#issuecomment-3018529599

From ayang at openjdk.org  Mon Jun 30 10:17:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:17:11 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v18]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <0RXvJz_kUMWD8_XusZ0XrlrLQj9960i-iur1w5gpwF4=.b6323262-211a-4ae2-bd2f-1350f6b390ca@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - review
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - cast
 - remove-young-resize-after-full-gc
 - Merge branch 'master' into pgc-size-policy
 - Merge branch 'master' into pgc-size-policy
 - review
 - Merge branch 'master' into pgc-size-policy
 - ... and 17 more: https://git.openjdk.org/jdk/compare/c2d76f98...ec2e3908

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

Changes: https://git.openjdk.org/jdk/pull/25000/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25000&range=17
  Stats: 4362 lines in 31 files changed: 506 ins; 3470 del; 386 mod
  Patch: https://git.openjdk.org/jdk/pull/25000.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25000/head:pull/25000

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

From ayang at openjdk.org  Mon Jun 30 10:17:11 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:17:11 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v3]
In-Reply-To: <2kNEq2gNwn7YKpY5Wj5yAxyKS7J0I64hQ_snRWbPayQ=.b9e3d87e-cb04-423e-b56d-e7a722c16ed5@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <swWCrRm3BuXCwP8Vv7QvGGKZhlc70mqe3mtSg5lstX0=.e5920c86-5500-4468-8ba1-8020d0052b2e@github.com>
 <u8ZqFFJm0HQdM6N3dstyI66s-joQrZXLxMHTmiiDVXc=.d8376877-114d-472d-a5f9-aedc05116195@github.com>
 <RDcMR1RE88vwQM9Lfl6JFoqMnKT6SVBS4Iq0U0v9cWA=.d9d5e8d8-850a-4d15-997d-dac456b97501@github.com>
 <2kNEq2gNwn7YKpY5Wj5yAxyKS7J0I64hQ_snRWbPayQ=.b9e3d87e-cb04-423e-b56d-e7a722c16ed5@github.com>
Message-ID: <vmNHVwSYlfcV8wdqQzH5N6VgmJLiDwX1onT3570MKM8=.5d2a0fc1-bc17-468a-91b8-d538ff48d5ca@github.com>

On Mon, 30 Jun 2025 09:08:28 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>>> so that we can do the check after all the GCs
>> 
>> Well, not really. In the old impl, `GCOverheadChecker::check_gc_overhead_limit` calls `set_gc_overhead_limit_exceeded` only for full-gc.
>> 
>>  > But now you only use check_gc_overhead_limit in ParallelScavengeHeap::satisfy_failed_allocation. I suspect whether it can check the gc overhead limit accurately.
>> 
>> I believe so.  In the old impl, we don't check gc-overhead for explicit gcs. Only allocation-failure caused gcs are interesting, which all go through `satisfy_failed_allocation`.
>> 
>> 
>>   // Ignore explicit GC's.  Exiting here does not set the flag and
>>   // does not reset the count.
>>   if (GCCause::is_user_requested_gc(gc_cause) ||
>>       GCCause::is_serviceability_requested_gc(gc_cause)) {
>>     return;
>>   }
>
> `check_gc_overhead_limit` does more than `check`, can we find a more appropriate method name?

The only side-effect is mutating `_gc_overhead_counter`, which I believe is part of checking gc overhead limit. Do you have any names in mind?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174712372

From ayang at openjdk.org  Mon Jun 30 10:17:12 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:17:12 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v17]
In-Reply-To: <QIkll-XpnhjdS3WJnSynfj90ithzeTtQimWZag7VXBE=.faaaf4e9-6db4-4212-9829-ebf8f0be0ee9@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
 <lCCR-o-A90dC3X_RMzVp3lZ6ttwv-drSPIaAplMe9w0=.5bea2111-d462-4786-85b7-1ac516d1ad9a@github.com>
 <QIkll-XpnhjdS3WJnSynfj90ithzeTtQimWZag7VXBE=.faaaf4e9-6db4-4212-9829-ebf8f0be0ee9@github.com>
Message-ID: <p1dthm5Kd35YJTjcZ3NOudqQ_nnHR8KSaqc6nrI4vnk=.d2c02841-7a2d-4a5e-9c2d-2d7c0ba76728@github.com>

On Mon, 30 Jun 2025 09:29: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 pull request now contains 25 commits:
>> 
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - cast
>>  - remove-young-resize-after-full-gc
>>  - Merge branch 'master' into pgc-size-policy
>>  - Merge branch 'master' into pgc-size-policy
>>  - review
>>  - Merge branch 'master' into pgc-size-policy
>>  - merge
>>  - version
>>  - ... and 15 more: https://git.openjdk.org/jdk/compare/20e0055e...eeda1eb8
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 425:
> 
>> 423:   }
>> 424: 
>> 425:   if (check_gc_overhead_limit()) {
> 
> What is the effect of calling this method twice? Line 400 above, and then again here on line 425. Does that increment `_gc_overhead_counter` twice? More reason why i think the name is confusing.

This method checks after-gc gc-ratio and memory limit, so it is meant to be called after every (young/old) gc. (Increment `_gc_overhead_counter` is an impl detail, that is not visible at this abstraction level, IMO.)

> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 756:
> 
>> 754: }
>> 755: 
>> 756: static size_t calculate_free_from_free_ratio_flag(size_t live, uintx free_percent) {
> 
> Why refer to the `free_ratio_flag` instead of just `calculate_free_from_free_percent`?

It's mostly due to how the cmdline flag is named. See one of the callsite: `calculate_free_from_free_ratio_flag(old_gen_live_size, MinHeapFreeRatio);`.

I think this method can be renamed after the cmdline flag is renamed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174707957
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2174709739

From ayang at openjdk.org  Mon Jun 30 10:24:58 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:24:58 GMT
Subject: RFR: 8338977: Parallel: Improve heap resizing heuristics [v19]
In-Reply-To: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
References: <9-QvRzQoMkyGxgiTAFpkizJOG8unI4JYBLYu7gigMMQ=.7257790b-1a27-4925-b88a-87c03b3ea536@github.com>
Message-ID: <WogSr2fs28fgSLguuEazIeZuUXM3Tii2pTRSNtdk4MI=.18c048b9-f708-4916-8ec7-d7403ed96b91@github.com>

> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
> 
> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
> 
> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
> 
> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
> 
> ## Performance evaluation
> 
> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
> 
> PS: I have opportunistically set the obsolete/expired version to ~~25/26~~ 26/27 for now. I will update them accordingly before merging.
> 
> Test: tier1-8

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

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25000/files
  - new: https://git.openjdk.org/jdk/pull/25000/files/ec2e3908..d1ff874a

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

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

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

From ayang at openjdk.org  Mon Jun 30 10:30:21 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:30:21 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v2]
In-Reply-To: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
Message-ID: <AY5c7vx3q6Tl-MwbAeU7zk1o29zF4ek21kCE4IjZajI=.b81598ed-c6d5-416f-8ab3-f3eb63488b5c@github.com>

> Refactor roots processing in Serial (young-gc and full-gc) to clean up the control-flow and make is clearer what roots and closures are used in each context.
> 
> 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/26038/files
  - new: https://git.openjdk.org/jdk/pull/26038/files/6088695a..0743d5e5

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

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

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

From ayang at openjdk.org  Mon Jun 30 10:35:38 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:35:38 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v2]
In-Reply-To: <UM5jKvGApizARKg9ShEUDG6A8y4ZeaiArJqaZmb365U=.c094ea39-5cbf-4b46-a752-ffa02557121d@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <FG0aAZ9B1COw_cnTO9-98VgzcmvMp31h9exjS1WHOdY=.6e7ab790-2ca8-4def-8553-13a1c98bf709@github.com>
 <g-3AW0eciN3nZes2e1kBsAL6awpS4YIkoSSr_wFjFQE=.cbee3225-10b0-46cf-91a3-a148c2e7b6d5@github.com>
 <UM5jKvGApizARKg9ShEUDG6A8y4ZeaiArJqaZmb365U=.c094ea39-5cbf-4b46-a752-ffa02557121d@github.com>
Message-ID: <gy2IwIClW0CnFYPeicLC-B1GqjQwhoPM_mMh6rnRqDk=.a30f5da8-192a-413e-8506-863b42026364@github.com>

On Mon, 30 Jun 2025 09:48:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Both orderings are fine. (`ScavengeRootsTask` processes old-to-young pointers first). I changed that to avoid a local variable. Can revert it back if you prefers that.
>
> OK. I understand. It could be worth adding a comment explaining that we're scanning objects that were old before relocation started. FWIW, if you want to keep it at the top then I think you can get rid of "_old_gen->space()->top()" from this function and extract it inside scan_old_to_young_refs instead.

Added comment and inlined `space()->top()` to the callee.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26038#discussion_r2174759782

From ayang at openjdk.org  Mon Jun 30 10:59:37 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 30 Jun 2025 10:59:37 GMT
Subject: RFR: 8277394: Remove the use of safepoint_workers in reference
 processor
In-Reply-To: <RrtFq3ad8Biz9tWbHwGxvvpbkIBNoYjv9lfmbTeha4I=.869a5cea-cc0e-4205-a396-0519e8d4a277@github.com>
References: <RrtFq3ad8Biz9tWbHwGxvvpbkIBNoYjv9lfmbTeha4I=.869a5cea-cc0e-4205-a396-0519e8d4a277@github.com>
Message-ID: <UEG80rj5Gmb8znleol4lsr3g8kqRLLYjerzRHWQ1CAE=.f23f6692-b8e2-4455-89a8-7ed71991a93b@github.com>

On Thu, 26 Jun 2025 08:06:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this alternate implementation of 8277394. During the review of the first implementation (https://github.com/openjdk/jdk/pull/6453) the reviews did not like that the `WorkerThreads` were stashed away in the `ReferenceProcessor`.
> 
> This is an alternate implementation that implements the suggestion in the review comments, passing them along through the callers. While this requires a bit more changes, imo it better separates reference processor logic from the execution resources.
> 
> Testing: tier1-5
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25995#pullrequestreview-2970794601

From iwalulya at openjdk.org  Mon Jun 30 11:09:41 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 30 Jun 2025 11:09:41 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime() [v3]
In-Reply-To: <tGWA9VXEfR4MSinKfuL6VubXgi4KcE3F1WVPUWBkUKs=.fd881eec-e9af-440e-9426-8ce53eeb818a@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
 <tGWA9VXEfR4MSinKfuL6VubXgi4KcE3F1WVPUWBkUKs=.fd881eec-e9af-440e-9426-8ce53eeb818a@github.com>
Message-ID: <gYreHDBEW2xQb1sw5R1bAclYYH-GR9rQZE3ql8eAMv0=.596604d2-66da-4c67-9746-4a1d42140a6e@github.com>

On Fri, 27 Jun 2025 09:48:06 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that removes the `*vtime()` methods from G1, replacing them with the appropriate `os::thread_cpu_time()` calls. They completely supersede the former ones.
>> 
>> Further I made support for `os::thread_cpu_time()` mandatory for G1, it will fail if not available. All platforms implement them, only non-OSX *BSD do not in mainline sources. However in the [official fork](https://github.com/freebsd/openjdk/blob/jdk24u-freebsd/src/hotspot/os/bsd/os_bsd.cpp#L2609) it already does.
>> 
>> There are upstreaming efforts underway too, so I do not see this as blocker for this behavior. 
>> 
>> One other change is that the various getters directly use the time returned by the OS function as cpu time, only counting the main work (marking steps, actual refinement) as used cpu time. I do not think this is honest to discount random cpu time spent in other work these threads must do (like getting to and leaving the main work described above).
>> 
>> There has been some effort to make naming a bit more consistent: cpu times were all named with `_cpu_time` with all non-standard units that unit appended (`_s`for seconds and so on).
>> 
>> Testing: tier1-3
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   * more kbarrett review

LGTM!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26001#pullrequestreview-2970822285

From tschatzl at openjdk.org  Mon Jun 30 11:25:44 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 11:25:44 GMT
Subject: RFR: 8274051: Remove supports_vtime()/elapsedVTime() [v3]
In-Reply-To: <gYreHDBEW2xQb1sw5R1bAclYYH-GR9rQZE3ql8eAMv0=.596604d2-66da-4c67-9746-4a1d42140a6e@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
 <tGWA9VXEfR4MSinKfuL6VubXgi4KcE3F1WVPUWBkUKs=.fd881eec-e9af-440e-9426-8ce53eeb818a@github.com>
 <gYreHDBEW2xQb1sw5R1bAclYYH-GR9rQZE3ql8eAMv0=.596604d2-66da-4c67-9746-4a1d42140a6e@github.com>
Message-ID: <lamZCIB7dTnt2hnTxh7IsmGju1meq13tvTmDRUDUahg=.ebbf5899-5bef-4a4e-8824-7a2ef75431aa@github.com>

On Mon, 30 Jun 2025 11:07:31 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 kbarrett review
>
> LGTM!

Thanks @walulyai @kimbarrett for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/26001#issuecomment-3018777552

From tschatzl at openjdk.org  Mon Jun 30 11:25:45 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 11:25:45 GMT
Subject: Integrated: 8274051: Remove supports_vtime()/elapsedVTime()
In-Reply-To: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
References: <S6_-fW_VV2xJZj0DNkEKyHeWaY-JBa8hKt4uNNFkfqs=.22358380-27c2-4c12-9212-4b5138dc1e01@github.com>
Message-ID: <MvIZw_JdQ_pcpffDpPHn6UaEJPiO8EJtFjrd36JUf1k=.d55efe88-19e9-4f2d-83fd-6d85f0ea9020@github.com>

On Thu, 26 Jun 2025 12:53:37 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that removes the `*vtime()` methods from G1, replacing them with the appropriate `os::thread_cpu_time()` calls. They completely supersede the former ones.
> 
> Further I made support for `os::thread_cpu_time()` mandatory for G1, it will fail if not available. All platforms implement them, only non-OSX *BSD do not in mainline sources. However in the [official fork](https://github.com/freebsd/openjdk/blob/jdk24u-freebsd/src/hotspot/os/bsd/os_bsd.cpp#L2609) it already does.
> 
> There are upstreaming efforts underway too, so I do not see this as blocker for this behavior. 
> 
> One other change is that the various getters directly use the time returned by the OS function as cpu time, only counting the main work (marking steps, actual refinement) as used cpu time. I do not think this is honest to discount random cpu time spent in other work these threads must do (like getting to and leaving the main work described above).
> 
> There has been some effort to make naming a bit more consistent: cpu times were all named with `_cpu_time` with all non-standard units that unit appended (`_s`for seconds and so on).
> 
> Testing: tier1-3
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 00adbbe5
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/00adbbe5538ec5c26dc5bd17ca94cc29db9bc478
Stats:     221 lines in 19 files changed: 29 ins; 99 del; 93 mod

8274051: Remove supports_vtime()/elapsedVTime()

Reviewed-by: kbarrett, iwalulya

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

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

From tschatzl at openjdk.org  Mon Jun 30 11:36:49 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 11:36:49 GMT
Subject: RFR: 8360790: G1: Improve HRRSStatsIter name
Message-ID: <us20YzLggddyDsPIb9n4AC2LtKSXSly6dRV7hC02YMw=.36197243-27ed-4ce3-ba2e-7f8cbc25f7cd@github.com>

Hi all,

  please review this change that changes the names of some internal classes related to remembered set summaries to use the G1 prefix.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - 8360790

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

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

From stefank at openjdk.org  Mon Jun 30 11:49:38 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 30 Jun 2025 11:49:38 GMT
Subject: RFR: 8361055: Serial: Inline SerialHeap::process_roots [v2]
In-Reply-To: <AY5c7vx3q6Tl-MwbAeU7zk1o29zF4ek21kCE4IjZajI=.b81598ed-c6d5-416f-8ab3-f3eb63488b5c@github.com>
References: <JBY_dQRC7EPM71Ng1XAD1s4_VZ4E6PBjd6wbf26qVV4=.5b195f95-f6df-4bc1-8fb0-07b8da94ae64@github.com>
 <AY5c7vx3q6Tl-MwbAeU7zk1o29zF4ek21kCE4IjZajI=.b81598ed-c6d5-416f-8ab3-f3eb63488b5c@github.com>
Message-ID: <xkPn9kh0cs4EQPGbFCDnSeTAnKJKIWBMS_7DJ516tKc=.6ec4b3b4-481c-45ba-8fb5-3b99f00ed722@github.com>

On Mon, 30 Jun 2025 10:30:21 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Refactor roots processing in Serial (young-gc and full-gc) to clean up the control-flow and make is clearer what roots and closures are used in each context.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

To me this is OK. I'll leave it up to you and other reviewers to determine if this change should be made or not.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26038#pullrequestreview-2970926768

From iwalulya at openjdk.org  Mon Jun 30 11:52:53 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 30 Jun 2025 11:52:53 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v7]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <wvFgPwHXhaVoGjrR0oOX6axoHornQ6I2ATI88LWbgWU=.78f7adac-26ae-4842-9875-bae2195948b0@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya 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 remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
 - Thomas Review
 - Reviews
 - Albert suggestions
 - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
 - remove unrequired changes - kim
 - clean init

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

Changes: https://git.openjdk.org/jdk/pull/25832/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25832&range=06
  Stats: 614 lines in 16 files changed: 391 ins; 89 del; 134 mod
  Patch: https://git.openjdk.org/jdk/pull/25832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25832/head:pull/25832

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

From tschatzl at openjdk.org  Mon Jun 30 11:52:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 11:52:53 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v7]
In-Reply-To: <wvFgPwHXhaVoGjrR0oOX6axoHornQ6I2ATI88LWbgWU=.78f7adac-26ae-4842-9875-bae2195948b0@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <wvFgPwHXhaVoGjrR0oOX6axoHornQ6I2ATI88LWbgWU=.78f7adac-26ae-4842-9875-bae2195948b0@github.com>
Message-ID: <0jZZt3phd8r5aQfkOh6bz6za8YO9jXSBCWO2vWU6kqM=.0365799f-b476-4df3-854d-7a0c9b825b57@github.com>

On Mon, 30 Jun 2025 11:49:52 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya 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 remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
>  - Thomas Review
>  - Reviews
>  - Albert suggestions
>  - Merge remote-tracking branch 'upstream/master' into G1HeapResizePolicyV2
>  - remove unrequired changes - kim
>  - clean init

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25832#pullrequestreview-2970897593

From tschatzl at openjdk.org  Mon Jun 30 11:52:53 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 11:52:53 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v6]
In-Reply-To: <knhSsdsVInqshiHo_YhCDA-AwqMNpMAOQXpBWXAYKyg=.fa6e8ef7-f7ee-4392-a9fa-d9f4d0715c94@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <knhSsdsVInqshiHo_YhCDA-AwqMNpMAOQXpBWXAYKyg=.fa6e8ef7-f7ee-4392-a9fa-d9f4d0715c94@github.com>
Message-ID: <5tEew3q15QHfXmaXXLkVBcvVb1n3lp33blutHPNnrfo=.a724ffff-bc4c-4d57-adc1-11ccc2896e5a@github.com>

On Fri, 27 Jun 2025 16:56:17 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas Review

src/hotspot/share/gc/g1/g1HeapSizingPolicy.hpp line 80:

> 78:   uint _long_term_count;
> 79: 
> 80:   // Clear GC CPU usage tracking data used by resize_amount().

Suggestion:

  // Clear GC CPU usage tracking data used by *resize_amount().

src/hotspot/share/gc/g1/g1_globals.hpp line 177:

> 175:           range(0, 100)                                                     \
> 176:                                                                             \
> 177:   product(uint, G1CPUUsageExpandThreshold, 4, DIAGNOSTIC,                   \

This, and `G1CPUUsageShrinkThreshold` need to have a range attached to it - if it is set to `0`, I think expansion won't work well initially.

E.g. if set to 0, `_gc_cpu_usage_deviation_counter` will be initialized to 1, and since we compare with `==` in the code


  if ((_gc_cpu_usage_deviation_counter == (int)G1CPUUsageExpandThreshold) ||
      (use_long_term_delta && (long_term_gc_cpu_usage > upper_threshold))) {


the first term will not fire. Also, we increment `_gc_cpu_usage_deviation_counter` first, then compare.

So a `range(1, MAX_UINT)` should be added to both. Or make the comparison a `>=` or `<=` (for the shrinking).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2174864384
PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2174884973

From iwalulya at openjdk.org  Mon Jun 30 12:38:25 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 30 Jun 2025 12:38:25 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v8]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <hC74cpr1K3zqP-F9oQWmtOCaNPO14diUQhRzSeSj2aI=.35b27e18-20b3-4be0-a70f-576efe486741@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Thomas Review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25832/files
  - new: https://git.openjdk.org/jdk/pull/25832/files/9340422a..5997940f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25832&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25832&range=06-07

  Stats: 8 lines in 2 files changed: 1 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25832/head:pull/25832

PR: https://git.openjdk.org/jdk/pull/25832

From iwalulya at openjdk.org  Mon Jun 30 12:38:26 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 30 Jun 2025 12:38:26 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v6]
In-Reply-To: <5tEew3q15QHfXmaXXLkVBcvVb1n3lp33blutHPNnrfo=.a724ffff-bc4c-4d57-adc1-11ccc2896e5a@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <knhSsdsVInqshiHo_YhCDA-AwqMNpMAOQXpBWXAYKyg=.fa6e8ef7-f7ee-4392-a9fa-d9f4d0715c94@github.com>
 <5tEew3q15QHfXmaXXLkVBcvVb1n3lp33blutHPNnrfo=.a724ffff-bc4c-4d57-adc1-11ccc2896e5a@github.com>
Message-ID: <2OnR3JPN14mEAauGFmX_zUl4p8IDDQIosBZQDMbO6b4=.87abdef1-c9ca-47d0-9923-9d94ec505874@github.com>

On Mon, 30 Jun 2025 11:47:57 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Thomas Review
>
> src/hotspot/share/gc/g1/g1_globals.hpp line 177:
> 
>> 175:           range(0, 100)                                                     \
>> 176:                                                                             \
>> 177:   product(uint, G1CPUUsageExpandThreshold, 4, DIAGNOSTIC,                   \
> 
> This, and `G1CPUUsageShrinkThreshold` need to have a range attached to it - if it is set to `0`, I think expansion won't work well initially.
> 
> E.g. if set to 0, `_gc_cpu_usage_deviation_counter` will be initialized to 1, and since we compare with `==` in the code
> 
> 
>   if ((_gc_cpu_usage_deviation_counter == (int)G1CPUUsageExpandThreshold) ||
>       (use_long_term_delta && (long_term_gc_cpu_usage > upper_threshold))) {
> 
> 
> the first term will not fire. Also, we increment `_gc_cpu_usage_deviation_counter` first, then compare.
> 
> So a `range(1, MAX_UINT)` should be added to both. Or make the comparison a `>=` or `<=` (for the shrinking).

Resolved by improving the constraint function and also changing the comparisons to `G1CPUUsageExpandThreshold` and `G1CPUUsageShrinkThreshold`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25832#discussion_r2174970288

From iwalulya at openjdk.org  Mon Jun 30 12:42:11 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 30 Jun 2025 12:42:11 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v9]
In-Reply-To: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
Message-ID: <24IBqFegflzzJC1jB1t7LFUasQXD59KqTefhtGq71PU=.0dbe6333-bb7b-415f-aa68-b8eeede95627@github.com>

> Hi all,
> 
> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
> 
> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
> 
> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
> 
> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
> 
> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
> 
> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
> 
> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
> 
> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
> 
> Testing: Mach5 Tier 1-7

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25832/files
  - new: https://git.openjdk.org/jdk/pull/25832/files/5997940f..88434073

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25832&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25832&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/25832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25832/head:pull/25832

PR: https://git.openjdk.org/jdk/pull/25832

From tschatzl at openjdk.org  Mon Jun 30 13:30:42 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 13:30:42 GMT
Subject: RFR: 8238687: Investigate memory uncommit during young collections
 in G1 [v9]
In-Reply-To: <24IBqFegflzzJC1jB1t7LFUasQXD59KqTefhtGq71PU=.0dbe6333-bb7b-415f-aa68-b8eeede95627@github.com>
References: <JaMw3thrbYFyY43uzuOZvb4LJUbsEbOErJPFYEDd-qk=.cba0cdd8-1bb1-4d69-aaeb-4d27d198a701@github.com>
 <24IBqFegflzzJC1jB1t7LFUasQXD59KqTefhtGq71PU=.0dbe6333-bb7b-415f-aa68-b8eeede95627@github.com>
Message-ID: <WKUtOUUqjfLe_d4_iUUzx60BE_jFjGhfIFff5DCVUME=.6e082762-0dad-4866-878f-ab42a08e1926@github.com>

On Mon, 30 Jun 2025 12:42:11 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>> Please review this change to the G1 heap resizing policy, aimed at improving alignment with the configured GCTimeRatio. The GCTimeRatio is intended to manage the balance between GC time and Application execution time. G1's current implementation of GCTimeRatio appears to have drifted from its intended purpose over time.  Therefore, we need to change G1?s use of the GCTimeRatio to better manage heap sizes without relying on additional magic constants.
>> 
>> The primary goal is to enable both heap expansion and shrinking at the end of any GC, rather than limiting shrinking to only the Remark or Full GC pauses as is currently done. We achieve this using heuristics that monitor both short-term and long-term GC time ratios relative to the configured GCTimeRatio.
>> 
>> - The short-term policy adjusts a counter based on whether recent GC time is above or below a target range around GCTimeRatio (as defined by G1MinimumPercentOfGCTimeRatio). When the counter crosses predefined thresholds, the heap may be expanded or shrunk accordingly.
>> 
>> - The long-term policy evaluates the GC time ratio over a long-term interval and triggers resizing if the number of recorded ratios exceeds a threshold and the GC time ratio over the long-term interval is outside the target range.
>> 
>> - These heuristics allow for responsive heap resizing (both expansion and shrinking) at the end of any GC, guided by actual GC performance rather than fixed thresholds or constants.
>> 
>> We are increasing the default GCTimeRatio from 12 to 24, since under the new policy, the current default leads to overly aggressive heap shrinking as the GCTimeRatio allows for a lot more GC overhead.
>> 
>> Additionally, we are removing the heap resizing step at the end of the Remark pause which was based on MinHeapFreeRatio and MaxHeapFreeRatio. We keep this MinHeapFreeRatio-MaxHeapFreeRatio based resizing logic at the end of Full GC and Remark pauses that may have been triggered by PeriodicGCs.
>> 
>> As a result of these changes, some applications may settle at more appropriate and in some cases smaller heap sizes for the configured GCTimeRatio. While this may appear as a regression in some benchmarks that are sensitive to heap size, it represents more accurate G1 behavior with respect to the GCTimeRatio. Although smaller heap sizes may lead to more frequent GCs, this is the expected outcome, provided the cumulative GC overhead remains within the limits defined by the GCTimeRatio.
>> 
>> Testing: Mach5 ...
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment

Marked as reviewed by tschatzl (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/25832#pullrequestreview-2971240450

From duke at openjdk.org  Mon Jun 30 13:35:23 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 30 Jun 2025 13:35:23 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v10]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <QZ0mf-nkJxt6a72htydnCAEAcufC4lbxo8VzY8ZIODA=.cb19d2aa-d441-4c37-a3a8-78598df29ade@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
 - Implement CollectedHeap::before_exit() as suggested by @stefank
 - Remove incorrect is_gc_operation call after rebase
 - More clean up, remove virtual
 - Fixes after feedback from @stefank
 - Remove extra whitespace
 - operation_is_gc -> is_gc_operation per @stefank suggestion
 - Only sample if needed
 - Remove explicit super call and minor fixes
 - Add CPU time tracking for string deduplication to log_gc_vtime
 - ... and 8 more: https://git.openjdk.org/jdk/compare/aa191119...0993931f

-------------

Changes: https://git.openjdk.org/jdk/pull/25779/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=09
  Stats: 265 lines in 17 files changed: 253 ins; 7 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

PR: https://git.openjdk.org/jdk/pull/25779

From duke at openjdk.org  Mon Jun 30 13:35:23 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 30 Jun 2025 13:35:23 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v9]
In-Reply-To: <_FhdGlOiiWqN_Jpx_7kJZgamyXtgQTUw54t1w38SjxY=.609da7e0-39f9-4525-9836-b56a71c488f6@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <YLer4W0t8eLT5pUta2WCFfVYCdq7DwswRRFKwsUf0wo=.d4e61f23-d3fa-4523-b2e6-2575d1fb9cbd@github.com>
 <BgaYTXMTce7LBJAfqnll72hjJcuPmWZoSX6_aTXVLJM=.e1b38e72-51b6-4a87-97cd-e01d315050d3@github.com>
 <a3IxFvi_7KvwpMj86lxXp2iQFIRAHuINx4AK63kGGlA=.1a7c5dd9-7956-4da3-9a2e-fe860695fa4f@github.com>
 <_FhdGlOiiWqN_Jpx_7kJZgamyXtgQTUw54t1w38SjxY=.609da7e0-39f9-4525-9836-b56a71c488f6@github.com>
Message-ID: <ua18ykA5Js8-4EzFNQLC4gFQ-cBYdv3Up26LHuF70sk=.0cbaf8f5-6a22-4e81-9f3b-db2f42ced9c6@github.com>

On Mon, 23 Jun 2025 18:57:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I think it makes sense. We want to log the total GC CPU time before exiting. The latest point we can do that is right before we terminate threads, which we do in when we call `ConcurrentGCThread::stop`. I am open for any suggestions to rename `log_gc_vtime` in case that would help.
>
> I'd also prefer to see a small adjustment here. With this change all GCs have to add a back call to `CollectedHeap::stop()`. I think it makes the could a tiny bit less clean.
> 
> I wonder if an alternative could be to split `CollectedHeap::stop()` into two functions:
> 
> virtual void CollectedHeap::stop() = 0; // Now pure virtual
> 
> void CollectedHeap::before_exit() {
>   // Log GC CPU usage.
>   log_gc_vtime();
> 
>   // Stop any on-going concurrent work and prepare for exit.
>   stop();
> }
> 
> And revert the added calls to `CollectedHeap::stop()`.

That's a great suggestion, thanks! I have now implemented these changes :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175091875

From stefank at openjdk.org  Mon Jun 30 13:57:43 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 30 Jun 2025 13:57:43 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v10]
In-Reply-To: <QZ0mf-nkJxt6a72htydnCAEAcufC4lbxo8VzY8ZIODA=.cb19d2aa-d441-4c37-a3a8-78598df29ade@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <QZ0mf-nkJxt6a72htydnCAEAcufC4lbxo8VzY8ZIODA=.cb19d2aa-d441-4c37-a3a8-78598df29ade@github.com>
Message-ID: <A2aDx55_kkJ95h3-9ETNH3mUJVnVgeACUagfOzs3Eno=.2f9e522d-8488-4efa-a9dc-aa235bd8f815@github.com>

On Mon, 30 Jun 2025 13:35:23 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
>  - Implement CollectedHeap::before_exit() as suggested by @stefank
>  - Remove incorrect is_gc_operation call after rebase
>  - More clean up, remove virtual
>  - Fixes after feedback from @stefank
>  - Remove extra whitespace
>  - operation_is_gc -> is_gc_operation per @stefank suggestion
>  - Only sample if needed
>  - Remove explicit super call and minor fixes
>  - Add CPU time tracking for string deduplication to log_gc_vtime
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/aa191119...0993931f

I've listed a couple more nits.

Given that JDK-8274051 has now been integrated should the os::elapsedVTime be removed from this patch?

I know that we talked about the vtime name earlier. Should we still use the `vtime` name now that we have removed elapsedVTime?

src/hotspot/share/gc/shared/vtimeScope.hpp line 37:

> 35:   bool          _enabled;
> 36:   bool          _is_gc_operation;
> 37:   Thread*       _thread;

Suggestion:

  jlong   _start;
  bool    _enabled;
  bool    _is_gc_operation;
  Thread* _thread;

src/hotspot/share/gc/shared/vtimeScope.inline.hpp line 44:

> 42: 
> 43: inline VTimeScope::~VTimeScope() {
> 44:   if (!_enabled) return;

This is a style that most HotSpot GC devs try to avoid.
Suggestion:

  if (!_enabled) {
    return;
  }

-------------

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2971280145
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175108401
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175113990

From stefank at openjdk.org  Mon Jun 30 14:05:42 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 30 Jun 2025 14:05:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v10]
In-Reply-To: <QZ0mf-nkJxt6a72htydnCAEAcufC4lbxo8VzY8ZIODA=.cb19d2aa-d441-4c37-a3a8-78598df29ade@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <QZ0mf-nkJxt6a72htydnCAEAcufC4lbxo8VzY8ZIODA=.cb19d2aa-d441-4c37-a3a8-78598df29ade@github.com>
Message-ID: <t7VdJjXx_ImIyFO_Fie8f_EeNWnbW6Jn03XaZxyN_fU=.e31071d7-096f-4314-a1c7-0209b24cba2f@github.com>

On Mon, 30 Jun 2025 13:35:23 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
>> 
>> 
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>> 
>> 
>> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
>> 
>> 
>> [1.500s][trace][gc] Process CPU time: 4.945370s
>> [1.500s][trace][gc] GC CPU time: 0.086382s
>> [1.500s][info ][gc] GC CPU cost: 1.75%
>
> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
>  - Implement CollectedHeap::before_exit() as suggested by @stefank
>  - Remove incorrect is_gc_operation call after rebase
>  - More clean up, remove virtual
>  - Fixes after feedback from @stefank
>  - Remove extra whitespace
>  - operation_is_gc -> is_gc_operation per @stefank suggestion
>  - Only sample if needed
>  - Remove explicit super call and minor fixes
>  - Add CPU time tracking for string deduplication to log_gc_vtime
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/aa191119...0993931f

I missed that you hadn't changed this:

LogTarget(Info, gc) out;

I would prefer to see this getting moved over to gc+cpu (alt. gc+cpu+exit).

src/hotspot/share/gc/shared/collectedHeap.cpp line 70:

> 68: size_t CollectedHeap::_filler_array_max_size = 0;
> 69: size_t CollectedHeap::_stack_chunk_max_size = 0;
> 70: jlong  CollectedHeap::_vm_vtime = 0;

I'm not sure that the `vm` prefix is fitting for this name.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25779#pullrequestreview-2971365591
PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175161128

From duke at openjdk.org  Mon Jun 30 14:12:42 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 30 Jun 2025 14:12:42 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v10]
In-Reply-To: <t7VdJjXx_ImIyFO_Fie8f_EeNWnbW6Jn03XaZxyN_fU=.e31071d7-096f-4314-a1c7-0209b24cba2f@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <QZ0mf-nkJxt6a72htydnCAEAcufC4lbxo8VzY8ZIODA=.cb19d2aa-d441-4c37-a3a8-78598df29ade@github.com>
 <t7VdJjXx_ImIyFO_Fie8f_EeNWnbW6Jn03XaZxyN_fU=.e31071d7-096f-4314-a1c7-0209b24cba2f@github.com>
Message-ID: <M-dM8f887PeySV5t4UIUaVtOoTx7uYUaAcknFanaliA=.5e8cb341-0a44-4c61-9aeb-9d51b5ee42e2@github.com>

On Mon, 30 Jun 2025 14:02:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge branch 'master' of github.com:JonasNorlinder/openjdk_jdk into gc_cpu_time
>>  - Implement CollectedHeap::before_exit() as suggested by @stefank
>>  - Remove incorrect is_gc_operation call after rebase
>>  - More clean up, remove virtual
>>  - Fixes after feedback from @stefank
>>  - Remove extra whitespace
>>  - operation_is_gc -> is_gc_operation per @stefank suggestion
>>  - Only sample if needed
>>  - Remove explicit super call and minor fixes
>>  - Add CPU time tracking for string deduplication to log_gc_vtime
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/aa191119...0993931f
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 70:
> 
>> 68: size_t CollectedHeap::_filler_array_max_size = 0;
>> 69: size_t CollectedHeap::_stack_chunk_max_size = 0;
>> 70: jlong  CollectedHeap::_vm_vtime = 0;
> 
> I'm not sure that the `vm` prefix is fitting for this name.

It is the time we spend on doing GC activities inside the VM thread, hence `vm`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25779#discussion_r2175174704

From duke at openjdk.org  Mon Jun 30 14:26:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 30 Jun 2025 14:26:04 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v11]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <_zPHIAMLNTOQ4uZw_VlgM7i44DnasKtalJe0glruAn4=.4a5d505e-60db-479e-9d0f-718450846397@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fixes after review from @stefank

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/0993931f..293fbe95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=09-10

  Stats: 31 lines in 6 files changed: 2 ins; 23 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

PR: https://git.openjdk.org/jdk/pull/25779

From tschatzl at openjdk.org  Mon Jun 30 14:53:41 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 30 Jun 2025 14:53:41 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v10]
In-Reply-To: <A2aDx55_kkJ95h3-9ETNH3mUJVnVgeACUagfOzs3Eno=.2f9e522d-8488-4efa-a9dc-aa235bd8f815@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <QZ0mf-nkJxt6a72htydnCAEAcufC4lbxo8VzY8ZIODA=.cb19d2aa-d441-4c37-a3a8-78598df29ade@github.com>
 <A2aDx55_kkJ95h3-9ETNH3mUJVnVgeACUagfOzs3Eno=.2f9e522d-8488-4efa-a9dc-aa235bd8f815@github.com>
Message-ID: <E3koLs63-mDZ8gqeGfAnBuZY1pB8AO-P652AI1ML3kQ=.f80dfc12-fdb2-45ec-ad44-35d078934a06@github.com>

On Mon, 30 Jun 2025 13:55:24 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I've listed a couple more nits.
> 
> Given that JDK-8274051 has now been integrated should the os::elapsedVTime be removed from this patch?
> 
> I know that we talked about the vtime name earlier. Should we still use the `vtime` name now that we have removed elapsedVTime?

I concur with @stefank: we just removed `vtime` in other gc code, simply using `cpu_time`. 

`_vmthread_cpu_time` seems to be a lot more descriptive than `_vm_vtime`. At least add `thread` - the name of that thread is `VMThread` after all (as opposed to the whole VM what the current name implies to me).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3019468123

From sangheki at openjdk.org  Mon Jun 30 15:06:41 2025
From: sangheki at openjdk.org (Sangheon Kim)
Date: Mon, 30 Jun 2025 15:06:41 GMT
Subject: RFR: 8360206: Refactor ReferenceProcessor::balance_queues [v4]
In-Reply-To: <9rBfmwlk3NgNPtcbwQduzm143Rj8JqZFPp2091Uo-EM=.06209243-d0d2-484f-84df-e73d8ba36926@github.com>
References: <NAf03HLCGyr027180oyn9ODSu9sAinWUC8eXvv_jVeA=.19d4809a-7545-4b3f-8866-690e401900c0@github.com>
 <9rBfmwlk3NgNPtcbwQduzm143Rj8JqZFPp2091Uo-EM=.06209243-d0d2-484f-84df-e73d8ba36926@github.com>
Message-ID: <zbbsSJGDcCH8wd_NrMuehU_1ZR6WR49SY7UWosy4oxs=.4cbca40a-be16-4e06-9145-59e8e5435a1c@github.com>

On Fri, 27 Jun 2025 19:01:38 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to clean up the inner-loop conditions and control flow. Due to the structural change, the diff is slightly large and may be harder to read than the resulting code. The new version simplifies the logic by using a single `remaining_to_move` counter in the inner loop to track remaining work, and introduces early returns to reduce indentation and improve clarity.
>> 
>> 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:
> 
>  - Merge branch 'master' into ref-refactor
>  - review
>  - review
>  - Merge branch 'master' into ref-refactor
>  - Merge branch 'master' into ref-refactor
>  - ref-refactor

Looks good.

-------------

Marked as reviewed by sangheki (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25930#pullrequestreview-2971596942

From duke at openjdk.org  Mon Jun 30 15:58:07 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 30 Jun 2025 15:58:07 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v12]
In-Reply-To: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
Message-ID: <9THM_-ewp6IHKihx_AAHi2AjhG86B9tD7IvqtUIxUe8=.501655a3-77d4-4996-a340-9141bbf25154@github.com>

> Add support to log CPU cost for GC during VM exit with `-Xlog:gc`.
> 
> 
> [1.500s][info ][gc] GC CPU cost: 1.75%
> 
> 
> Additionally, detailed information may be retrieved with `-Xlog:gc=trace`
> 
> 
> [1.500s][trace][gc] Process CPU time: 4.945370s
> [1.500s][trace][gc] GC CPU time: 0.086382s
> [1.500s][info ][gc] GC CPU cost: 1.75%

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - Update closure name
 - vtime -> cpu_time and _vm_vtime -> _vmthread_cpu_time

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25779/files
  - new: https://git.openjdk.org/jdk/pull/25779/files/293fbe95..35a74668

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25779&range=10-11

  Stats: 234 lines in 12 files changed: 102 ins; 102 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/25779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25779/head:pull/25779

PR: https://git.openjdk.org/jdk/pull/25779

From duke at openjdk.org  Mon Jun 30 15:58:07 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 30 Jun 2025 15:58:07 GMT
Subject: RFR: 8359110: Log accumulated GC and process CPU time upon VM exit
 [v10]
In-Reply-To: <E3koLs63-mDZ8gqeGfAnBuZY1pB8AO-P652AI1ML3kQ=.f80dfc12-fdb2-45ec-ad44-35d078934a06@github.com>
References: <bsaXX9mRXUVYY5Z1vfMKZeuj9bwOsDXm4adiVcGFb-w=.0d3d4815-6f20-43a2-aeb1-1154865f7520@github.com>
 <QZ0mf-nkJxt6a72htydnCAEAcufC4lbxo8VzY8ZIODA=.cb19d2aa-d441-4c37-a3a8-78598df29ade@github.com>
 <A2aDx55_kkJ95h3-9ETNH3mUJVnVgeACUagfOzs3Eno=.2f9e522d-8488-4efa-a9dc-aa235bd8f815@github.com>
 <E3koLs63-mDZ8gqeGfAnBuZY1pB8AO-P652AI1ML3kQ=.f80dfc12-fdb2-45ec-ad44-35d078934a06@github.com>
Message-ID: <VIjFqk0Uk8TsvTdoIu6lTpA9WfAPN2ekigdU1qqZP4I=.d941aded-e7ec-45de-9db6-ff456b9c3faa@github.com>

On Mon, 30 Jun 2025 14:50:43 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> I've listed a couple more nits.
>> 
>> Given that JDK-8274051 has now been integrated should the os::elapsedVTime be removed from this patch?
>> 
>> I know that we talked about the vtime name earlier. Should we still use the `vtime` name now that we have removed elapsedVTime?
>
>> I've listed a couple more nits.
>> 
>> Given that JDK-8274051 has now been integrated should the os::elapsedVTime be removed from this patch?
>> 
>> I know that we talked about the vtime name earlier. Should we still use the `vtime` name now that we have removed elapsedVTime?
> 
> I concur with @stefank: we just removed `vtime` in other gc code, simply using `cpu_time`. 
> 
> `_vmthread_cpu_time` seems to be a lot more descriptive than `_vm_vtime`. At least add `thread` - the name of that thread is `VMThread` after all (as opposed to the whole VM what the current name implies to me).

Thanks @tschatzl, I have updated the PR with your suggestions

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25779#issuecomment-3019748061

From kbarrett at openjdk.org  Mon Jun 30 16:11:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 30 Jun 2025 16:11:39 GMT
Subject: RFR: 8360790: G1: Improve HRRSStatsIter name
In-Reply-To: <us20YzLggddyDsPIb9n4AC2LtKSXSly6dRV7hC02YMw=.36197243-27ed-4ce3-ba2e-7f8cbc25f7cd@github.com>
References: <us20YzLggddyDsPIb9n4AC2LtKSXSly6dRV7hC02YMw=.36197243-27ed-4ce3-ba2e-7f8cbc25f7cd@github.com>
Message-ID: <VIPjRQssHVQrpesG1ywBhFvOWRvwJTA9gYcYTnc7rvc=.13cd7ee6-cae0-4e54-bc3e-04b0edcd4263@github.com>

On Mon, 30 Jun 2025 11:32:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that changes the names of some internal classes related to remembered set summaries to use the G1 prefix.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

I particularly approve of HRRSStatsIter => G1HeapRegionStatsClosure.

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26042#pullrequestreview-2971862778

From wkemper at openjdk.org  Mon Jun 30 19:15:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Jun 2025 19:15:40 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v2]
In-Reply-To: <o1wfwjjIJEcEOxI7ZNeNapByyhJsEBi22iu2nDNm3Lw=.954ab02a-5582-4474-ae82-d9a64fa41123@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <o1wfwjjIJEcEOxI7ZNeNapByyhJsEBi22iu2nDNm3Lw=.954ab02a-5582-4474-ae82-d9a64fa41123@github.com>
Message-ID: <-6IGc4gDm8t7AEFTtRbpGXLvVXvsKm9QWGfLGaGU2ls=.8c897937-ab45-45f9-bb5d-9ec54fd99563@github.com>

On Wed, 25 Jun 2025 21:14:01 GMT, Rui Li <duke at openjdk.org> wrote:

>> Generational shenandoah currently doesn't pick up the changes of managed flag `SoftMaxHeapSize` when the app is running. This is because the value of `_soft_max_capacity` in `shenandoahGeneration` is never changed.
>> 
>> This change delegates the soft max heap size in `shenandoahGeneration` to `ShenandoahGenerationalHeap::heap()->soft_max_capacity()`, which does pick up the flag value changes.
>> 
>> Also, found `ShenandoahHeap:: initialize` uses `_num_regions * reg_size_bytes` rather than user input flag value. Updated to using actual flag value.
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   No need atomic load in initialization

Changes requested by wkemper (Reviewer).

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 1017:

> 1015: size_t ShenandoahGeneration::soft_max_capacity() const {
> 1016:   size_t capacity = ShenandoahGenerationalHeap::heap()->soft_max_capacity();
> 1017:   log_debug(gc)("soft_max_capacity: %zu", capacity); // TestDynamicSoftMaxHeapSize needs the log line to validate

This will be a hot method. It's called by the heuristic frequently to test if it should start a GC. We may also even test this on the allocation path. I'd rather not have a log level check here just for one test case. Can we move this log message to the place where the value is updated? I expect the value to change _much less_ frequently than it is read.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25943#pullrequestreview-2972355280
PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2175731624

From wkemper at openjdk.org  Mon Jun 30 19:15:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 30 Jun 2025 19:15:41 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v2]
In-Reply-To: <DHB0jkUkcL0UdSU6ZtTXc7gG4Mm2FPEBQ_n6c0JLdAA=.f31ec6e3-702e-4d29-9427-1fc68a1e90e5@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <o0HHvbjcpoCDhwCGETC2pCJxgJw1AmqnQqoaud0O1WI=.0f126d1d-a107-4a02-88e5-425819effcd3@github.com>
 <DHB0jkUkcL0UdSU6ZtTXc7gG4Mm2FPEBQ_n6c0JLdAA=.f31ec6e3-702e-4d29-9427-1fc68a1e90e5@github.com>
Message-ID: <CzbuQJC5aopf1rdH5AmEVp4OdUFCpbAnIBiVmQw9YI0=.11e113ca-948f-4935-b526-f25b5f8745c8@github.com>

On Mon, 23 Jun 2025 23:04:11 GMT, Rui Li <duke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 129:
>> 
>>> 127:   virtual ShenandoahHeuristics* initialize_heuristics(ShenandoahMode* gc_mode);
>>> 128: 
>>> 129:   size_t soft_max_capacity() const override;
>> 
>> Can we take out the `_soft_max_capacity` member from `ShenandoahGeneration` now?
>
> Yes. Good catch. Removed

I think we can cut deeper here. If `ShenandoahHeap` is now the sole source of truth for soft max heap size, can we remove the `soft_max_capacity` getter method from `ShenandoahGeneration` (and `ShenandoahSpaceInfo`)? All the callers can just get this value directly from `ShenandoahHeap` now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2175728375

From dlong at openjdk.org  Mon Jun 30 22:05:49 2025
From: dlong at openjdk.org (Dean Long)
Date: Mon, 30 Jun 2025 22:05:49 GMT
Subject: RFR: 8358821: patch_verified_entry causes problems,
 use nmethod entry barriers instead [v9]
In-Reply-To: <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
References: <MHl4gp-i7wvWlPIDFe-DgLkTdKsHdN5IMmKfqM62vOU=.77d172b7-3a83-4d6d-9b4e-6b580155088f@github.com>
 <V1R7QX7ECR-b4R9RafrckOzaQCZZlSOBvHqaixwEQcY=.8aef5d9b-5df2-40f6-b9d6-107f580fe907@github.com>
Message-ID: <Icjdyj4xjcDgCCrKOu0bMuKWXP2h6Y4uBJUbhshB1tk=.a00cc33c-eb3e-4c4e-9b87-6e78abc9ae92@github.com>

On Mon, 23 Jun 2025 19:26:11 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This PR removes patching of the verified entry point and related code, and replaces it by refactoring the existing nmethod entry barrier.
>> 
>> We used to patch the verified entry point to make sure it was not_entrant.  The patched entry point then redirected to SharedRuntime::handle_wrong_method(), either directly with a jump to a stub, or indirectly with an illegal instruction and the help of the signal handler.  The not_entrant state is a final state, so once an nmethod becomes not_entrant, it stays not_entrant.  We can do the same thing with a permanently armed nmethod entry barrier.
>> 
>> The solution I went with reserves one bit of the entry barrier guard value.  This bit must remain set, so I call it a "sticky" bit.  Setting the guard value now is effectively like setting a bitfield, so I needed to add a lock around it.  The alternative would be to change the platform-specific code to do compare-and-swap.
>> 
>> For the lock, I introduced a new NMethodEntryBarrier_lock, whose only purpose is to make the update to the guard value atomic.  For ZGC, I decided to use the existing per-nmethod lock ZNMethod::lock_for_nmethod().  I suspect we could do the same for Shenandoah, if needed for performance.
>> 
>> This change also makes it a bit clearer that  the nmethod entry barrier effectively has two levels.  Level 0 is the outer level or layer controlled by BarrierSetNMethod::nmethod_stub_entry_barrier(), and the inner layer controlled by BarrierSetNMethod::nmethod_entry_barrier().  This could be generalized if we decide we need more flavors of entry barriers.  The inner barrier is mostly ignorant of the fact that the outer guard is multiplexing for both levels.
>
> Dean Long has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Merge branch 'master' into 8358821-patch-verified-entry
>  - 2nd try at arm fix
>  - rename arm_with to guard_with
>  - arm32 fix
>  - s390 fix courtesy of Amit Kumar
>  - remove is_sigill_not_entrant
>  - more cleanup
>  - more TheRealMDoerr suggestions
>  - TheRealMDoerr suggestions
>  - remove trailing space
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/6df0f5e3...a39c458c

I would be OK with JDK-8258229 being backed out.  I sent a message to @mhaessig asking what he things.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25764#issuecomment-3020951767

From duke at openjdk.org  Mon Jun 30 23:04:39 2025
From: duke at openjdk.org (Rui Li)
Date: Mon, 30 Jun 2025 23:04:39 GMT
Subject: RFR: 8358529: GenShen: Heuristics do not respond to changes in
 SoftMaxHeapSize [v2]
In-Reply-To: <-6IGc4gDm8t7AEFTtRbpGXLvVXvsKm9QWGfLGaGU2ls=.8c897937-ab45-45f9-bb5d-9ec54fd99563@github.com>
References: <GmwmWQL-JmqgFmZYHD4gpQSOytIJFq6wg5STgwgQAqI=.e24b629c-d7e5-42ce-a471-44ba0715ce35@github.com>
 <o1wfwjjIJEcEOxI7ZNeNapByyhJsEBi22iu2nDNm3Lw=.954ab02a-5582-4474-ae82-d9a64fa41123@github.com>
 <-6IGc4gDm8t7AEFTtRbpGXLvVXvsKm9QWGfLGaGU2ls=.8c897937-ab45-45f9-bb5d-9ec54fd99563@github.com>
Message-ID: <0-_c2MpqhmXuv_rN3VHirKNVbqLn6Y-xEPk2Czj68GY=.af55e164-7565-4a7e-ab89-ffbb989b1401@github.com>

On Mon, 30 Jun 2025 19:12:32 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No need atomic load in initialization
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 1017:
> 
>> 1015: size_t ShenandoahGeneration::soft_max_capacity() const {
>> 1016:   size_t capacity = ShenandoahGenerationalHeap::heap()->soft_max_capacity();
>> 1017:   log_debug(gc)("soft_max_capacity: %zu", capacity); // TestDynamicSoftMaxHeapSize needs the log line to validate
> 
> This will be a hot method. It's called by the heuristic frequently to test if it should start a GC. We may also even test this on the allocation path. I'd rather not have a log level check here just for one test case. Can we move this log message to the place where the value is updated? I expect the value to change _much less_ frequently than it is read.

Agree that the debug log can be too much in the log and impact perf. There is an existing log when soft max is changed: [link](https://github.com/openjdk/jdk/blob/6df0f5e390ecf874c1eca7284c51efa65ce23737/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L865-L868). The problem is, before the fix, when the soft max was changed, gen shen  doesn't read the changed value. That's why I put a log here. Validating log is also indeed a bit fragile. If we remove the log, probably need to think another way to test.


For removing `soft_max_capacity`: not sure if I understand it right, but I thought `ShenandoahSpaceInfo` was the parent class in the polymorphism ([code](https://github.com/openjdk/jdk/blob/6df0f5e390ecf874c1eca7284c51efa65ce23737/src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp#L68)), so the code would work for both gen shen (ShenandoahGeneration) and ShenandoahGlobalGeneration? If we removed `soft_max_capacity ` from ShenandoahSpaceInfo, wouldn't that make heuristics not able to access soft max heap size?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25943#discussion_r2176116550