From shade at openjdk.org  Fri Aug  1 06:30:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 1 Aug 2025 06:30:59 GMT
Subject: RFR: 8358340: Support CDS heap archive with Generational
 Shenandoah
In-Reply-To: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
References: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
Message-ID: <fvZBbWR_guKJX0W63aEp-WT1glp2PYHvJx8or_9VZjg=.b180a629-7ae6-4662-be84-c06c48bd172f@github.com>

On Mon, 2 Jun 2025 18:22:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) is integrated, Generational Shenandoah can support CDS heap loads. This also allows Generational Shenandoah to work well with Leyden/AOT. We allocate things in young regions, and there is nothing else in the heap, so no card table updates are necessary.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:+ShenandoahVerify`

Thanks! Here goes.

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

PR Comment: https://git.openjdk.org/jdk/pull/25597#issuecomment-3142755055

From shade at openjdk.org  Fri Aug  1 06:30:59 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 1 Aug 2025 06:30:59 GMT
Subject: Integrated: 8358340: Support CDS heap archive with Generational
 Shenandoah
In-Reply-To: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
References: <GuPeTDuTrk-iRrs6nhdO8wC1lR_69SWdczMuuMHNefY=.a6474c0a-0287-42ff-8e5c-09b1d0854177@github.com>
Message-ID: <vAQ82U2RzI4kCOxwYY0z-kBdAUkOqnSRjCPIW_ePx5g=.12b7aa04-97ff-42db-a3da-ee4d64ffcf78@github.com>

On Mon, 2 Jun 2025 18:22:36 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Now that [JDK-8364111](https://bugs.openjdk.org/browse/JDK-8364111) is integrated, Generational Shenandoah can support CDS heap loads. This also allows Generational Shenandoah to work well with Leyden/AOT. We allocate things in young regions, and there is nothing else in the heap, so no card table updates are necessary.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah` 
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:+ShenandoahVerify`

This pull request has now been integrated.

Changeset: 577ac061
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/577ac0610a0c62d6a3f5501bb0d1bd45f8c47f22
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8358340: Support CDS heap archive with Generational Shenandoah

Reviewed-by: xpeng, wkemper

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

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

From shade at openjdk.org  Fri Aug  1 07:30:40 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 1 Aug 2025 07:30:40 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5]
In-Reply-To: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
Message-ID: <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>

> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>  - [x] Linux x86_64 server fastdebug, `all`

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

 - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
 - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
 - Do not fill out the entire regions
 - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
 - A bit more verification
 - Fix
 - Fix
 - Regular CDS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26510/files
  - new: https://git.openjdk.org/jdk/pull/26510/files/84a64649..780bb19e

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

  Stats: 6239 lines in 132 files changed: 4457 ins; 1551 del; 231 mod
  Patch: https://git.openjdk.org/jdk/pull/26510.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26510/head:pull/26510

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

From wkemper at openjdk.org  Fri Aug  1 18:42:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 1 Aug 2025 18:42:00 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5]
In-Reply-To: <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
Message-ID: <Gza8yuXOWJnqahsFIVIhCz7Tkro1zsJtx5chT9vnYJk=.171a7d84-ff1d-4dbe-a5d7-d7513afbc70c@github.com>

On Fri, 1 Aug 2025 07:30:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - Do not fill out the entire regions
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - A bit more verification
>  - Fix
>  - Fix
>  - Regular CDS

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

> 1280:       ShenandoahHeapRegion* r = _heap->get_region(i);
> 1281:       if (r->free() < PLAB::min_size() * HeapWordSize) {
> 1282:         _partitions.retire_from_partition(ShenandoahFreeSetPartitionId::Mutator, i, r->used());

Should we accrue waste here when these regions are retired? Or is waste only _humongous_ waste?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2248623501

From shade at openjdk.org  Fri Aug  1 19:11:02 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 1 Aug 2025 19:11:02 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5]
In-Reply-To: <Gza8yuXOWJnqahsFIVIhCz7Tkro1zsJtx5chT9vnYJk=.171a7d84-ff1d-4dbe-a5d7-d7513afbc70c@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
 <Gza8yuXOWJnqahsFIVIhCz7Tkro1zsJtx5chT9vnYJk=.171a7d84-ff1d-4dbe-a5d7-d7513afbc70c@github.com>
Message-ID: <otGXBGFGdGVsC8lWwoYRyVzmOSWYXUx0DaoBio8Svbw=.1b1f5116-c943-4150-9275-2daa3ee812ac@github.com>

On Fri, 1 Aug 2025 18:39:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>>  - Do not fill out the entire regions
>>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>>  - A bit more verification
>>  - Fix
>>  - Fix
>>  - Regular CDS
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1282:
> 
>> 1280:       ShenandoahHeapRegion* r = _heap->get_region(i);
>> 1281:       if (r->free() < PLAB::min_size() * HeapWordSize) {
>> 1282:         _partitions.retire_from_partition(ShenandoahFreeSetPartitionId::Mutator, i, r->used());
> 
> Should we accrue waste here when these regions are retired? Or is waste only _humongous_ waste?

I believe yes, we only report the _humongous_ waste in ShenandoahAllocRequest. The rest of the waste is accrued right in `retire_from_partition`: https://github.com/openjdk/jdk/blob/8e921aee5abb20c240b45cb75b06fb1f316d8a1f/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L373-L376

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2248692418

From wkemper at openjdk.org  Fri Aug  1 19:29:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 1 Aug 2025 19:29:55 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5]
In-Reply-To: <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
Message-ID: <aXy4jvvB0d0TiQTFLkVuPM_OM1A4mfJ4WCOfnYVjic4=.e7e5c234-dad5-448d-aa3c-fe8ff848fa08@github.com>

On Fri, 1 Aug 2025 07:30:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - Do not fill out the entire regions
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - A bit more verification
>  - Fix
>  - Fix
>  - Regular CDS

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26510#pullrequestreview-3080348336

From kdnilsen at openjdk.org  Sun Aug  3 22:42:54 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 3 Aug 2025 22:42:54 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5]
In-Reply-To: <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
Message-ID: <_B8dg2PqDeKOfcnFjCYzvi02rMn9aB_FUmJebzyYJtA=.972e96cf-4b7c-403e-bf92-285c7ddd85a2@github.com>

On Fri, 1 Aug 2025 07:30:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - Do not fill out the entire regions
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - A bit more verification
>  - Fix
>  - Fix
>  - Regular CDS

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/26510#pullrequestreview-3082385892

From kdnilsen at openjdk.org  Sun Aug  3 22:42:55 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 3 Aug 2025 22:42:55 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5]
In-Reply-To: <otGXBGFGdGVsC8lWwoYRyVzmOSWYXUx0DaoBio8Svbw=.1b1f5116-c943-4150-9275-2daa3ee812ac@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
 <Gza8yuXOWJnqahsFIVIhCz7Tkro1zsJtx5chT9vnYJk=.171a7d84-ff1d-4dbe-a5d7-d7513afbc70c@github.com>
 <otGXBGFGdGVsC8lWwoYRyVzmOSWYXUx0DaoBio8Svbw=.1b1f5116-c943-4150-9275-2daa3ee812ac@github.com>
Message-ID: <oI9nXs7Cav36aSYxK6KD9yie90YeUIDjYcZ9k3mTwFs=.2a8036f7-91c3-4da9-b0e5-09dbe7223667@github.com>

On Fri, 1 Aug 2025 19:08:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1282:
>> 
>>> 1280:       ShenandoahHeapRegion* r = _heap->get_region(i);
>>> 1281:       if (r->free() < PLAB::min_size() * HeapWordSize) {
>>> 1282:         _partitions.retire_from_partition(ShenandoahFreeSetPartitionId::Mutator, i, r->used());
>> 
>> Should we accrue waste here when these regions are retired? Or is waste only _humongous_ waste?
>
> I believe yes, we only report the _humongous_ waste in ShenandoahAllocRequest. The rest of the waste is accrued right in `retire_from_partition`: https://github.com/openjdk/jdk/blob/8e921aee5abb20c240b45cb75b06fb1f316d8a1f/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L373-L376

The "theory" is that if the remainder of this region is available for allocations, then we should not count the remnant as humongous_waste.  Is there any reason why we could not allow additional allocations within the CDS regions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2250161656

From kdnilsen at openjdk.org  Sun Aug  3 22:42:55 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 3 Aug 2025 22:42:55 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5]
In-Reply-To: <oI9nXs7Cav36aSYxK6KD9yie90YeUIDjYcZ9k3mTwFs=.2a8036f7-91c3-4da9-b0e5-09dbe7223667@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
 <Gza8yuXOWJnqahsFIVIhCz7Tkro1zsJtx5chT9vnYJk=.171a7d84-ff1d-4dbe-a5d7-d7513afbc70c@github.com>
 <otGXBGFGdGVsC8lWwoYRyVzmOSWYXUx0DaoBio8Svbw=.1b1f5116-c943-4150-9275-2daa3ee812ac@github.com>
 <oI9nXs7Cav36aSYxK6KD9yie90YeUIDjYcZ9k3mTwFs=.2a8036f7-91c3-4da9-b0e5-09dbe7223667@github.com>
Message-ID: <QgfmY130h38mgShn7I608NM__IVyEH7TIaCWHvSv3ok=.90f361f1-3d5d-452b-a2e7-dbe2caf0cc93@github.com>

On Sun, 3 Aug 2025 22:36:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> I believe yes, we only report the _humongous_ waste in ShenandoahAllocRequest. The rest of the waste is accrued right in `retire_from_partition`: https://github.com/openjdk/jdk/blob/8e921aee5abb20c240b45cb75b06fb1f316d8a1f/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L373-L376
>
> The "theory" is that if the remainder of this region is available for allocations, then we should not count the remnant as humongous_waste.  Is there any reason why we could not allow additional allocations within the CDS regions?

I agree that if we need to prevent further allocations in this region, then calling retire_from_partition() will account for the remnant memory as used and will prevent further allocations from this region.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2250161916

From jjiang at openjdk.org  Mon Aug  4 07:43:35 2025
From: jjiang at openjdk.org (John Jiang)
Date: Mon, 4 Aug 2025 07:43:35 GMT
Subject: RFR: 8364597: Replace THL A29 Limited with Tencent
Message-ID: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>

`THL A29 Limited` was a `Tencent` company but was dissolved.
So, the copyright notes just use `Tencent` directly.

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

Commit messages:
 - 8364597: Replace THL A29 Limited with Tencent

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

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

From shade at openjdk.org  Mon Aug  4 10:47:55 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 4 Aug 2025 10:47:55 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5]
In-Reply-To: <QgfmY130h38mgShn7I608NM__IVyEH7TIaCWHvSv3ok=.90f361f1-3d5d-452b-a2e7-dbe2caf0cc93@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
 <Gza8yuXOWJnqahsFIVIhCz7Tkro1zsJtx5chT9vnYJk=.171a7d84-ff1d-4dbe-a5d7-d7513afbc70c@github.com>
 <otGXBGFGdGVsC8lWwoYRyVzmOSWYXUx0DaoBio8Svbw=.1b1f5116-c943-4150-9275-2daa3ee812ac@github.com>
 <oI9nXs7Cav36aSYxK6KD9yie90YeUIDjYcZ9k3mTwFs=.2a8036f7-91c3-4da9-b0e5-09dbe7223667@github.com>
 <QgfmY130h38mgShn7I608NM__IVyEH7TIaCWHvSv3ok=.90f361f1-3d5d-452b-a2e7-dbe2caf0cc93@github.com>
Message-ID: <YT3PoiBNKGW813DFzAfows5voOKzY6VOFAFIgrCe19g=.f67e8024-065c-4cf9-b456-a210d106faf8@github.com>

On Sun, 3 Aug 2025 22:37:47 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The "theory" is that if the remainder of this region is available for allocations, then we should not count the remnant as humongous_waste.  Is there any reason why we could not allow additional allocations within the CDS regions?
>
> I agree that if we need to prevent further allocations in this region, then calling retire_from_partition() will account for the remnant memory as used and will prevent further allocations from this region.

> Is there any reason why we could not allow additional allocations within the CDS regions?

That code tries to accomplish exactly that, right? We only retire the regions that have too few free space. Otherwise they (well, the tail region, really) stays in mutator partition and can satisfy more allocations. This also avoid dealing with a possibility of having an unallocated tail in that tail region, which might not fit the smallest filler object.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26510#discussion_r2251110956

From shade at openjdk.org  Tue Aug  5 18:37:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 5 Aug 2025 18:37:11 GMT
Subject: RFR: 8364212: Shenandoah: Rework archived objects loading [v5]
In-Reply-To: <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
 <KFlmoTGgTa7jCaFS97Vjjd6uvnzeRCc183rbrwoahEI=.e3d22dce-2c69-441c-b4e7-6d148661d4c1@github.com>
Message-ID: <2qH9wp5hspi3MDhW3X2KPZwb3_xCIrLhKUncwsArIcE=.a598f20e-2ba5-4a10-b44d-09c0c799ce6f@github.com>

On Fri, 1 Aug 2025 07:30:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - Do not fill out the entire regions
>  - Merge branch 'master' into JDK-8364212-shenandoah-archived-objs
>  - A bit more verification
>  - Fix
>  - Fix
>  - Regular CDS

Thanks for reviews. I am integrating to let Kelvin rebase his accounting changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/26510#issuecomment-3156184478

From shade at openjdk.org  Tue Aug  5 18:37:12 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 5 Aug 2025 18:37:12 GMT
Subject: Integrated: 8364212: Shenandoah: Rework archived objects loading
In-Reply-To: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
References: <LLgVnLfavtfu3qlsx_WcYJe6OIyoWqzrBPWZwup2YT0=.27556183-2553-4d01-9a75-3753d2663061@github.com>
Message-ID: <wvtG5ht849spb9pdCUrMo5XzZubMIv-3zEauXUdWbU4=.0ce37b0f-a6c4-41c6-ac8e-bc72b8b1c820@github.com>

On Mon, 28 Jul 2025 15:36:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> As continuation of [JDK-8293650](https://bugs.openjdk.org/browse/JDK-8293650), we would want to avoid allocating CDS archives as humongous regions and then flipping them back to regular state. This already complicates the region accounting significantly, and was a source a few bugs. We can rework the CDS archive load to cleanly ask collector for a contiguous set of regular regions.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `hotspot_gc_shenandoah`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds`
>  - [x] Linux x86_64 server fastdebug, `runtime/cds` with `-XX:+UseShenandoahGC`
>  - [x] Linux x86_64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: 68a35511
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/68a35511ebd3fd77716242db973104657bc7b541
Stats:     115 lines in 6 files changed: 42 ins; 39 del; 34 mod

