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