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