8364212: Shenandoah: Rework archived objects loading

Reviewed-by: wkemper, kdnilsen

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

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

From jiefu at openjdk.org  Wed Aug  6 06:59:02 2025
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 6 Aug 2025 06:59:02 GMT
Subject: RFR: 8364597: Replace THL A29 Limited with Tencent
In-Reply-To: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
References: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
Message-ID: <08Gigv9qz5H5c80w-WLegQ_8KVI4xoY-kZ374S8t5ls=.35ded307-c917-4c1b-9ab0-032499140a67@github.com>

On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `THL A29 Limited` was a `Tencent` company but was dissolved.
> So, the copyright notes just use `Tencent` directly.

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26614#pullrequestreview-3090664823

From wkemper at openjdk.org  Thu Aug  7 14:34:32 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 7 Aug 2025 14:34:32 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <7XE4YJeZb4Xx7iTK7kxKFUBO86GzSvnQdOtIXfoXYtA=.924c5048-febf-4198-bb75-7aa3de183f7b@github.com>

Merges tag jdk-21.0.9+2

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

Commit messages:
 - 8358452: JNI exception pending in Java_sun_awt_screencast_ScreencastHelper_remoteDesktopKeyImpl of screencast_pipewire.c:1214 (ID: 51119)
 - 8334016: Make PrintNullString.java automatic
 - 8355262: Test sun/security/ssl/SSLSessionImpl/NoInvalidateSocketException.java failed: accept timed out
 - 8328244: Convert javax/swing/JSlider/6742358/bug6742358.java applet test to main
 - 8328279: Convert java/awt/Cursor/CursorOverlappedPanelsTest test to main
 - 8328262: Convert javax/swing/JSplitPane/8132123/bug8132123.java applet test to main
 - 8328154: Convert sun/java2d/loops/CopyAreaSpeed.java applet test to main
 - 8328248: Convert javax/swing/JSlider/6587742/bug6587742.java applet test to main
 - 8327756: Convert javax/swing/JSlider/4987336/bug4987336.java applet to main
 - 8327873: Convert javax/swing/border/Test4247606.java applet test to main
 - ... and 187 more: https://git.openjdk.org/shenandoah-jdk21u/compare/54f20959...aab1e218

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=209&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/209/files
  Stats: 31104 lines in 690 files changed: 17697 ins; 9955 del; 3452 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/209.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/209/head:pull/209

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/209

From jjiang at openjdk.org  Fri Aug  8 02:31:15 2025
From: jjiang at openjdk.org (John Jiang)
Date: Fri, 8 Aug 2025 02:31:15 GMT
Subject: Integrated: 8364597: Replace THL A29 Limited with Tencent
In-Reply-To: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
References: <U2j3q3Sl7dZREY-8isnSNgyxxfaZxjrRMVRvfyDlaSg=.be42d20a-b81a-4ba5-8478-23662187d162@github.com>
Message-ID: <lUxnGf2cVXWfHR38WmZQVPwfzfBnjtOcc2Re_omkeGw=.c64c63b7-e7dd-48e1-b6f7-f0a1ebefaf56@github.com>

On Mon, 4 Aug 2025 07:38:01 GMT, John Jiang <jjiang at openjdk.org> wrote:

> `THL A29 Limited` was a `Tencent` company but was dissolved.
> So, the copyright notes just use `Tencent` directly.

This pull request has now been integrated.

Changeset: 4c9eadda
Author:    John Jiang <jjiang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c9eaddaef83c6ba30e27ae3e0d16caeeec206cb
Stats:     67 lines in 58 files changed: 0 ins; 9 del; 58 mod

8364597: Replace THL A29 Limited with Tencent

Reviewed-by: jiefu

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

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

From wkemper at openjdk.org  Thu Aug 14 14:30:59 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Aug 2025 14:30:59 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <dzNWaAFcQho6ma1A6W4cDiN29qLrwcbSo8yZP_KTkJE=.e0c0fc6d-314f-41e1-80ad-d406fd882e44@github.com>

Merges tag jdk-21.0.9+3

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

Commit messages:
 - 8361212: Remove AffirmTrust root CAs
 - 8360647: [XWayland] [OL10] NumPad keys are not triggered
 - 8358701: Remove misleading javax.management.remote API doc wording about JMX spec, and historic link to JMXMP
 - 8328570: Convert closed JViewport manual applet tests to main
 - 8328631: Convert java/awt/InputMethods/InputMethodsTest/InputMethodsTest.java applet test to manual
 - 8328401: Convert java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html applet test to automated
 - 8328328: Convert javax/swing/JTabbedPane/4666224/bug4666224.java applet test to main
 - 8328035: Convert javax/swing/text/html/TableView/7030332/bug7030332.java applet test to main
 - 8328225: Convert ImageDecoratedDnD.html applet test to main
 - 8328386: Convert java/awt/FileDialog/FileNameOverrideTest test to main
 - ... and 210 more: https://git.openjdk.org/shenandoah-jdk21u/compare/54f20959...d90297a8

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=210&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/210/files
  Stats: 36393 lines in 756 files changed: 19716 ins; 13027 del; 3650 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/210.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/210/head:pull/210

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/210

From wkemper at openjdk.org  Thu Aug 14 18:22:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Aug 2025 18:22:31 GMT
Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for
 evacuation threads
Message-ID: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>

Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation.

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

Commit messages:
 - Re-enable plab promotions for all threads when plabs are retired

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

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

From wkemper at openjdk.org  Thu Aug 14 19:26:52 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Aug 2025 19:26:52 GMT
Subject: RFR: 8365572: Shenandoah: Remove unused thread local _paced_time field
Message-ID: <luxHAW8XfZJjaw0X0dphfguc9rcdkiyk-sxkGAmjej8=.4d5bc073-8f75-4ac2-9088-d79cc6ca9639@github.com>

We missed this spot when removing the ShenandoahPacer.

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

Commit messages:
 - Remove unused ShenandoahThreadLocalData::_paced_time

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

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

From shade at openjdk.org  Thu Aug 14 19:33:14 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Aug 2025 19:33:14 GMT
Subject: RFR: 8365572: Shenandoah: Remove unused thread local _paced_time
 field
In-Reply-To: <luxHAW8XfZJjaw0X0dphfguc9rcdkiyk-sxkGAmjej8=.4d5bc073-8f75-4ac2-9088-d79cc6ca9639@github.com>
References: <luxHAW8XfZJjaw0X0dphfguc9rcdkiyk-sxkGAmjej8=.4d5bc073-8f75-4ac2-9088-d79cc6ca9639@github.com>
Message-ID: <X76-LCqk-XUqJBz4c46u4NzmVIcbBd74fXuQcDdxbvc=.6960d878-08ec-4ad9-9850-2acf4631bbe4@github.com>

On Thu, 14 Aug 2025 19:21:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We missed this spot when removing the ShenandoahPacer.

Right. Looks good!

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26788#pullrequestreview-3121877645

From wkemper at openjdk.org  Thu Aug 14 20:02:19 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Aug 2025 20:02:19 GMT
Subject: Integrated: 8365572: Shenandoah: Remove unused thread local
 _paced_time field
In-Reply-To: <luxHAW8XfZJjaw0X0dphfguc9rcdkiyk-sxkGAmjej8=.4d5bc073-8f75-4ac2-9088-d79cc6ca9639@github.com>
References: <luxHAW8XfZJjaw0X0dphfguc9rcdkiyk-sxkGAmjej8=.4d5bc073-8f75-4ac2-9088-d79cc6ca9639@github.com>
Message-ID: <8BpPi84im-8JicE0VBKcZ2nPlx4D1JNOeVH_MZll4JI=.50559f89-e2a7-41c6-945c-c1202670348f@github.com>

On Thu, 14 Aug 2025 19:21:34 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We missed this spot when removing the ShenandoahPacer.

This pull request has now been integrated.

Changeset: dccca0fb
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dccca0fb7a892d31179b70fa861b8b3cdde54e84
Stats:     15 lines in 2 files changed: 0 ins; 15 del; 0 mod

8365572: Shenandoah: Remove unused thread local _paced_time field

Reviewed-by: shade

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

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

From kdnilsen at openjdk.org  Thu Aug 14 23:36:09 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 14 Aug 2025 23:36:09 GMT
Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for
 evacuation threads
In-Reply-To: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>
References: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>
Message-ID: <kM-2iQVRra6k0VRv35Zcxv2Re7iP-YRbxCsmInij02U=.5083a28c-6e5e-49f9-9b02-c6fe53c18a63@github.com>

On Thu, 14 Aug 2025 18:15:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation.

Thank you for much improved code structure, and for fixing this bug.

Would be nice to share any improved performance results with this fix in place.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26785#pullrequestreview-3122435215

From ysr at openjdk.org  Fri Aug 15 02:40:11 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 15 Aug 2025 02:40:11 GMT
Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for
 evacuation threads
In-Reply-To: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>
References: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>
Message-ID: <LUhclRIPOxhgfXVSEn9m8nkE9Rz-Qo08lR4kW9Z-jHA=.6c3cbd0d-2482-47c0-b81a-c448147b2187@github.com>

On Thu, 14 Aug 2025 18:15:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation.

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26785#pullrequestreview-3122663034

From shade at openjdk.org  Fri Aug 15 08:11:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Aug 2025 08:11:10 GMT
Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for
 evacuation threads
In-Reply-To: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>
References: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>
Message-ID: <rK6ijRJALxEW7wudRKCD41J3n_eAAE5Hw9KDYSrdb-A=.6988fd6f-c168-4ef2-ab5b-c753b9971dd6@github.com>

On Thu, 14 Aug 2025 18:15:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation.

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26785#pullrequestreview-3123211456

From wkemper at openjdk.org  Fri Aug 15 17:57:10 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Aug 2025 17:57:10 GMT
Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for
 evacuation threads
In-Reply-To: <LUhclRIPOxhgfXVSEn9m8nkE9Rz-Qo08lR4kW9Z-jHA=.6c3cbd0d-2482-47c0-b81a-c448147b2187@github.com>
References: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>
 <LUhclRIPOxhgfXVSEn9m8nkE9Rz-Qo08lR4kW9Z-jHA=.6c3cbd0d-2482-47c0-b81a-c448147b2187@github.com>
Message-ID: <jI_Hi-OT3R7F00RbL47wRhy2HiL7CuYvGkNhhefc_JI=.e9acb789-c113-4c2f-9d85-d1f22719f0f4@github.com>

On Fri, 15 Aug 2025 02:37:57 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation.
>
> Marked as reviewed by ysr (Reviewer).

@ysramakrishna - the performance test results show no regressions. The level of detail we need to see the effect of the changes isn't enabled by default in the release testing.

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

PR Comment: https://git.openjdk.org/jdk/pull/26785#issuecomment-3192309751

From wkemper at openjdk.org  Fri Aug 15 18:00:17 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Aug 2025 18:00:17 GMT
Subject: Integrated: 8365571: GenShen: PLAB promotions may remain disabled for
 evacuation threads
In-Reply-To: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>
References: <OwdheYsNlGVN28yxWc9ANNQ5k1XayVzTBbCWXmRNPZY=.e549fd43-1e5d-49e3-b2bb-b9055bdb3774@github.com>
Message-ID: <vY0GYbzqm5qtWjTDAbs_042B9h3J6CPe3eFmQ2wqm3U=.34a7db19-0e6b-4f88-9fe3-d29b6da7ee53@github.com>

On Thu, 14 Aug 2025 18:15:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Mutators and GC workers have old generation LABs for promotions and old generation evacuations. Priority is given to old evacuations by using a promotion budget. Once the promotion budget is exhausted, a thread local flag is set to disable further promotions (the LAB can still be used for old evacuations). This thread local flag is meant to be cleared to allow all threads to resume promotions on the next cycle. However, this flag is only reset for workers that perform thread root evacuations, which may not be the same workers that perform subsequent evacuations. This patch clears the flag for all threads when their LABs are retired at the end of evacuation.

This pull request has now been integrated.

Changeset: 08db4b99
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08db4b99622e488558dd7987c34f1c515fa30426
Stats:     24 lines in 2 files changed: 5 ins; 15 del; 4 mod

8365571: GenShen: PLAB promotions may remain disabled for evacuation threads

Reviewed-by: kdnilsen, ysr, shade

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

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

From wkemper at openjdk.org  Mon Aug 18 21:10:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Aug 2025 21:10:38 GMT
Subject: RFR: 8361948: Shenandoah: region free capacity unit mismatch
Message-ID: <s5diaXHvMZQ6N0MG0TtnrjM59vfNdljhVmGA9nEbYjI=.5cd58e26-c793-4abc-847e-a990588d9d91@github.com>

Clean backport. Fixes Shenandoah unit mismatch bug.

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

Commit messages:
 - Backport 46988e1073e9a2b47491c90143b1f261fe56da56

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/213

From wkemper at openjdk.org  Mon Aug 18 22:08:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Aug 2025 22:08:13 GMT
Subject: Integrated: 8361948: Shenandoah: region free capacity unit mismatch
In-Reply-To: <s5diaXHvMZQ6N0MG0TtnrjM59vfNdljhVmGA9nEbYjI=.5cd58e26-c793-4abc-847e-a990588d9d91@github.com>
References: <s5diaXHvMZQ6N0MG0TtnrjM59vfNdljhVmGA9nEbYjI=.5cd58e26-c793-4abc-847e-a990588d9d91@github.com>
Message-ID: <qC3HTh0GDroXO0rs7fFIS-KDiAQnV8P7utW7m6gH2KM=.7242df20-9262-48b5-b979-3f8f326436d6@github.com>

On Mon, 18 Aug 2025 21:00:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes Shenandoah unit mismatch bug.

This pull request has now been integrated.

Changeset: 87538c54
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/87538c5482665ae9f6395923aaa8e4ed0fbf2e02
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8361948: Shenandoah: region free capacity unit mismatch

Backport-of: 46988e1073e9a2b47491c90143b1f261fe56da56

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/213

From wkemper at openjdk.org  Mon Aug 18 22:14:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Aug 2025 22:14:13 GMT
Subject: RFR: 8365571: GenShen: PLAB promotions may remain disabled for
 evacuation threads
Message-ID: <_pkC7d2_DNa25LzxdQiZtWHAdamHRM0DUiTMmgfhgfE=.737e5b5e-f482-45b5-9855-ce04f936857e@github.com>

Clean backport. Fixes performance issue in generational mode for Shenanodah.

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

Commit messages:
 - Backport 08db4b99622e488558dd7987c34f1c515fa30426

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/214/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=214&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365571
  Stats: 24 lines in 2 files changed: 5 ins; 15 del; 4 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/214.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/214/head:pull/214

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/214

From wkemper at openjdk.org  Mon Aug 18 23:07:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Aug 2025 23:07:56 GMT
Subject: Integrated: 8365571: GenShen: PLAB promotions may remain disabled for
 evacuation threads
In-Reply-To: <_pkC7d2_DNa25LzxdQiZtWHAdamHRM0DUiTMmgfhgfE=.737e5b5e-f482-45b5-9855-ce04f936857e@github.com>
References: <_pkC7d2_DNa25LzxdQiZtWHAdamHRM0DUiTMmgfhgfE=.737e5b5e-f482-45b5-9855-ce04f936857e@github.com>
Message-ID: <Ey8rVHWCrBjFpv6TLDRMJb9S-2SIz6Rs6Nit_DtVQEY=.07ce77c9-eec8-4d7a-8b9f-6a49842f28a8@github.com>

On Mon, 18 Aug 2025 22:03:45 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes performance issue in generational mode for Shenanodah.

This pull request has now been integrated.

Changeset: dcf0b23f
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/dcf0b23fb28346172ac3e3ee0465776c51c0220e
Stats:     24 lines in 2 files changed: 5 ins; 15 del; 4 mod

8365571: GenShen: PLAB promotions may remain disabled for evacuation threads

Backport-of: 08db4b99622e488558dd7987c34f1c515fa30426

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/214

From wkemper at openjdk.org  Mon Aug 18 23:11:58 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Aug 2025 23:11:58 GMT
Subject: Withdrawn: Merge openjdk/jdk21u:master
In-Reply-To: <Lj82QvEbU8TJ8LCR08rT4K9BbdY_ZGn-niMnU1GICVQ=.971375d3-69e7-4014-afb2-21d2ee6b6f13@github.com>
References: <Lj82QvEbU8TJ8LCR08rT4K9BbdY_ZGn-niMnU1GICVQ=.971375d3-69e7-4014-afb2-21d2ee6b6f13@github.com>
Message-ID: <5zdwUUiCZ5wGwQXWGyoEOPAoJz-T1YSjbAswSzmE7KI=.6f47839f-03d7-4b9e-881b-dd3a2f00d506@github.com>

On Thu, 31 Jul 2025 14:27:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+1

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/208

From wkemper at openjdk.org  Mon Aug 18 23:11:58 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Aug 2025 23:11:58 GMT
Subject: RFR: Merge openjdk/jdk21u:master
In-Reply-To: <Lj82QvEbU8TJ8LCR08rT4K9BbdY_ZGn-niMnU1GICVQ=.971375d3-69e7-4014-afb2-21d2ee6b6f13@github.com>
References: <Lj82QvEbU8TJ8LCR08rT4K9BbdY_ZGn-niMnU1GICVQ=.971375d3-69e7-4014-afb2-21d2ee6b6f13@github.com>
Message-ID: <aTcg0H1KSD8NihQLqWmeUayJ0H8iZoDUaPp99DE5cb4=.5c126f44-fc9c-4a70-9f8b-b450c6874e1b@github.com>

On Thu, 31 Jul 2025 14:27:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+1

Superseded by another PR.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/208#issuecomment-3198682451

From wkemper at openjdk.org  Mon Aug 18 23:12:10 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Aug 2025 23:12:10 GMT
Subject: RFR: Merge openjdk/jdk21u:master
In-Reply-To: <7XE4YJeZb4Xx7iTK7kxKFUBO86GzSvnQdOtIXfoXYtA=.924c5048-febf-4198-bb75-7aa3de183f7b@github.com>
References: <7XE4YJeZb4Xx7iTK7kxKFUBO86GzSvnQdOtIXfoXYtA=.924c5048-febf-4198-bb75-7aa3de183f7b@github.com>
Message-ID: <NXmZX6ORnPdO8x0qFgNGsYnkwfY_Ksk97SMB4NDmdVY=.86cf532e-eb07-4ec0-9ed6-c37dd4db5592@github.com>

On Thu, 7 Aug 2025 14:28:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+2

Superseded by another PR.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/209#issuecomment-3198683197

From wkemper at openjdk.org  Mon Aug 18 23:12:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 18 Aug 2025 23:12:11 GMT
Subject: Withdrawn: Merge openjdk/jdk21u:master
In-Reply-To: <7XE4YJeZb4Xx7iTK7kxKFUBO86GzSvnQdOtIXfoXYtA=.924c5048-febf-4198-bb75-7aa3de183f7b@github.com>
References: <7XE4YJeZb4Xx7iTK7kxKFUBO86GzSvnQdOtIXfoXYtA=.924c5048-febf-4198-bb75-7aa3de183f7b@github.com>
Message-ID: <VDSZzeFcdzgJKYA7dMy1MIqJt8V_IdeBGqSHfyojcIE=.244f3e49-d63b-417d-9755-f0797dca7bb9@github.com>

On Thu, 7 Aug 2025 14:28:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+2

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/209

From wkemper at openjdk.org  Tue Aug 19 17:28:14 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 19 Aug 2025 17:28:14 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <dzNWaAFcQho6ma1A6W4cDiN29qLrwcbSo8yZP_KTkJE=.e0c0fc6d-314f-41e1-80ad-d406fd882e44@github.com>
References: <dzNWaAFcQho6ma1A6W4cDiN29qLrwcbSo8yZP_KTkJE=.e0c0fc6d-314f-41e1-80ad-d406fd882e44@github.com>
Message-ID: <aqwxSfTEovmZ7r5s6zV9CCmiLtPsPVTuZKkzNEXlwLU=.e413233e-ab77-4b08-a34a-1221bbf0e3c1@github.com>

> Merges tag jdk-21.0.9+3

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

 - Merge remote-tracking branch 'shenandoah-jdk21u/master' into merge-jdk-21.0.9+3
 - 8361212: Remove AffirmTrust root CAs
   
   Backport-of: 3bdac5317815b84d6f693d972f73d77dd069a891
 - 8360647: [XWayland] [OL10] NumPad keys are not triggered
   
   Reviewed-by: mbaesken
   Backport-of: 0029554d20f22648994040a041c418d48a2a0eb4
 - 8358701: Remove misleading javax.management.remote API doc wording about JMX spec, and historic link to JMXMP
   
   Reviewed-by: mbaesken
   Backport-of: 66535fe26da27dfaf0940bd70deb30942f7d0cdc
 - 8328570: Convert closed JViewport manual applet tests to main
   
   Backport-of: 725d87bbc2abae2ca856d91668f0a494f93fca1c
 - 8328631: Convert java/awt/InputMethods/InputMethodsTest/InputMethodsTest.java applet test to manual
   
   Backport-of: 43080173e88c8f53cd54c9096c79f3144007fd97
 - 8328401: Convert java/awt/Frame/InitialMaximizedTest/InitialMaximizedTest.html applet test to automated
   
   Backport-of: 700d2b91defd421a2818f53830c24f70d11ba4f6
 - 8328328: Convert javax/swing/JTabbedPane/4666224/bug4666224.java applet test to main
   
   Backport-of: 65d9f119c401c26c9a6436f5c9a513f91bb8c753
 - 8328035: Convert javax/swing/text/html/TableView/7030332/bug7030332.java applet test to main
   
   Backport-of: 481473efce9f51a497e26002c6da52b0ddc9ea8f
 - 8328225: Convert ImageDecoratedDnD.html applet test to main
   
   Backport-of: a112fc8bac8ddee87c8555b156519a2785d3223b
 - ... and 211 more: https://git.openjdk.org/shenandoah-jdk21u/compare/dcf0b23f...842ad56f

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/210/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=210&range=01
  Stats: 36391 lines in 755 files changed: 19716 ins; 13027 del; 3648 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/210.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/210/head:pull/210

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/210

From cslucas at openjdk.org  Tue Aug 19 23:52:50 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Tue, 19 Aug 2025 23:52:50 GMT
Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry points
Message-ID: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>

The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part.

This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests.

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

Commit messages:
 - Shenandoah API clean-up.

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

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

From kdnilsen at openjdk.org  Wed Aug 20 20:20:38 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 20 Aug 2025 20:20:38 GMT
Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry
 points
In-Reply-To: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
References: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
Message-ID: <SVJ-BZDYH4JlmEwBkOfy3FoHl8l-ZG0FiGUowuL42RI=.b9091938-aa54-47d3-b73a-193d112979e2@github.com>

On Tue, 19 Aug 2025 23:47:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part.
> 
> This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests.

Looks good to me.  Have we run this change through our internal CI regression pipelines?

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26850#pullrequestreview-3138114458

From wkemper at openjdk.org  Wed Aug 20 20:58:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 20 Aug 2025 20:58:36 GMT
Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry
 points
In-Reply-To: <SVJ-BZDYH4JlmEwBkOfy3FoHl8l-ZG0FiGUowuL42RI=.b9091938-aa54-47d3-b73a-193d112979e2@github.com>
References: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
 <SVJ-BZDYH4JlmEwBkOfy3FoHl8l-ZG0FiGUowuL42RI=.b9091938-aa54-47d3-b73a-193d112979e2@github.com>
Message-ID: <WlJ3sRxTj-5SWV39RV-PARpuNjZeip3-6zHy190p-vU=.eeac7299-f33b-4a83-a727-8f79b65191fd@github.com>

On Wed, 20 Aug 2025 20:18:21 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part.
>> 
>> This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests.
>
> Looks good to me.  Have we run this change through our internal CI regression pipelines?

Looks reasonable to me. I have the same question as @kdnilsen .

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

PR Comment: https://git.openjdk.org/jdk/pull/26850#issuecomment-3208064052

From ysr at openjdk.org  Thu Aug 21 01:59:51 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 21 Aug 2025 01:59:51 GMT
Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry
 points
In-Reply-To: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
References: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
Message-ID: <Bvyj-qaGuDGGhYxHscdnF8H92ZduUDaw-Zj3f8IYodQ=.4e5d1abc-518d-4656-8ac3-00621a3a567b@github.com>

On Tue, 19 Aug 2025 23:47:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part.
> 
> This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests.

Marked as reviewed by ysr (Reviewer).

Same; performance impact would be good to know (i.e. that it's performance neutral or may be even a bit better).

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

PR Review: https://git.openjdk.org/jdk/pull/26850#pullrequestreview-3138778757
PR Comment: https://git.openjdk.org/jdk/pull/26850#issuecomment-3208682261

From wkemper at openjdk.org  Thu Aug 21 14:28:48 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 21 Aug 2025 14:28:48 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <zQZpfNAhUefAuKiT84Os_GeRk_6og22iyg_vyWY-htw=.5c645ca4-5d47-469d-841f-726eddf0e2e2@github.com>

Merges tag jdk-21.0.9+4

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

Commit messages:
 - 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in linux-aarch64
 - 8353126: Open source events tests batch1
 - 8352860: Open source events tests batch0
 - 8348135: Fix couple of problem listing entries in test/hotspot/jtreg/ProblemList-Virtual.txt
 - 8352677: Opensource JMenu tests - series2
 - 8185429: [macos] After a modal dialog is closed, no window becomes active
 - 8357285: JSR166 Test case testShutdownNow_delayedTasks failed
 - 8341370: Test java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails intermittently on macOS-aarch64
 - 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock
 - 8353847: Remove extra args to System.out.printf in open/test/jdk/java/net/httpclient tests
 - ... and 237 more: https://git.openjdk.org/shenandoah-jdk21u/compare/54f20959...3949aae8

The webrev contains the conflicts with master:
 - merge conflicts: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=215&range=00.conflicts

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/215/files
  Stats: 39746 lines in 807 files changed: 22040 ins; 13897 del; 3809 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/215.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/215/head:pull/215

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/215

From wkemper at openjdk.org  Fri Aug 22 18:31:08 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 22 Aug 2025 18:31:08 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may raise
 threshold prematurely
Message-ID: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>

The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).

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

Commit messages:
 - Revert unintended change
 - Merge tag 'jdk-26+12' into adaptive-tenuring-threshold
 - Clean up tests
 - Checkpoint, tests pass
 - Add test that simulates promotion above tenuring age
 - Add more census updates, exhibit current behavior in test
 - Remove outdated comment
 - Update unit test, fix slowdebug build issue
 - Merge remote-tracking branch 'jdk/master' into adaptive-tenuring-threshold
 - Assert current behavior is expected
 - ... and 1 more: https://git.openjdk.org/jdk/compare/02fe095d...64c68395

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

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

From wkemper at openjdk.org  Fri Aug 22 18:31:09 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 22 Aug 2025 18:31:09 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely
In-Reply-To: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
Message-ID: <mnHSX8xRGTpfaMNVKW7xy8p4hP73PtU3ztB6d-cqhgk=.db53a740-135d-4fc0-bbea-1819cd76c70a@github.com>

On Fri, 22 Aug 2025 18:24:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).

src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp line 30:

> 28: #include "gc/shenandoah/shenandoahHeap.inline.hpp"
> 29: 
> 30: ShenandoahAgeCensus::ShenandoahAgeCensus()

Many of the changes here are to facilitate unit testing.

src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp line 307:

> 305:      // ignoring the mortality rates of any older cohorts (which may see
> 306:      // higher mortality rates due to promotions).
> 307:      upper_bound = MIN2(upper_bound, prev_tt);

This is a key change.

src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.cpp line 331:

> 329:       assert(tenuring_threshold == i + 1 || tenuring_threshold == upper_bound, "Error");
> 330:       assert(tenuring_threshold >= lower_bound && tenuring_threshold <= upper_bound, "Error");
> 331:       return i + 1;

This is a subtle change, but it prevents the algorithm from getting stuck on the first cohort.

src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 181:

> 179:   // Return true if this age is above the tenuring threshold.
> 180:   bool is_tenurable(uint age) const {
> 181:     return age > tenuring_threshold();

Another key change. This prevents the algorithm from seeing higher mortality rates caused by promotions in the cohort at tenuring age.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2294394667
PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2294395207
PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2294396795
PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2294398888

From wkemper at openjdk.org  Fri Aug 22 21:01:32 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 22 Aug 2025 21:01:32 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v2]
In-Reply-To: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
Message-ID: <XpbibmoivROzFjDLX5HK6wB1nXVrsSzzopQL5EVjrrA=.2393c649-075b-4bb3-a346-c3e55cff427f@github.com>

> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).

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

  Fix release build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26906/files
  - new: https://git.openjdk.org/jdk/pull/26906/files/64c68395..8b2fb41a

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

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

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

From wkemper at openjdk.org  Fri Aug 22 21:45:04 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 22 Aug 2025 21:45:04 GMT
Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry
 points
In-Reply-To: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
References: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
Message-ID: <7DOD0VQ9oRjzSLKrfDhFe7SvK7ewKato2pS8TaiVLJE=.d45cafcc-6a6b-4aa5-af23-c9426cd5d224@github.com>

On Tue, 19 Aug 2025 23:47:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part.
> 
> This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests.

Internal testing looks good.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26850#pullrequestreview-3146240854

From cslucas at openjdk.org  Fri Aug 22 21:53:56 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 22 Aug 2025 21:53:56 GMT
Subject: RFR: 8356289: Shenandoah: Clean up SATB barrier runtime entry
 points
In-Reply-To: <WlJ3sRxTj-5SWV39RV-PARpuNjZeip3-6zHy190p-vU=.eeac7299-f33b-4a83-a727-8f79b65191fd@github.com>
References: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
 <SVJ-BZDYH4JlmEwBkOfy3FoHl8l-ZG0FiGUowuL42RI=.b9091938-aa54-47d3-b73a-193d112979e2@github.com>
 <WlJ3sRxTj-5SWV39RV-PARpuNjZeip3-6zHy190p-vU=.eeac7299-f33b-4a83-a727-8f79b65191fd@github.com>
Message-ID: <WLK2S7AvO_MoTl5yHm0FqGWZd3UJuCIdXJsy6L-PSyw=.bfc16d93-0ffa-41e9-a8f5-f5d93d30e82c@github.com>

On Wed, 20 Aug 2025 20:56:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Looks good to me.  Have we run this change through our internal CI regression pipelines?
>
> Looks reasonable to me. I have the same question as @kdnilsen .

I reviewed the tests internally with @earthling-amzn ; He said everything looks good.

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

PR Comment: https://git.openjdk.org/jdk/pull/26850#issuecomment-3215770829

From cslucas at openjdk.org  Fri Aug 22 21:53:57 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 22 Aug 2025 21:53:57 GMT
Subject: Integrated: 8356289: Shenandoah: Clean up SATB barrier runtime entry
 points
In-Reply-To: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
References: <swe1dQ9Ye5mMF3vFwaFaN-XrQkHedGHxjBEHNj8VkE0=.21b1a1e7-4745-4639-bebf-f4c56bf21d29@github.com>
Message-ID: <h9Ee2tnRi9oJdOTqu5lrud-m8YnvKIXlY0NZjLsBc_g=.ea377a24-832c-44b1-bb38-e0ae951bc8a4@github.com>

On Tue, 19 Aug 2025 23:47:34 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> The runtime entry points for the SATB slow-paths currently take a JavaThread* argument. When @rkennke did the entry points for Graal ([JDK-8356075](https://bugs.openjdk.org/browse/JDK-8356075)), he figured that we do not really need them. The slow-path is only called rarely (whenever the local SATB buffer is full), and getting the current Thread* in the runtime would not be the expensive part.
> 
> This PR is a patch to do that clean up. The changes were tested on Linux x64/aarch64 with JTREG tier1-3 using Shenandoah for all tests.

This pull request has now been integrated.

Changeset: f28f6189
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f28f6189721a86b1a6ad0a19cc38192af55eb45a
Stats:     31 lines in 9 files changed: 1 ins; 8 del; 22 mod

8356289: Shenandoah: Clean up SATB barrier runtime entry points

Reviewed-by: kdnilsen, ysr, wkemper

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

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

From wkemper at openjdk.org  Mon Aug 25 17:23:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Aug 2025 17:23:11 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v3]
In-Reply-To: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
Message-ID: <GxnQowl_uv6hL5gO26Qo88aVZWfnLgLPRghlIJilR3I=.29442648-30ae-461c-a1ba-40a4358085ec@github.com>

> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).

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

  Fix windows build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26906/files
  - new: https://git.openjdk.org/jdk/pull/26906/files/8b2fb41a..b9e16d26

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

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

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

From wkemper at openjdk.org  Mon Aug 25 18:47:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 25 Aug 2025 18:47:56 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <dzNWaAFcQho6ma1A6W4cDiN29qLrwcbSo8yZP_KTkJE=.e0c0fc6d-314f-41e1-80ad-d406fd882e44@github.com>
References: <dzNWaAFcQho6ma1A6W4cDiN29qLrwcbSo8yZP_KTkJE=.e0c0fc6d-314f-41e1-80ad-d406fd882e44@github.com>
Message-ID: <b9bAAeN-89NVoERrG_ggecVM5xxTGiEGPFAu-vxXMtM=.9b9246dc-9aed-4db8-a201-94ed5e902677@github.com>

On Thu, 14 Aug 2025 14:25:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+3

This pull request has now been integrated.

Changeset: 753618a7
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/753618a7cbdeea9a1869821a088cd47169b4f7c1
Stats:     36391 lines in 755 files changed: 19716 ins; 13027 del; 3648 mod

Merge

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/210

From kdnilsen at openjdk.org  Tue Aug 26 16:09:34 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 26 Aug 2025 16:09:34 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v3]
In-Reply-To: <GxnQowl_uv6hL5gO26Qo88aVZWfnLgLPRghlIJilR3I=.29442648-30ae-461c-a1ba-40a4358085ec@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <GxnQowl_uv6hL5gO26Qo88aVZWfnLgLPRghlIJilR3I=.29442648-30ae-461c-a1ba-40a4358085ec@github.com>
Message-ID: <DlzcuJXbPaxqzjyQteFalHDb35ouKO2PfQm0X_aUKvo=.8b5c6104-c250-4760-acd0-cbaf8ccbb3c6@github.com>

On Mon, 25 Aug 2025 17:23:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows build

Thank you very much for these changes.  LGTM.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26906#pullrequestreview-3156366673

From wkemper at openjdk.org  Tue Aug 26 22:26:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 26 Aug 2025 22:26:39 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <zQZpfNAhUefAuKiT84Os_GeRk_6og22iyg_vyWY-htw=.5c645ca4-5d47-469d-841f-726eddf0e2e2@github.com>
References: <zQZpfNAhUefAuKiT84Os_GeRk_6og22iyg_vyWY-htw=.5c645ca4-5d47-469d-841f-726eddf0e2e2@github.com>
Message-ID: <mTLjSJz8NjIGeHWCs300Ps3-AVN0ouJhYEt8F7MAXqE=.024e3c2c-dbfb-467e-bcdb-f76d741276dc@github.com>

> Merges tag jdk-21.0.9+4

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/215/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/215/files/3949aae8..3949aae8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=215&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=215&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/215.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/215/head:pull/215

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/215

From duke at openjdk.org  Wed Aug 27 18:31:03 2025
From: duke at openjdk.org (Rui Li)
Date: Wed, 27 Aug 2025 18:31:03 GMT
Subject: RFR: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics
 considered poor user-experience
Message-ID: <O8NEkCNP1GVe--X2sM7tUDmboVfTH2L28WoTlnOgeaY=.7234d126-94ff-43f3-9245-765e995eb099@github.com>

When generational shenandoah is enabled, it ignores the value of ShenandoahGCHeuristics input silently:

java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
openjdk version "25" 2025-09-16 LTS
OpenJDK Runtime Environment Corretto-25.0.0.36.1 (build 25+36-LTS)
OpenJDK 64-Bit Server VM Corretto-25.0.0.36.1 (build 25+36-LTS, mixed mode, sharing)


Adding additional guard rail to gen shen is not an option - it is actually by design that gen shen does not support non adaptive heuristics due to the complexity brought by generational design. 

So print out a warning to users to indicate that their `ShenandoahGCHeuristics` input is ignored.


x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=static -version
[0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: static, because generational shenandoah only supports adaptive heuristics
openjdk version "26" 2026-03-17
OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)

x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
[0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: junk, because generational shenandoah only supports adaptive heuristics
openjdk version "26" 2026-03-17
OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)

x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=adaptive -version
openjdk version "26" 2026-03-17
OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)

x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -version  
openjdk version "26" 2026-03-17
OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)

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

Commit messages:
 - 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics considered poor user-experience

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

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

From duke at openjdk.org  Wed Aug 27 22:47:58 2025
From: duke at openjdk.org (Rui Li)
Date: Wed, 27 Aug 2025 22:47:58 GMT
Subject: RFR: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics
 considered poor user-experience [v2]
In-Reply-To: <O8NEkCNP1GVe--X2sM7tUDmboVfTH2L28WoTlnOgeaY=.7234d126-94ff-43f3-9245-765e995eb099@github.com>
References: <O8NEkCNP1GVe--X2sM7tUDmboVfTH2L28WoTlnOgeaY=.7234d126-94ff-43f3-9245-765e995eb099@github.com>
Message-ID: <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com>

> When generational shenandoah is enabled, it ignores the value of ShenandoahGCHeuristics input silently:
> 
> java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
> openjdk version "25" 2025-09-16 LTS
> OpenJDK Runtime Environment Corretto-25.0.0.36.1 (build 25+36-LTS)
> OpenJDK 64-Bit Server VM Corretto-25.0.0.36.1 (build 25+36-LTS, mixed mode, sharing)
> 
> 
> Adding additional guard rail to gen shen is not an option - it is actually by design that gen shen does not support non adaptive heuristics due to the complexity brought by generational design. 
> 
> So print out a warning to users to indicate that their `ShenandoahGCHeuristics` input is ignored.
> 
> 
> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=static -version
> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: static, because generational shenandoah only supports adaptive heuristics
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
> 
> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: junk, because generational shenandoah only supports adaptive heuristics
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
> 
> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=adaptive -version
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
> 
> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -version  
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)

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

  Update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26968/files
  - new: https://git.openjdk.org/jdk/pull/26968/files/c999d47f..247dce42

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

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

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

From ysr at openjdk.org  Wed Aug 27 23:07:41 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 27 Aug 2025 23:07:41 GMT
Subject: RFR: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics
 considered poor user-experience [v2]
In-Reply-To: <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com>
References: <O8NEkCNP1GVe--X2sM7tUDmboVfTH2L28WoTlnOgeaY=.7234d126-94ff-43f3-9245-765e995eb099@github.com>
 <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com>
Message-ID: <bJJVwC62AroZ6Un9nW11VvteHGJm_w7VaCKWFelJ-mA=.a6f1b223-8217-4666-8e18-8686b9a6fe8b@github.com>

On Wed, 27 Aug 2025 22:47:58 GMT, Rui Li <duke at openjdk.org> wrote:

>> When generational shenandoah is enabled, it ignores the value of ShenandoahGCHeuristics input silently:
>> 
>> java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
>> openjdk version "25" 2025-09-16 LTS
>> OpenJDK Runtime Environment Corretto-25.0.0.36.1 (build 25+36-LTS)
>> OpenJDK 64-Bit Server VM Corretto-25.0.0.36.1 (build 25+36-LTS, mixed mode, sharing)
>> 
>> 
>> Adding additional guard rail to gen shen is not an option - it is actually by design that gen shen does not support non adaptive heuristics due to the complexity brought by generational design. 
>> 
>> So print out a warning to users to indicate that their `ShenandoahGCHeuristics` input is ignored.
>> 
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=static -version
>> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: static, because generational shenandoah only supports adaptive heuristics
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
>> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: junk, because generational shenandoah only supports adaptive heuristics
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=adaptive -version
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -version  
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update

Thanks for fixing this. The new behaviour is much more user friendly, and I like the clear error message.

Approved, modulo testing results (which I don't expect any issues with given the change).

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26968#pullrequestreview-3162061524

From wkemper at openjdk.org  Wed Aug 27 23:13:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 27 Aug 2025 23:13:41 GMT
Subject: RFR: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics
 considered poor user-experience [v2]
In-Reply-To: <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com>
References: <O8NEkCNP1GVe--X2sM7tUDmboVfTH2L28WoTlnOgeaY=.7234d126-94ff-43f3-9245-765e995eb099@github.com>
 <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com>
Message-ID: <0Y1dV8xouNEnMbmpNqT5rLrA96_K5YxmpWkCCiBDcOk=.2f088f9f-c3b1-4d14-a033-db1bb195da25@github.com>

On Wed, 27 Aug 2025 22:47:58 GMT, Rui Li <duke at openjdk.org> wrote:

>> When generational shenandoah is enabled, it ignores the value of ShenandoahGCHeuristics input silently:
>> 
>> java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
>> openjdk version "25" 2025-09-16 LTS
>> OpenJDK Runtime Environment Corretto-25.0.0.36.1 (build 25+36-LTS)
>> OpenJDK 64-Bit Server VM Corretto-25.0.0.36.1 (build 25+36-LTS, mixed mode, sharing)
>> 
>> 
>> Adding additional guard rail to gen shen is not an option - it is actually by design that gen shen does not support non adaptive heuristics due to the complexity brought by generational design. 
>> 
>> So print out a warning to users to indicate that their `ShenandoahGCHeuristics` input is ignored.
>> 
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=static -version
>> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: static, because generational shenandoah only supports adaptive heuristics
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
>> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: junk, because generational shenandoah only supports adaptive heuristics
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=adaptive -version
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -version  
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update

Looks good to me.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26968#pullrequestreview-3162081094

From ysr at openjdk.org  Thu Aug 28 01:08:50 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Aug 2025 01:08:50 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v3]
In-Reply-To: <GxnQowl_uv6hL5gO26Qo88aVZWfnLgLPRghlIJilR3I=.29442648-30ae-461c-a1ba-40a4358085ec@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <GxnQowl_uv6hL5gO26Qo88aVZWfnLgLPRghlIJilR3I=.29442648-30ae-461c-a1ba-40a4358085ec@github.com>
Message-ID: <F62Ov4-foXX5k-inl4XO2hx_TGQj1nrf9BmAvjJpqBw=.f460cb67-621d-493d-bbb1-2cf9b978742d@github.com>

On Mon, 25 Aug 2025 17:23:11 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix windows build

Left some comments.
Will take a look at the tests and re-review the computation loop, once I understand your response to my comment about uniformly using `is_tenurable` (or its moral equivalent of doing a strictly greater than check in age comparisons for tenuring).

Sorry for the delay.

Also, are there any comparative performance numbers to share yet?

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

> 217:       // We don't want to deal with MT here just to ensure we read the right mark word.
> 218:       // Skip the potential promotion attempt for this one.
> 219:     } else if (age_census()->is_tenurable(r->age() + mark.age())) {

See comment above re using this boolean accessor at other places where comparisons are made with tenuring threshold.

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

PR Review: https://git.openjdk.org/jdk/pull/26906#pullrequestreview-3162543552
PR Comment: https://git.openjdk.org/jdk/pull/26906#issuecomment-3230713766
PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2305790877

From ysr at openjdk.org  Thu Aug 28 01:08:50 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 28 Aug 2025 01:08:50 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v3]
In-Reply-To: <mnHSX8xRGTpfaMNVKW7xy8p4hP73PtU3ztB6d-cqhgk=.db53a740-135d-4fc0-bbea-1819cd76c70a@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <mnHSX8xRGTpfaMNVKW7xy8p4hP73PtU3ztB6d-cqhgk=.db53a740-135d-4fc0-bbea-1819cd76c70a@github.com>
Message-ID: <sxFgoDL6Qu745yVNjQMrA2p7skZVGLrCfJx_zNwBuHw=.a25132c7-50a5-471f-ab29-4b705f47408e@github.com>

On Fri, 22 Aug 2025 18:27:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix windows build
>
> src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 181:
> 
>> 179:   // Return true if this age is above the tenuring threshold.
>> 180:   bool is_tenurable(uint age) const {
>> 181:     return age > tenuring_threshold();
> 
> Another key change. This prevents the algorithm from seeing higher mortality rates caused by promotions in the cohort at tenuring age.

The strict ">" says objects of age strictly greater than the computed tenuring threshold are tenurable, not those of that age. This might make sense if it were used at all the places where tenuring decisions were being made during evacuation. Was that the intention?

That doesn't seem to be the case -- there are pre-existing places in the code where a raw comparison with the tenuring threshold are made that don't do the strict check. Might be a good idea to go over all such spots and use this method (and inline it for performance?). It would then make `tenuring_threshold()` a private accessor, so the official API would be `is_tenurable(age)`, and no raw comparisons w/`tenuring_threshold()` that might become mutually inconsistent.

See raw comparisons in:
1. `ShenandoahYoungHeuristics::choose_young_collection_set`
2. `ShenandoahGenerationalEvacuationTask::maybe_promote_region`
3. `ShenandoahGenerationalHeuristics::choose_collection_set`
4. `ShenandoahGenerationalHeuristics::add_preselected_regions_to_collection_set`
5. `ShenandoahGlobalHeuristics::choose_global_collection_set`
6. `ShenandoahCollectionSet::add_region`
7. etc... there are several more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2305788307

From duke at openjdk.org  Thu Aug 28 01:19:41 2025
From: duke at openjdk.org (duke)
Date: Thu, 28 Aug 2025 01:19:41 GMT
Subject: RFR: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics
 considered poor user-experience [v2]
In-Reply-To: <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com>
References: <O8NEkCNP1GVe--X2sM7tUDmboVfTH2L28WoTlnOgeaY=.7234d126-94ff-43f3-9245-765e995eb099@github.com>
 <-G7AGJRPOYIhjHRPhx8fyuinCe-nLXZfbZO3Sz5Y7iM=.0b6d63d6-24e6-4618-9fa0-106dde9fa2f7@github.com>
Message-ID: <xf0KoZxUpHk-yn-3KozGNxuNUYavtAYYBlionSe-X1Q=.47cfdb37-5ee4-41f3-95b6-868ac9ca811f@github.com>

On Wed, 27 Aug 2025 22:47:58 GMT, Rui Li <duke at openjdk.org> wrote:

>> When generational shenandoah is enabled, it ignores the value of ShenandoahGCHeuristics input silently:
>> 
>> java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
>> openjdk version "25" 2025-09-16 LTS
>> OpenJDK Runtime Environment Corretto-25.0.0.36.1 (build 25+36-LTS)
>> OpenJDK 64-Bit Server VM Corretto-25.0.0.36.1 (build 25+36-LTS, mixed mode, sharing)
>> 
>> 
>> Adding additional guard rail to gen shen is not an option - it is actually by design that gen shen does not support non adaptive heuristics due to the complexity brought by generational design. 
>> 
>> So print out a warning to users to indicate that their `ShenandoahGCHeuristics` input is ignored.
>> 
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=static -version
>> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: static, because generational shenandoah only supports adaptive heuristics
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
>> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: junk, because generational shenandoah only supports adaptive heuristics
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=adaptive -version
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>> 
>> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -version  
>> openjdk version "26" 2026-03-17
>> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
>> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
>
> Rui Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update

@rgithubli 
Your change (at version 247dce42a12bad7d7a305819cb0057613912ca85) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/26968#issuecomment-3230808479

From duke at openjdk.org  Thu Aug 28 13:56:55 2025
From: duke at openjdk.org (Rui Li)
Date: Thu, 28 Aug 2025 13:56:55 GMT
Subject: Integrated: 8342640: GenShen: Silently ignoring ShenandoahGCHeuristics
 considered poor user-experience
In-Reply-To: <O8NEkCNP1GVe--X2sM7tUDmboVfTH2L28WoTlnOgeaY=.7234d126-94ff-43f3-9245-765e995eb099@github.com>
References: <O8NEkCNP1GVe--X2sM7tUDmboVfTH2L28WoTlnOgeaY=.7234d126-94ff-43f3-9245-765e995eb099@github.com>
Message-ID: <5GH1rWiImDIKhQZs_X6KFcWTfkfDDcq6MGyhuJ5XIdk=.77f33adc-910f-4984-95c6-50c26b604b13@github.com>

On Wed, 27 Aug 2025 18:26:22 GMT, Rui Li <duke at openjdk.org> wrote:

> When generational shenandoah is enabled, it ignores the value of ShenandoahGCHeuristics input silently:
> 
> java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
> openjdk version "25" 2025-09-16 LTS
> OpenJDK Runtime Environment Corretto-25.0.0.36.1 (build 25+36-LTS)
> OpenJDK 64-Bit Server VM Corretto-25.0.0.36.1 (build 25+36-LTS, mixed mode, sharing)
> 
> 
> Adding additional guard rail to gen shen is not an option - it is actually by design that gen shen does not support non adaptive heuristics due to the complexity brought by generational design. 
> 
> So print out a warning to users to indicate that their `ShenandoahGCHeuristics` input is ignored.
> 
> 
> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=static -version
> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: static, because generational shenandoah only supports adaptive heuristics
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
> 
> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=junk -version
> [0.001s][warning][gc] Ignoring -XX:ShenandoahGCHeuristics input: junk, because generational shenandoah only supports adaptive heuristics
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
> 
> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -XX:ShenandoahGCHeuristics=adaptive -version
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)
> 
> x64 (8342640) % java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational -version  
> openjdk version "26" 2026-03-17
> OpenJDK Runtime Environment Corretto-26.0.2.1.1 (slowdebug build 26+2-FR)
> OpenJDK 64-Bit Server VM Corretto-26.0.2.1.1 (slowdebug build 26+2-FR, mixed mode)

This pull request has now been integrated.

Changeset: 8051aaf0
Author:    Rui Li <ruiamzn at amazon.com>
Committer: SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8051aaf0685f7bb23bf3e23d32ad45b0bffbce7b
Stats:     7 lines in 1 file changed: 7 ins; 0 del; 0 mod

8342640: GenShen: Silently ignoring ShenandoahGCHeuristics considered poor user-experience

Reviewed-by: ysr, wkemper

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

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

From wkemper at openjdk.org  Thu Aug 28 14:28:14 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Aug 2025 14:28:14 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <DVkWI_DbJaBY69HA6O5gy_B5MV0ZoOvLxhE1YpdRYJU=.befc3e8f-3eb3-4952-90b4-c1a55cdf4955@github.com>

Merges tag jdk-21.0.9+5

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

Commit messages:
 - 8353748: Open source several swing tests batch6
 - 8340547: Starting many threads can delay safepoints
 - 8361478: GHA: Use MSYS2 from GHA runners
 - 8353293: Open source several swing tests batch4
 - 8358004: Delete applications/scimark/Scimark.java test
 - 8353000: Open source several swing tests batch2
 - 8353213: Open source several swing tests batch3
 - 8279005: sun/tools/jstat tests do not check for test case exit codes after JDK-8245129
 - 8365811: test/jdk/java/net/CookieHandler/B6644726.java failure - "Should have 5 cookies. Got only 4, expires probably didn't parse correctly"
 - 8361328: cds/appcds/dynamicArchive/TestAutoCreateSharedArchive.java archive timestamps comparison failed
 - ... and 34 more: https://git.openjdk.org/shenandoah-jdk21u/compare/d90297a8...36910541

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/216/files
  Stats: 6815 lines in 128 files changed: 5599 ins; 987 del; 229 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/216.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/216/head:pull/216

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/216

From wkemper at openjdk.org  Thu Aug 28 17:26:43 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Aug 2025 17:26:43 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v3]
In-Reply-To: <sxFgoDL6Qu745yVNjQMrA2p7skZVGLrCfJx_zNwBuHw=.a25132c7-50a5-471f-ab29-4b705f47408e@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
 <mnHSX8xRGTpfaMNVKW7xy8p4hP73PtU3ztB6d-cqhgk=.db53a740-135d-4fc0-bbea-1819cd76c70a@github.com>
 <sxFgoDL6Qu745yVNjQMrA2p7skZVGLrCfJx_zNwBuHw=.a25132c7-50a5-471f-ab29-4b705f47408e@github.com>
Message-ID: <zqn9aYO5BDbJ3BfcyBlhOlg3Xu-2fHZcGqS77qDIzGQ=.35173ccd-db98-475b-a02e-02bcfef13058@github.com>

On Thu, 28 Aug 2025 00:59:08 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahAgeCensus.hpp line 181:
>> 
>>> 179:   // Return true if this age is above the tenuring threshold.
>>> 180:   bool is_tenurable(uint age) const {
>>> 181:     return age > tenuring_threshold();
>> 
>> Another key change. This prevents the algorithm from seeing higher mortality rates caused by promotions in the cohort at tenuring age.
>
> The strict ">" says objects of age strictly greater than the computed tenuring threshold are tenurable, not those of that age. This might make sense if it were used at all the places where tenuring decisions were being made during evacuation. Was that the intention?
> 
> That doesn't seem to be the case -- there are pre-existing places in the code where a raw comparison with the tenuring threshold are made that don't do the strict check. Might be a good idea to go over all such spots and use this method (and inline it for performance?). It would then make `tenuring_threshold()` a private accessor, so the official API would be `is_tenurable(age)`, and no raw comparisons w/`tenuring_threshold()` that might become mutually inconsistent.
> 
> See raw comparisons in:
> 1. `ShenandoahYoungHeuristics::choose_young_collection_set`
> 2. `ShenandoahGenerationalEvacuationTask::maybe_promote_region`
> 3. `ShenandoahGenerationalHeuristics::choose_collection_set`
> 4. `ShenandoahGenerationalHeuristics::add_preselected_regions_to_collection_set`
> 5. `ShenandoahGlobalHeuristics::choose_global_collection_set`
> 6. `ShenandoahCollectionSet::add_region`
> 7. etc... there are several more.

Yes, that the intention was to make the comparison strictly greater than (to prevent the adaptive tenuring algorithm from looking at cohorts that may have been promoted). I'll make the changes you suggested. Methods defined in headers are implicitly inline.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26906#discussion_r2308056678

From wkemper at openjdk.org  Thu Aug 28 19:12:43 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Aug 2025 19:12:43 GMT
Subject: RFR: 8365956: GenShen: Adaptive tenuring threshold algorithm may
 raise threshold prematurely [v4]
In-Reply-To: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
References: <a0xbCmn50ELDPEhLMbdtdnTGeC6Io9Uammhf6XF4cZM=.6003fa95-8b51-4a56-b8cd-b7d53b4ba7fd@github.com>
Message-ID: <DeyNfL_DL3Lt0u4ofygtR8h9tOnFl3VDvP_SpncvPg8=.069cac19-aa43-4ce5-a911-dbf396755ad9@github.com>

> The adaptive tenuring algorithm has been modified to begin its evaluation of mortality rates from the current tenuring threshold. To compliment this change, objects must also now be strictly above the tenuring threshold to be promoted (instead of greater-than-or-equal).

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

  Be consistent when comparing tenuring threshold with ages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26906/files
  - new: https://git.openjdk.org/jdk/pull/26906/files/b9e16d26..658f76f7

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

  Stats: 84 lines in 12 files changed: 42 ins; 20 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/26906.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26906/head:pull/26906

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

From wkemper at openjdk.org  Thu Aug 28 19:16:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Aug 2025 19:16:01 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <mTLjSJz8NjIGeHWCs300Ps3-AVN0ouJhYEt8F7MAXqE=.024e3c2c-dbfb-467e-bcdb-f76d741276dc@github.com>
References: <zQZpfNAhUefAuKiT84Os_GeRk_6og22iyg_vyWY-htw=.5c645ca4-5d47-469d-841f-726eddf0e2e2@github.com>
 <mTLjSJz8NjIGeHWCs300Ps3-AVN0ouJhYEt8F7MAXqE=.024e3c2c-dbfb-467e-bcdb-f76d741276dc@github.com>
Message-ID: <6LOAaDsY1FWbV03ehSbGDWzECjN-xXcCdIAX5Fbxr0M=.ec26e767-36f3-47c7-a087-23bf39704645@github.com>

On Tue, 26 Aug 2025 22:26:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Merges tag jdk-21.0.9+4
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

Superseded by https://github.com/openjdk/shenandoah-jdk21u/pull/216.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/215#issuecomment-3234646276

From wkemper at openjdk.org  Thu Aug 28 19:16:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Aug 2025 19:16:00 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v3]
In-Reply-To: <zQZpfNAhUefAuKiT84Os_GeRk_6og22iyg_vyWY-htw=.5c645ca4-5d47-469d-841f-726eddf0e2e2@github.com>
References: <zQZpfNAhUefAuKiT84Os_GeRk_6og22iyg_vyWY-htw=.5c645ca4-5d47-469d-841f-726eddf0e2e2@github.com>
Message-ID: <o31FtacSdjJpaUiRjkPJGwzvMw9vfMUUfcXZoJxyVNE=.f21653f3-0b60-4f8c-87e4-25d79ea31d08@github.com>

> Merges tag jdk-21.0.9+4

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

 - Merge tag 'jdk-21.0.9+4' into merge-jdk-21.0.9+4
   
   Added tag jdk-21.0.9+4 for changeset 3949aae8cd88
 - 8325397: sun/java2d/Disposer/TestDisposerRace.java fails in linux-aarch64
   
   Backport-of: e0c46d589b12aa644e12e4a4c9e84e035f7cf98d
 - 8353126: Open source events tests batch1
   
   Backport-of: cd5a43a98030a534babb01cfc4521e7e9bc89b91
 - 8352860: Open source events tests batch0
   
   Backport-of: d4d18350f367a18813d0d418169e852c1530418e
 - 8348135: Fix couple of problem listing entries in test/hotspot/jtreg/ProblemList-Virtual.txt
   
   Backport-of: 16a1d0a7ff04acf70573d303141a41dadca08f7a
 - 8352677: Opensource JMenu tests - series2
   
   Backport-of: cfc648bd17cc79b1c3e6f69d3559749e937261b2
 - 8185429: [macos] After a modal dialog is closed, no window becomes active
   
   Backport-of: 3a26bbcebc2f7d11b172f2b16192a3adefeb8111
 - 8357285: JSR166 Test case testShutdownNow_delayedTasks failed
   
   Backport-of: 6a07820483bcf3e9d7df27ee496db43675f1c002
 - 8341370: Test java/awt/Frame/ShapeNotSetSometimes/ShapeNotSetSometimes.java fails intermittently on macOS-aarch64
   
   Reviewed-by: mbaesken
   Backport-of: 84a67e83e3f4fcb6be6802d12b0788850a3845b5
 - 8346255: java/lang/management/ThreadMXBean/VirtualThreadDeadlocks.java finds no deadlock
   
   Backport-of: 9ebb5d42d43a743cf3a5197c7dabe46ac8120474
 - ... and 18 more: https://git.openjdk.org/shenandoah-jdk21u/compare/4fe18d25...c9496fe8

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/215/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/215/files/3949aae8..c9496fe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=215&range=02
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=215&range=01-02

  Stats: 29904 lines in 289 files changed: 24522 ins; 3576 del; 1806 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/215.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/215/head:pull/215

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/215

From wkemper at openjdk.org  Thu Aug 28 19:16:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Aug 2025 19:16:01 GMT
Subject: Withdrawn: Merge openjdk/jdk21u:master
In-Reply-To: <zQZpfNAhUefAuKiT84Os_GeRk_6og22iyg_vyWY-htw=.5c645ca4-5d47-469d-841f-726eddf0e2e2@github.com>
References: <zQZpfNAhUefAuKiT84Os_GeRk_6og22iyg_vyWY-htw=.5c645ca4-5d47-469d-841f-726eddf0e2e2@github.com>
Message-ID: <HYH5XByfgl9utPZtfsvKzPyA5UxIYdvUl_1tX7E0gps=.d360ed37-447e-47dd-94d8-c01fe35e205f@github.com>

On Thu, 21 Aug 2025 14:23:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+4

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/215

From wkemper at openjdk.org  Thu Aug 28 19:16:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Aug 2025 19:16:18 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <DVkWI_DbJaBY69HA6O5gy_B5MV0ZoOvLxhE1YpdRYJU=.befc3e8f-3eb3-4952-90b4-c1a55cdf4955@github.com>
References: <DVkWI_DbJaBY69HA6O5gy_B5MV0ZoOvLxhE1YpdRYJU=.befc3e8f-3eb3-4952-90b4-c1a55cdf4955@github.com>
Message-ID: <NiDmxJhbZskh8aoUOaSHdkDST962Notn0aap9ZPtBa0=.c6f180e2-a815-4d35-a81e-6b068090defb@github.com>

> Merges tag jdk-21.0.9+5

William Kemper has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase.

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/216/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/216/files/36910541..36910541

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=216&range=01
 - incr: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=216&range=00-01

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/216.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/216/head:pull/216

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/216

From wkemper at openjdk.org  Thu Aug 28 19:16:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 28 Aug 2025 19:16:18 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <DVkWI_DbJaBY69HA6O5gy_B5MV0ZoOvLxhE1YpdRYJU=.befc3e8f-3eb3-4952-90b4-c1a55cdf4955@github.com>
References: <DVkWI_DbJaBY69HA6O5gy_B5MV0ZoOvLxhE1YpdRYJU=.befc3e8f-3eb3-4952-90b4-c1a55cdf4955@github.com>
Message-ID: <UH_TMccD2zKYMgQc02mb8tqRznTLA6SIIuHdI_eWhdE=.2cc3486d-370b-4fc0-ab30-7d2f325082cd@github.com>

On Thu, 28 Aug 2025 14:22:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.9+5

This pull request has now been integrated.

Changeset: d0d9b7e3
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/d0d9b7e33be176e7cda01258ffa5d574715c9089
Stats:     6815 lines in 128 files changed: 5599 ins; 987 del; 229 mod

Merge

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

PR: https://git.openjdk.org/shenandoah-jdk21u/pull/216

From cslucas at openjdk.org  Fri Aug 29 00:08:16 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Fri, 29 Aug 2025 00:08:16 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
Message-ID: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>

Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.

The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

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

Commit messages:
 - Change shenandoah nmethod entry barrier fence.

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

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

From shade at openjdk.org  Fri Aug 29 06:35:41 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 29 Aug 2025 06:35:41 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
In-Reply-To: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
Message-ID: <notSe0AbMi16PxhpA10j_6wP1DYOs0YwuW4OiV9gd7Q=.317dc2b1-afa2-4b28-8b5e-5a42869512ec@github.com>

On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
> 
> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

I see `virtual NMethodPatchingType nmethod_patching_type() { return NMethodPatchingType::conc_data_patch; }` in Shenandoah PPC64 and RISC-V barrier sets as well. Those should likely go away as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3235890936

From dzhang at openjdk.org  Fri Aug 29 07:04:41 2025
From: dzhang at openjdk.org (Dingli Zhang)
Date: Fri, 29 Aug 2025 07:04:41 GMT
Subject: RFR: 8364936: Shenandoah: Switch nmethod entry barriers to
 conc_instruction_and_data_patch
In-Reply-To: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
References: <hA8KRrjiWgdQsG7TWURlzOna1OPV0y76a55vfs5X9sU=.2e392c8e-d180-42e7-840a-60085d7426df@github.com>
Message-ID: <133lBie4di5uGvczIdenGraY_OY6vmMRIY4CFOc2xYo=.c1635af8-f715-456c-910c-a63809916179@github.com>

On Fri, 29 Aug 2025 00:02:42 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please, review this patch to make nmethod entry barriers use `conc-instruction-and-data-patch` fence mechanics when ShenandoahGC is being used on AArch64. The patch also removes (including from JVMCI interface) the old constant that was being used only by Shenandoah on AArch64.
> 
> The patch has been tested with functional and performance benchmarks on AArch64. Improvements in DaCapo and Renaissance benchmarks can be as high as 30%. Maximum critical Jops in SPEC improved by ~10%.

Thanks for this patch! I've made similar changes on RISC-V.
Could you please add those as well? https://github.com/DingliZhang/jdk/commit/495b07fe690ef7e3fe828fd2be27c4259c739c23
I've tested the `hotspot_gc_shenandoah` on the SG2042 with fastdebug and found no failures.
Specjbb testing on the SG2042 is ongoing. I'll update the results later.

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

PR Comment: https://git.openjdk.org/jdk/pull/26999#issuecomment-3235958508

From gli at openjdk.org  Sat Aug 30 10:54:51 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sat, 30 Aug 2025 10:54:51 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code
Message-ID: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>

Hi all,

After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.

Test:
All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).

Best Regards,
-- Guoxiong

[1] https://bugs.openjdk.org/browse/JDK-8338977

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

Commit messages:
 - JDK-8357188

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

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

From ayang at openjdk.org  Sat Aug 30 11:42:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sat, 30 Aug 2025 11:42:41 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code
In-Reply-To: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
Message-ID: <SqzDQpN4sCyju1MkdhzOtylCfk1ZdUajexLEkBCPMYQ=.217b3776-9189-42db-b313-17d203499322@github.com>

On Sat, 30 Aug 2025 10:49:45 GMT, Guoxiong Li <gli at openjdk.org> wrote:

> Hi all,
> 
> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.
> 
> Test:
> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).
> 
> Best Regards,
> -- Guoxiong
> 
> [1] https://bugs.openjdk.org/browse/JDK-8338977

src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 197:

> 195:   // an excessive amount of time is being spent doing collections
> 196:   // and caused a null to be returned.  If a null is not returned,
> 197:   // "gc_time_limit_was_exceeded" has an undefined meaning.

Outdated comments about "gc_time_limit_was_exceeded".

Looks good otherwise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27020#discussion_r2311911209

From gli at openjdk.org  Sun Aug 31 11:31:32 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 31 Aug 2025 11:31:32 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v2]
In-Reply-To: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
Message-ID: <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com>

> Hi all,
> 
> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.
> 
> Test:
> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).
> 
> Best Regards,
> -- Guoxiong
> 
> [1] https://bugs.openjdk.org/browse/JDK-8338977

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

  Remove outdated comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27020/files
  - new: https://git.openjdk.org/jdk/pull/27020/files/d617cbd5..949e1620

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

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

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

From gli at openjdk.org  Sun Aug 31 11:31:32 2025
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 31 Aug 2025 11:31:32 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v2]
In-Reply-To: <SqzDQpN4sCyju1MkdhzOtylCfk1ZdUajexLEkBCPMYQ=.217b3776-9189-42db-b313-17d203499322@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
 <SqzDQpN4sCyju1MkdhzOtylCfk1ZdUajexLEkBCPMYQ=.217b3776-9189-42db-b313-17d203499322@github.com>
Message-ID: <XCvYwzvyBddMFXq6DG8zRZl0utMC3kmliFpKmpVi4iA=.2f63ecc1-9f87-4297-a5e8-09e1d31e148c@github.com>

On Sat, 30 Aug 2025 11:40:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove outdated comments.
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.hpp line 197:
> 
>> 195:   // an excessive amount of time is being spent doing collections
>> 196:   // and caused a null to be returned.  If a null is not returned,
>> 197:   // "gc_time_limit_was_exceeded" has an undefined meaning.
> 
> Outdated comments about "gc_time_limit_was_exceeded".
> 
> Looks good otherwise.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27020#discussion_r2312417378

From ayang at openjdk.org  Sun Aug 31 13:09:41 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Sun, 31 Aug 2025 13:09:41 GMT
Subject: RFR: 8357188: Remove the field
 MemAllocator::Allocation::_overhead_limit_exceeded and the related code [v2]
In-Reply-To: <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com>
References: <0qHdlghXGyq966nZz5mrxkDrTLtN-FNb7zqRSewz92o=.84d3673c-7526-4ad7-a37d-17c3637ce918@github.com>
 <4suEaL8ElbI5gbPNk1Sq0hO4j5v3SvHUemCfLDbERiY=.1d0d93ff-15f7-4f04-8cb5-a705fc2ddfce@github.com>
Message-ID: <UCykifZH-OMTlrIBaS9UdfJphKx0klutu1XPclkWsnw=.68ff6e9a-a7a9-4dfd-9035-b1f6a078d421@github.com>

On Sun, 31 Aug 2025 11:31:32 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Hi all,
>> 
>> After JDK-8338977 [1], the field `MemAllocator::Allocation::_overhead_limit_exceeded` and the parameter `gc_overhead_limit_was_exceeded` of the method `CollectedHeap::mem_allocate` are not used by any GC. This patch removes them.
>> 
>> Test:
>> All the tests of the command `make test TEST="hotspot:hotspot_gc"` passed locally (linux, x86_64, release build).
>> 
>> Best Regards,
>> -- Guoxiong
>> 
>> [1] https://bugs.openjdk.org/browse/JDK-8338977
>
> Guoxiong Li has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove outdated comments.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27020#pullrequestreview-3171619294