From rkennke at openjdk.org  Mon Dec  2 11:15:12 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 2 Dec 2024 11:15:12 GMT
Subject: RFR: 8345293: Fix generational Shenandoah with compact headers
Message-ID: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>

See bug for crash details.

The problem is in the code that gets the object age out of the mark-word. That code has a special cases for when an object is monitor locked, in which case it fetches the displaced header out of the monitor and extracts the age from there. However, with compact headers, we're running with ObjectMonitorTable, and decoding the monitor-locked mark-word crashes.

The fix is simple: when we are running with ObjectMonitorTable, the mark-word never gets overloaded by locking, so we can return the age straight out of the mark-word.

Testing:
 - [x] hotspot_gc_shenandoah +UCOH

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

Commit messages:
 - 8345293: Fix generational Shenandoah with compact headers

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

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

From shade at openjdk.org  Mon Dec  2 11:58:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 2 Dec 2024 11:58:39 GMT
Subject: RFR: 8345293: Fix generational Shenandoah with compact headers
In-Reply-To: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
References: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
Message-ID: <H8qIDILd2kncw33XrS2vhHNThcjk9XfYK5A_KaJQuxM=.39751eaf-8fc4-4fd7-94bd-f4602ec2a45b@github.com>

On Mon, 2 Dec 2024 11:09:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> See bug for crash details.
> 
> The problem is in the code that gets the object age out of the mark-word. That code has a special cases for when an object is monitor locked, in which case it fetches the displaced header out of the monitor and extracts the age from there. However, with compact headers, we're running with ObjectMonitorTable, and decoding the monitor-locked mark-word crashes.
> 
> The fix is simple: when we are running with ObjectMonitorTable, the mark-word never gets overloaded by locking, so we can return the age straight out of the mark-word.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah +UCOH

Looks good.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22477#pullrequestreview-2472499004

From stuefe at openjdk.org  Mon Dec  2 13:52:37 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 2 Dec 2024 13:52:37 GMT
Subject: RFR: 8345293: Fix generational Shenandoah with compact headers
In-Reply-To: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
References: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
Message-ID: <4oavGU_b5J322sriy37B9AC_zoIC6mvfADPFSRpcDYs=.24381e90-ebd6-47ff-9ee7-5e098f9c1aab@github.com>

On Mon, 2 Dec 2024 11:09:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> See bug for crash details.
> 
> The problem is in the code that gets the object age out of the mark-word. That code has a special cases for when an object is monitor locked, in which case it fetches the displaced header out of the monitor and extracts the age from there. However, with compact headers, we're running with ObjectMonitorTable, and decoding the monitor-locked mark-word crashes.
> 
> The fix is simple: when we are running with ObjectMonitorTable, the mark-word never gets overloaded by locking, so we can return the age straight out of the mark-word.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah +UCOH

Good.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22477#pullrequestreview-2472754459

From ysr at openjdk.org  Mon Dec  2 15:47:42 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 2 Dec 2024 15:47:42 GMT
Subject: RFR: 8345293: Fix generational Shenandoah with compact headers
In-Reply-To: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
References: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
Message-ID: <h9ikapUhWfmf1RFqXV608MerINGFOMnM015E2sC_mUE=.4810d1d6-84f5-441c-92be-4fa7a6e6e692@github.com>

On Mon, 2 Dec 2024 11:09:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> See bug for crash details.
> 
> The problem is in the code that gets the object age out of the mark-word. That code has a special cases for when an object is monitor locked, in which case it fetches the displaced header out of the monitor and extracts the age from there. However, with compact headers, we're running with ObjectMonitorTable, and decoding the monitor-locked mark-word crashes.
> 
> The fix is simple: when we are running with ObjectMonitorTable, the mark-word never gets overloaded by locking, so we can return the age straight out of the mark-word.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah +UCOH

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22477#pullrequestreview-2473077721

From gziemski at openjdk.org  Mon Dec  2 16:00:48 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 2 Dec 2024 16:00:48 GMT
Subject: RFR: 8328944: NMT reports "unknown" memory [v2]
In-Reply-To: <gOgY8WianvtvdUezeU0iMihioxoN4JEhdscPeMIkAvk=.badfee4f-f4d6-4835-aa6d-b4bfa3ae41b6@github.com>
References: <q410XZ4jLQtnc1oedcMow7N8Dhhb9nw1dJYggeY2f6U=.00b23ac6-e99c-4784-ab1e-150f04eb7cc8@github.com>
 <6Up1fGCFJl2HAUGl6IBKEDRodItQLn5TigHJEdzZpbU=.5f5ae17c-edc4-4dd8-ae09-8e8ae8567354@github.com>
 <gOgY8WianvtvdUezeU0iMihioxoN4JEhdscPeMIkAvk=.badfee4f-f4d6-4835-aa6d-b4bfa3ae41b6@github.com>
Message-ID: <NpXGor-H932EK7Pn1DDvOMYYPhnudXS0hjb8rPErA6A=.65312f6b-340b-4789-acdb-e45531f3fa92@github.com>

On Wed, 20 Nov 2024 11:32:25 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - avoid using mtNone
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8328944
>>  - revert, we will re-do with a smaller change
>>  - remove more mtNone
>>  - remove API that allows to change the mem_tag for virtual memory, feedback
>>  - do not allow default parameter for mtNone
>
> Thanks for taking this issue. I add my points here:
> 
> 1) The `ReservedSpace` objects in these files have to have extra MemTag (`mtTest`) parameter:
>   - test_freeRegionList.cpp
>   - test_virtualspace.cpp
>   - test_virtualMemoryTracker.cpp
>  
> 2) The `mtNone` as default value for the parameter should be removed from the following functions, otherwise Unknown memory types can still be reported:
> 
> 
> 
> Source root ? src/hotspot/os/windows/os_windows.cpp:
>     3239: static char* map_or_reserve_memory_aligned(size_t size, size_t alignment, int file_desc, MemTag mem_tag = mtNone) {
>   3239    assert(is_aligned(alignment, os::vm_allocation_granularity()),
>   3240    assert(is_aligned(alignment, os::vm_allocation_granularity()),
> 
> Source root ? src/hotspot/share/cds/filemap.cpp:
>   1773                          char *addr, size_t bytes, bool read_only,
>   1774:                         bool allow_exec, MemTag mem_tag = mtNone) {
>   1775    char* mem = os::map_memory(fd, file_name, file_offset, addr, bytes,
> 
> Source root ? src/hotspot/share/memory/virtualspace.hpp:
>   63    void initialize(size_t size, size_t alignment, size_t page_size,
>   64    void initialize(size_t size, size_t alignment, size_t page_size,
>   65:                   char* requested_address, bool executable, MemTag mem_tag = mtNone);
>   65  
>   66  
> 
> Source root ? src/hotspot/share/nmt/memReporter.hpp:
>   110    void print_total(size_t reserved, size_t committed, size_t peak = 0) const;
>   111:   void print_malloc(const MemoryCounter* c, MemTag mem_tag = mtNone) const;
>   112    void print_virtual_memory(size_t reserved, size_t committed, size_t peak) const;
> 
> Source root ? src/hotspot/share/nmt/memTracker.hpp:
>   123    static inline void record_virtual_memory_reserve(void* addr, size_t size, const NativeCallStack& stack,
>   124:     MemTag mem_tag = mtNone) {
>   125      assert_post_init();
> 
>   149    static inline void record_virtual_memory_reserve_and_commit(void* addr, size_t size,
>   150:     const NativeCallStack& stack, MemTag mem_tag = mtNone) {
> 
> Source root ? src/hotspot/share/nmt/virtualMemoryTracker.hpp:
>   299    ReservedMemoryRegion(address base, size_t size, const NativeCallStack& stack,
>   300:     MemTag mem_tag = mtNone) :
> 
>   383:   static bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MemTag mem_tag = mtNone);
>   384  
> 
> Source root ? src/hotspot/share/runtime/os.hpp:
>   453:   static char*  reserve_memory(size_t bytes, bool executable = false, MemTag mem_tag = mtNone);
> 
>   46...

@afshin-zafari @tstuefe @stefank

ping

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

PR Comment: https://git.openjdk.org/jdk/pull/21843#issuecomment-2511920933

From xpeng at openjdk.org  Mon Dec  2 21:56:08 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 2 Dec 2024 21:56:08 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v16]
In-Reply-To: <vIbu5XmN02KaE98zc0TwAS2ot-zFsrV3K-3ZgomzT2g=.6bcfeead-7389-47a9-a795-a6dc3a4f77c1@github.com>
References: <4Vf5hDoYaZyyFJ3IS3Fxr9kNMhSoiJY5K4BqAaKXI-I=.60fe828e-6998-4438-a75a-0859604bae44@github.com>
 <vIbu5XmN02KaE98zc0TwAS2ot-zFsrV3K-3ZgomzT2g=.6bcfeead-7389-47a9-a795-a6dc3a4f77c1@github.com>
Message-ID: <48iTXfLRJ9YrdU8dg2--7aXBTQKWwbGX2a4FZUO8qTY=.c405031c-3baf-4034-93e6-5f19642e5322@github.com>

On Mon, 25 Nov 2024 22:25:39 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> All the shenandoah passed, still waiting for our test farm to verify performance.
>> 
>> Reset marking bitmaps after collection cycle, for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
>> 
>> I have run same workload for 30s with shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly(283us to 109us for GenShen, 276us to 167us for classic shenandoah. 
>> 
>> Classic shenandoah baseline:
>> 
>> [30.973s][info][gc,stats    ] Concurrent Reset               =    0.148 s (a =      276 us) (n =   536) (lvls, us =      141,      205,      240,      291,      694)
>> [30.973s][info][gc,stats    ] Pause Init Mark (G)            =    0.136 s (a =      253 us) (n =   536) (lvls, us =      119,      242,      254,      264,      926)
>> [30.973s][info][gc,stats    ] Pause Init Mark (N)            =    0.047 s (a =       87 us) (n =   536) (lvls, us =       62,       84,       88,       91,      110)
>> ...
>> 
>> 
>> Classic shenandoah reset bitmaps after cycle:
>> 
>> [30.967s][info][gc,stats    ] Concurrent Reset               =    0.109 s (a =      167 us) (n =   652) (lvls, us =       48,      113,      139,      160,      888)
>> [30.967s][info][gc,stats    ] Concurrent Reset After Collect =    0.085 s (a =      132 us) (n =   648) (lvls, us =      107,      121,      125,      131,      532)
>> [30.967s][info][gc,stats    ] Pause Init Mark (G)            =    0.189 s (a =      289 us) (n =   652) (lvls, us =      117,      260,      277,      291,     2297)
>> [30.967s][info][gc,stats    ] Pause Init Mark (N)            =    0.058 s (a =       89 us) (n =   652) (lvls, us =       62,       85,       89,       94,      143)
>> ...
>> 
>> 
>> GenShen baseline
>> 
>> [31.008s][info][gc,stats    ] Concurrent Reset               =    0.107 s (a =      283 us) (n =   379) (lvls, us =      143,      225,      283,      330,      753)
>> [31.008s][info][gc,stats    ] Pause Init Mark (G)            =    0.098 s (a =      259 us) (n =   379) (lvls, us =      104,      227,      262,      305,     1033)
>> [31.008s][info][gc,stats    ] Pause Init Mark (N)            =    0.034 s (a =       90 us) (n =   379) (lvls, us =       67,       81,       89,       99,      130)
>> ...
>> 
>> 
>> GenShen reset bitmaps after cycle
>> 
>> 
>> [30.977s][info][gc,stats    ] Concurrent Reset               =    0.050 s (a =      109 us) (n =   462) (l...
>
> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge branch 'shenandoah' into genshen-JDK-8338737
>  - Merge branch 'openjdk:master' into genshen-JDK-8338737
>  - Merge branch 'openjdk:master' into genshen-JDK-8338737
>  - Merge branch 'openjdk:master' into genshen-JDK-8338737
>  - Move set_mark_incomplete into reset_mark_bitmap
>  - fix test failures
>  - set_mark_incomplete should be always set after resetting bitmap
>  - Merge branch 'openjdk:master' into genshen-JDK-8338737
>  - Not reset bitmap after ShenandoahOldGC
>  - Capture Top At Mark Start for *this* generation
>  - ... and 30 more: https://git.openjdk.org/shenandoah/compare/e22e8d56...375f2bd3

I'll revisit the changes and re-work it on tip w/ a new PR since Genshen has landed on TIP.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/516#issuecomment-2513005624

From xpeng at openjdk.org  Mon Dec  2 21:56:08 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 2 Dec 2024 21:56:08 GMT
Subject: Withdrawn: 8338737: Shenandoah: Reset marking bitmaps after the cycle
In-Reply-To: <4Vf5hDoYaZyyFJ3IS3Fxr9kNMhSoiJY5K4BqAaKXI-I=.60fe828e-6998-4438-a75a-0859604bae44@github.com>
References: <4Vf5hDoYaZyyFJ3IS3Fxr9kNMhSoiJY5K4BqAaKXI-I=.60fe828e-6998-4438-a75a-0859604bae44@github.com>
Message-ID: <ra0Gf7f6SSLDjexbQ5wpgKfFZEohGz7tIp6SoVpuOmE=.a1a51138-b586-464d-a99c-5b22a3c734b4@github.com>

On Thu, 17 Oct 2024 08:29:43 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> All the shenandoah passed, still waiting for our test farm to verify performance.
> 
> Reset marking bitmaps after collection cycle, for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
> 
> I have run same workload for 30s with shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly(283us to 109us for GenShen, 276us to 167us for classic shenandoah. 
> 
> Classic shenandoah baseline:
> 
> [30.973s][info][gc,stats    ] Concurrent Reset               =    0.148 s (a =      276 us) (n =   536) (lvls, us =      141,      205,      240,      291,      694)
> [30.973s][info][gc,stats    ] Pause Init Mark (G)            =    0.136 s (a =      253 us) (n =   536) (lvls, us =      119,      242,      254,      264,      926)
> [30.973s][info][gc,stats    ] Pause Init Mark (N)            =    0.047 s (a =       87 us) (n =   536) (lvls, us =       62,       84,       88,       91,      110)
> ...
> 
> 
> Classic shenandoah reset bitmaps after cycle:
> 
> [30.967s][info][gc,stats    ] Concurrent Reset               =    0.109 s (a =      167 us) (n =   652) (lvls, us =       48,      113,      139,      160,      888)
> [30.967s][info][gc,stats    ] Concurrent Reset After Collect =    0.085 s (a =      132 us) (n =   648) (lvls, us =      107,      121,      125,      131,      532)
> [30.967s][info][gc,stats    ] Pause Init Mark (G)            =    0.189 s (a =      289 us) (n =   652) (lvls, us =      117,      260,      277,      291,     2297)
> [30.967s][info][gc,stats    ] Pause Init Mark (N)            =    0.058 s (a =       89 us) (n =   652) (lvls, us =       62,       85,       89,       94,      143)
> ...
> 
> 
> GenShen baseline
> 
> [31.008s][info][gc,stats    ] Concurrent Reset               =    0.107 s (a =      283 us) (n =   379) (lvls, us =      143,      225,      283,      330,      753)
> [31.008s][info][gc,stats    ] Pause Init Mark (G)            =    0.098 s (a =      259 us) (n =   379) (lvls, us =      104,      227,      262,      305,     1033)
> [31.008s][info][gc,stats    ] Pause Init Mark (N)            =    0.034 s (a =       90 us) (n =   379) (lvls, us =       67,       81,       89,       99,      130)
> ...
> 
> 
> GenShen reset bitmaps after cycle
> 
> 
> [30.977s][info][gc,stats    ] Concurrent Reset               =    0.050 s (a =      109 us) (n =   462) (lvls, us =       54,       77,      100,      125,      496)
> [30.977s][...

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah/pull/516

From wkemper at openjdk.org  Mon Dec  2 22:51:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 2 Dec 2024 22:51:50 GMT
Subject: RFR: 8345346: Shenandoah: Description of ShenandoahGCMode still refers
 to incremental update mode
Message-ID: <SGIhkoxOBgGNAHPxnQIjg9-WXfwMaCjhHHrIR1b-jWQ=.4f1f78b1-000a-478b-ab67-34c2429290f3@github.com>

The incremental update mode has been removed and is no longer supported.

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

Commit messages:
 - Remove reference to incremental update mode

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

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

From ysr at openjdk.org  Mon Dec  2 22:57:45 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 2 Dec 2024 22:57:45 GMT
Subject: RFR: 8345346: Shenandoah: Description of ShenandoahGCMode still
 refers to incremental update mode
In-Reply-To: <SGIhkoxOBgGNAHPxnQIjg9-WXfwMaCjhHHrIR1b-jWQ=.4f1f78b1-000a-478b-ab67-34c2429290f3@github.com>
References: <SGIhkoxOBgGNAHPxnQIjg9-WXfwMaCjhHHrIR1b-jWQ=.4f1f78b1-000a-478b-ab67-34c2429290f3@github.com>
Message-ID: <3YqrRBP2ACAzhlHZRXaKMmB-awPFRuiHXyDs66fpQOw=.37cfe055-529b-4f4b-b4d3-ad0c98ce0926@github.com>

On Mon, 2 Dec 2024 22:46:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The incremental update mode has been removed and is no longer supported.

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22502#pullrequestreview-2474111019

From wkemper at openjdk.org  Mon Dec  2 22:57:46 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 2 Dec 2024 22:57:46 GMT
Subject: Integrated: 8345346: Shenandoah: Description of ShenandoahGCMode still
 refers to incremental update mode
In-Reply-To: <SGIhkoxOBgGNAHPxnQIjg9-WXfwMaCjhHHrIR1b-jWQ=.4f1f78b1-000a-478b-ab67-34c2429290f3@github.com>
References: <SGIhkoxOBgGNAHPxnQIjg9-WXfwMaCjhHHrIR1b-jWQ=.4f1f78b1-000a-478b-ab67-34c2429290f3@github.com>
Message-ID: <tDQ8HvrBXt4cN5HkghDYuEI6IAYFjpPHRFkAzFPtqFc=.fe90ccf0-096c-478d-baf7-85a5f44a4669@github.com>

On Mon, 2 Dec 2024 22:46:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The incremental update mode has been removed and is no longer supported.

This pull request has now been integrated.

Changeset: 1997e89d
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1997e89ddf9fba7c6eea6c96bd0b5426576d4460
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8345346: Shenandoah: Description of ShenandoahGCMode still refers to incremental update mode

Reviewed-by: ysr

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

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

From ysr at openjdk.org  Tue Dec  3 02:47:08 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 3 Dec 2024 02:47:08 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks
Message-ID: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>

Fix documentation comment.

I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.

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

Commit messages:
 - Fix up documentation comment.

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

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

From shade at openjdk.org  Tue Dec  3 16:16:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 3 Dec 2024 16:16:40 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks
In-Reply-To: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
Message-ID: <O0GHFkQ4760Q0mjdxNIKexoyE45QZBZrqLVNrrheDBw=.5e754dd7-1578-4967-88c2-d3909cc0695d@github.com>

On Tue, 3 Dec 2024 02:41:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Fix documentation comment.
> 
> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.

I still don't quite understand if we need to implement `CardTableBarrierSet::on_slowpath_allocation_exit`. I see `SharedRuntime::on_slowpath_allocation_exit` is called from different places in VM. Are those really subsumed by safepoints?

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

PR Comment: https://git.openjdk.org/jdk/pull/22507#issuecomment-2514996606

From rkennke at openjdk.org  Tue Dec  3 16:48:42 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Dec 2024 16:48:42 GMT
Subject: RFR: 8345293: Fix generational Shenandoah with compact headers
In-Reply-To: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
References: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
Message-ID: <CGJg5AvOaoCW5805mCxXeWyQ1guWz2BPmRuaTApcl0s=.86af9404-1f6e-4230-b992-241ac5b2d987@github.com>

On Mon, 2 Dec 2024 11:09:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> See bug for crash details.
> 
> The problem is in the code that gets the object age out of the mark-word. That code has a special cases for when an object is monitor locked, in which case it fetches the displaced header out of the monitor and extracts the age from there. However, with compact headers, we're running with ObjectMonitorTable, and decoding the monitor-locked mark-word crashes.
> 
> The fix is simple: when we are running with ObjectMonitorTable, the mark-word never gets overloaded by locking, so we can return the age straight out of the mark-word.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah +UCOH

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/22477#issuecomment-2515074738

From rkennke at openjdk.org  Tue Dec  3 16:48:42 2024
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 3 Dec 2024 16:48:42 GMT
Subject: Integrated: 8345293: Fix generational Shenandoah with compact headers
In-Reply-To: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
References: <stu4nz6XmpuHZUWOkkLleX2ydF0ZGahvCvjmaoNjqG4=.cd5f8b60-1beb-4d1d-a96c-f38c5f8dd07f@github.com>
Message-ID: <-DdF0QuKZhADfsHN75TUl4hsiMfUva11bgDbxSGUpe8=.d31cc97b-d3cb-4cb6-9e3d-6f4bdec92f01@github.com>

On Mon, 2 Dec 2024 11:09:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> See bug for crash details.
> 
> The problem is in the code that gets the object age out of the mark-word. That code has a special cases for when an object is monitor locked, in which case it fetches the displaced header out of the monitor and extracts the age from there. However, with compact headers, we're running with ObjectMonitorTable, and decoding the monitor-locked mark-word crashes.
> 
> The fix is simple: when we are running with ObjectMonitorTable, the mark-word never gets overloaded by locking, so we can return the age straight out of the mark-word.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah +UCOH

This pull request has now been integrated.

Changeset: e9f6ba05
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9f6ba05264ecb2f1ca3983ea503778f301bf280
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8345293: Fix generational Shenandoah with compact headers

Reviewed-by: shade, stuefe, ysr

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

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

From ysr at openjdk.org  Tue Dec  3 17:28:41 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 3 Dec 2024 17:28:41 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks
In-Reply-To: <O0GHFkQ4760Q0mjdxNIKexoyE45QZBZrqLVNrrheDBw=.5e754dd7-1578-4967-88c2-d3909cc0695d@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
 <O0GHFkQ4760Q0mjdxNIKexoyE45QZBZrqLVNrrheDBw=.5e754dd7-1578-4967-88c2-d3909cc0695d@github.com>
Message-ID: <sFptGtk-Cj6BvLnpa-ErW01XSZhFpAATFx2PC22OzUg=.cc0ce878-be2a-4dd2-933e-c94c86a29e80@github.com>

On Tue, 3 Dec 2024 16:13:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I still don't quite understand if we need to implement `CardTableBarrierSet::on_slowpath_allocation_exit`. I see `SharedRuntime::on_slowpath_allocation_exit` is called from different places in VM. Are those really subsumed by safepoints?

Slow path allocations in GenShen also happen only in young regions, never directly in the old generation, and do not need card-marks. I was hoping to convey that in the comment.

Please let me know if I misunderstood your concern, and am missing a different mechanism through which initializing writes may happen in the old generation.

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

PR Comment: https://git.openjdk.org/jdk/pull/22507#issuecomment-2515165468

From ysr at openjdk.org  Tue Dec  3 21:02:37 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 3 Dec 2024 21:02:37 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks
In-Reply-To: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
Message-ID: <-kdMFM2kLRG0GOt9nD3Y4IR0mGBlVuAxM3vNnRI-R8U=.9a7400c2-94b8-45f4-a0d6-f940f30bc9f5@github.com>

On Tue, 3 Dec 2024 02:41:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Fix documentation comment.
> 
> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.

I chatted w/Aleksey and will take a slightly more conservative and future-proof approach to this. Withdrawing this PR to draft until I have made those changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22507#issuecomment-2515540383

From wkemper at openjdk.org  Tue Dec  3 21:17:24 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 3 Dec 2024 21:17:24 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <6Lk7gCLo6ZKKSqz2IUNGHp7hsXvgj9IhofQU3JZr1Mo=.80af9c39-5031-4c7c-a373-0f496766a2c8@github.com>
References: <6Lk7gCLo6ZKKSqz2IUNGHp7hsXvgj9IhofQU3JZr1Mo=.80af9c39-5031-4c7c-a373-0f496766a2c8@github.com>
Message-ID: <bI0yQNeB6ZSKCU5K_I5obJciqPfVq4WrYKSe9VBjWJo=.8e3bdd8e-aa8c-41d9-8358-e8cbb0202288@github.com>

> Merges tag jdk-21.0.6+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/139/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/139/files/50aa07ef..50aa07ef

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

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

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

From wkemper at openjdk.org  Tue Dec  3 21:17:25 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 3 Dec 2024 21:17:25 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <6Lk7gCLo6ZKKSqz2IUNGHp7hsXvgj9IhofQU3JZr1Mo=.80af9c39-5031-4c7c-a373-0f496766a2c8@github.com>
References: <6Lk7gCLo6ZKKSqz2IUNGHp7hsXvgj9IhofQU3JZr1Mo=.80af9c39-5031-4c7c-a373-0f496766a2c8@github.com>
Message-ID: <hWOfRDmpJahpAEhJpRSTKfylL9NK5BRdSyZLqzRb-4k=.84252f0a-7f95-4c99-927c-924a6ebbdbe7@github.com>

On Thu, 28 Nov 2024 14:20:30 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.6+5

This pull request has now been integrated.

Changeset: 83c356b1
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/83c356b1afe37031e73fa38e70baded002076a02
Stats:     1856 lines in 43 files changed: 664 ins; 170 del; 1022 mod

Merge

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

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

From wkemper at openjdk.org  Tue Dec  3 21:17:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 3 Dec 2024 21:17:36 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <LvcuPfQE_I5zLPyT4VqQnEoERmDcgWfb_z4EXbMRZgQ=.22e893b1-b8fb-43ee-b68f-0e9dfd7a6b19@github.com>
References: <LvcuPfQE_I5zLPyT4VqQnEoERmDcgWfb_z4EXbMRZgQ=.22e893b1-b8fb-43ee-b68f-0e9dfd7a6b19@github.com>
Message-ID: <zwkkTRP9bg1DE9TfmmebsAILRBExNpDlkJ-0o6bKtBA=.326ae2d7-bb07-4b2a-a89b-59f598ea09ac@github.com>

> Merges tag jdk-24+26

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/pull/554/files
  - new: https://git.openjdk.org/shenandoah/pull/554/files/8485cb1c..8485cb1c

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

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

PR: https://git.openjdk.org/shenandoah/pull/554

From wkemper at openjdk.org  Tue Dec  3 21:17:38 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 3 Dec 2024 21:17:38 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <LvcuPfQE_I5zLPyT4VqQnEoERmDcgWfb_z4EXbMRZgQ=.22e893b1-b8fb-43ee-b68f-0e9dfd7a6b19@github.com>
References: <LvcuPfQE_I5zLPyT4VqQnEoERmDcgWfb_z4EXbMRZgQ=.22e893b1-b8fb-43ee-b68f-0e9dfd7a6b19@github.com>
Message-ID: <2WL35Wa1voj1M9buGXux9TlVNxB5OHb5i3_1iZoCC-A=.9f0ae866-e56e-429b-b216-14f3abea951a@github.com>

On Fri, 29 Nov 2024 14:13:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+26

This pull request has now been integrated.

Changeset: d5668df7
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/d5668df7a20a6fbc0eef8b6f8a33dccdb97566ea
Stats:     43761 lines in 856 files changed: 22578 ins; 17018 del; 4165 mod

Merge

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

PR: https://git.openjdk.org/shenandoah/pull/554

From wkemper at openjdk.org  Tue Dec  3 22:24:17 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 3 Dec 2024 22:24:17 GMT
Subject: RFR: 8342444: Shenandoah: Uncommit regions from a separate,
 STS aware thread [v10]
In-Reply-To: <tmBUHpyr0Pozu_mzKD1HROlb1dV2vgPKW9Kb4tJEZ7s=.5a8bd9b3-76ba-4781-b9f7-31243ab24e81@github.com>
References: <tmBUHpyr0Pozu_mzKD1HROlb1dV2vgPKW9Kb4tJEZ7s=.5a8bd9b3-76ba-4781-b9f7-31243ab24e81@github.com>
Message-ID: <Yd7Rx71imniVm7UEbnSBrZg1RjsmCb4siSuf6_6DbGo=.2c8e7375-ce46-4328-ae53-7776a23ed136@github.com>

> Currently, Shenandoah uncommits regions from its control thread. The control thread is responsible for starting GC cycles in a timely fashion. Uncommitting memory from this thread may introduce unwanted delays in the control thread's response to GC pressure.

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

 - Merge jdk/master
 - Use count of regions uncommitted to compute uncommit delta
 - Decouple polling interval from uncommit time out
 - Log uncommitted delta and capacity
 - Merge remote-tracking branch 'jdk/master' into shen-uncommit-thread
 - Restore logging format, show change in committed heap, rather than usage
 - Allow commits initially
 - Use idiomatic name for CADR class
 - Improve comments
 - Do not notify uncommit thread when uncommit is forbidden
 - ... and 11 more: https://git.openjdk.org/jdk/compare/05ee562a...e70d874e

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

Changes: https://git.openjdk.org/jdk/pull/22019/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22019&range=09
  Stats: 514 lines in 9 files changed: 387 ins; 94 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/22019.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22019/head:pull/22019

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

From coleenp at openjdk.org  Tue Dec  3 23:15:43 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 3 Dec 2024 23:15:43 GMT
Subject: RFR: 8328944: NMT reports "unknown" memory [v4]
In-Reply-To: <WE3g3ujzzV9COo98K9kSBuhjku1qQBsh7Lp3ajsZsDg=.53795dab-550d-47b2-96b1-55cdfe82d111@github.com>
References: <q410XZ4jLQtnc1oedcMow7N8Dhhb9nw1dJYggeY2f6U=.00b23ac6-e99c-4784-ab1e-150f04eb7cc8@github.com>
 <WE3g3ujzzV9COo98K9kSBuhjku1qQBsh7Lp3ajsZsDg=.53795dab-550d-47b2-96b1-55cdfe82d111@github.com>
Message-ID: <pspug4-ZX9r4bMNHpXLFsTFZMR4ru4_zjkNhExkP6Kw=.7b4de66f-08d1-433a-99fe-314cea816446@github.com>

On Thu, 21 Nov 2024 21:09:33 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> We use `mtNone` value in several functions default parameters, which may show up in NMT reports.
>> 
>> We address this, by avoiding using `mtNone`.
>> 
>> This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that.
>> 
>> Testing: passes MARCH5 tier1-5
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stefan's feedback

Yes, this is much better to require the mt parameter to be passed down rather than fixing it up after the memory reservation, and having some code miss doing it.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21843#pullrequestreview-2476944377

From wkemper at openjdk.org  Wed Dec  4 01:11:00 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Dec 2024 01:11:00 GMT
Subject: RFR: 8344050: Shenandoah: Retire GC LABs concurrently [v2]
In-Reply-To: <on_-E8AEbHEsRdG8qIP-PVvhY1lTI82opr2v40guElU=.a08f6178-58e1-423f-b2ff-69b9a455f45b@github.com>
References: <M8PzzuQu4nydYYd1B4YMFF8YjKeRuOewMEyXjhtx-I0=.77de1863-2c80-471b-965d-74e30c3aadc8@github.com>
 <on_-E8AEbHEsRdG8qIP-PVvhY1lTI82opr2v40guElU=.a08f6178-58e1-423f-b2ff-69b9a455f45b@github.com>
Message-ID: <beFQarsOD4TUhjQmJQuVaT-mw2IMuZyxj8KbJGg8XJ4=.f1ab810a-a28e-4d7a-96f5-c571dabbee0f@github.com>

On Wed, 13 Nov 2024 19:10:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Test results show a consistent reduction in the time stopped at `init-update-refs` (as expected). Other metrics and benchmark scores are not significantly affected. This change itself does not completely eliminate the safepoint.
>> 
>> Results comparing `-XX:ShenandoahGCMode=satb` to `shenandoah/master` on `aarch64` (results for generational mode and other platforms are similar):
>> 
>> -51.91% sunflow/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.020ms (+/-  0.00ms)         70
>>   Test:         0.013ms (+/-  0.00ms)         20
>> 
>> -50.70% luindex/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.019ms (+/-  0.00ms)         70
>>   Test:         0.013ms (+/-  0.00ms)         20
>> 
>> -50.50% avrora/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.017ms (+/-  0.00ms)        144
>>   Test:         0.012ms (+/-  0.00ms)         42
>> 
>> -49.79% fop/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.022ms (+/-  0.00ms)        572
>>   Test:         0.015ms (+/-  0.00ms)        164
>> 
>> -47.99% batik/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.024ms (+/-  0.01ms)        420
>>   Test:         0.016ms (+/-  0.00ms)        120
>> 
>> -42.54% graphchi/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.020ms (+/-  0.00ms)         70
>>   Test:         0.014ms (+/-  0.00ms)         20
>> 
>> -42.36% xalan/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.017ms (+/-  0.00ms)        213
>>   Test:         0.012ms (+/-  0.00ms)         60
>> 
>> -23.63% scimark.lu.large/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.045ms (+/-  0.00ms)         54
>>   Test:         0.037ms (+/-  0.00ms)         12
>> 
>> -20.66% serial/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.041ms (+/-  0.00ms)        140
>>   Test:         0.034ms (+/-  0.00ms)         40
>> 
>> -20.31% crypto.aes/shenandoahinitupdaterefs_stopped p=0.00000
>>   Control:      0.041ms (+/-  0.00ms)         69
>>   Test:         0.034ms (+/-  0.01ms)         20
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix builds

Rebased and moving this PR to `openjdk/jdk:master`.

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

PR Comment: https://git.openjdk.org/shenandoah/pull/535#issuecomment-2515916628

From wkemper at openjdk.org  Wed Dec  4 01:11:00 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Dec 2024 01:11:00 GMT
Subject: Withdrawn: 8344050: Shenandoah: Retire GC LABs concurrently
In-Reply-To: <M8PzzuQu4nydYYd1B4YMFF8YjKeRuOewMEyXjhtx-I0=.77de1863-2c80-471b-965d-74e30c3aadc8@github.com>
References: <M8PzzuQu4nydYYd1B4YMFF8YjKeRuOewMEyXjhtx-I0=.77de1863-2c80-471b-965d-74e30c3aadc8@github.com>
Message-ID: <3kwiJNz33dsQgAun0SrCUzACJcZj2veB6uIPwBoOz3A=.f7d664b8-a99e-44fa-a9a4-f27dbe2fcf91@github.com>

On Tue, 12 Nov 2024 18:07:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Test results show a consistent reduction in the time stopped at `init-update-refs` (as expected). Other metrics and benchmark scores are not significantly affected. This change itself does not completely eliminate the safepoint.
> 
> Results comparing `-XX:ShenandoahGCMode=satb` to `shenandoah/master` on `aarch64` (results for generational mode and other platforms are similar):
> 
> -51.91% sunflow/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.020ms (+/-  0.00ms)         70
>   Test:         0.013ms (+/-  0.00ms)         20
> 
> -50.70% luindex/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.019ms (+/-  0.00ms)         70
>   Test:         0.013ms (+/-  0.00ms)         20
> 
> -50.50% avrora/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.017ms (+/-  0.00ms)        144
>   Test:         0.012ms (+/-  0.00ms)         42
> 
> -49.79% fop/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.022ms (+/-  0.00ms)        572
>   Test:         0.015ms (+/-  0.00ms)        164
> 
> -47.99% batik/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.024ms (+/-  0.01ms)        420
>   Test:         0.016ms (+/-  0.00ms)        120
> 
> -42.54% graphchi/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.020ms (+/-  0.00ms)         70
>   Test:         0.014ms (+/-  0.00ms)         20
> 
> -42.36% xalan/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.017ms (+/-  0.00ms)        213
>   Test:         0.012ms (+/-  0.00ms)         60
> 
> -23.63% scimark.lu.large/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.045ms (+/-  0.00ms)         54
>   Test:         0.037ms (+/-  0.00ms)         12
> 
> -20.66% serial/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.041ms (+/-  0.00ms)        140
>   Test:         0.034ms (+/-  0.00ms)         40
> 
> -20.31% crypto.aes/shenandoahinitupdaterefs_stopped p=0.00000
>   Control:      0.041ms (+/-  0.00ms)         69
>   Test:         0.034ms (+/-  0.01ms)         20

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah/pull/535

From ysr at openjdk.org  Wed Dec  4 01:29:24 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 4 Dec 2024 01:29:24 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks [v2]
In-Reply-To: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
Message-ID: <kglmZ_q-4e68bc_zmP8w-t-sVTQKVUw1sa4U4KuX-mI=.e33d28f4-970d-4dbb-a5bc-33d9b13c860c@github.com>

> Fix documentation comment, and add an assertion check upon slowpath allocation.
> 
> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.

Y. Srinivas Ramakrishna has updated the pull request incrementally with three additional commits since the last revision:

 - virtual -> override missed in previous delta.
   Fix zero build (ReduceInitialCardMarks is defined only in
   JVMCI/Compiler2)
 - virtual -> override in derived class ShenandoahBarrierSet.
 - Refine previous change and future-proof ReduceInitialCardMarks for
   GenShen.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22507/files
  - new: https://git.openjdk.org/jdk/pull/22507/files/3bcd441f..23b8103d

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

  Stats: 19 lines in 3 files changed: 13 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22507/head:pull/22507

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

From ysr at openjdk.org  Wed Dec  4 01:35:41 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 4 Dec 2024 01:35:41 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks
In-Reply-To: <-kdMFM2kLRG0GOt9nD3Y4IR0mGBlVuAxM3vNnRI-R8U=.9a7400c2-94b8-45f4-a0d6-f940f30bc9f5@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
 <-kdMFM2kLRG0GOt9nD3Y4IR0mGBlVuAxM3vNnRI-R8U=.9a7400c2-94b8-45f4-a0d6-f940f30bc9f5@github.com>
Message-ID: <TJXOvR68iWNMtEQijK9maId9rp0g_0fnu0wx4s2eCkc=.ed2e98f0-c92b-4f24-9c7a-a0a782c254a6@github.com>

On Tue, 3 Dec 2024 20:59:56 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> I chatted w/Aleksey and will take a slightly more conservative and future-proof approach to this. Withdrawing this PR to draft until I have made those changes.

Made a few changes; testing is in progress but PR is open again for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/22507#issuecomment-2515969743

From cslucas at openjdk.org  Wed Dec  4 02:07:37 2024
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Wed, 4 Dec 2024 02:07:37 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks [v2]
In-Reply-To: <kglmZ_q-4e68bc_zmP8w-t-sVTQKVUw1sa4U4KuX-mI=.e33d28f4-970d-4dbb-a5bc-33d9b13c860c@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
 <kglmZ_q-4e68bc_zmP8w-t-sVTQKVUw1sa4U4KuX-mI=.e33d28f4-970d-4dbb-a5bc-33d9b13c860c@github.com>
Message-ID: <j5Crcs3qSfi2X5qO314BHcjThyFbtMWzfNqc3XaPm0U=.2390036d-3eb1-41a4-b107-b01a0d8cd8b0@github.com>

On Wed, 4 Dec 2024 01:29:24 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Fix documentation comment, and add an assertion check upon slowpath allocation.
>> 
>> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - virtual -> override missed in previous delta.
>    Fix zero build (ReduceInitialCardMarks is defined only in
>    JVMCI/Compiler2)
>  - virtual -> override in derived class ShenandoahBarrierSet.
>  - Refine previous change and future-proof ReduceInitialCardMarks for
>    GenShen.

LGTM

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

Marked as reviewed by cslucas (Author).

PR Review: https://git.openjdk.org/jdk/pull/22507#pullrequestreview-2477104700

From shade at openjdk.org  Wed Dec  4 09:51:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Dec 2024 09:51:40 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks [v2]
In-Reply-To: <kglmZ_q-4e68bc_zmP8w-t-sVTQKVUw1sa4U4KuX-mI=.e33d28f4-970d-4dbb-a5bc-33d9b13c860c@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
 <kglmZ_q-4e68bc_zmP8w-t-sVTQKVUw1sa4U4KuX-mI=.e33d28f4-970d-4dbb-a5bc-33d9b13c860c@github.com>
Message-ID: <_aZAH2XY5f1s57YkntosDO02T6OIyfk1CsK1BGbvRns=.887cb130-66c5-42ea-a631-b71136dff7f2@github.com>

On Wed, 4 Dec 2024 01:29:24 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Fix documentation comment, and add an assertion check upon slowpath allocation.
>> 
>> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - virtual -> override missed in previous delta.
>    Fix zero build (ReduceInitialCardMarks is defined only in
>    JVMCI/Compiler2)
>  - virtual -> override in derived class ShenandoahBarrierSet.
>  - Refine previous change and future-proof ReduceInitialCardMarks for
>    GenShen.

Yes, good. Let's see if we catch any failure with this assert.

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp line 93:

> 91: void ShenandoahBarrierSet::on_slowpath_allocation_exit(JavaThread* thread, oop new_obj) {
> 92: #if COMPILER2_OR_JVMCI
> 93:   assert(!(ReduceInitialCardMarks && ShenandoahCardBarrier) || ShenandoahGenerationalHeap::heap()->is_in_young(new_obj),

Not sure why first two are grouped, looks more understandable if written like this? Your call.

Suggestion:

  assert(!ReduceInitialCardMarks || !ShenandoahCardBarrier || ShenandoahGenerationalHeap::heap()->is_in_young(new_obj),

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22507#pullrequestreview-2477889118
PR Review Comment: https://git.openjdk.org/jdk/pull/22507#discussion_r1869089707

From shade at openjdk.org  Wed Dec  4 11:17:43 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 4 Dec 2024 11:17:43 GMT
Subject: RFR: 8342444: Shenandoah: Uncommit regions from a separate,
 STS aware thread [v10]
In-Reply-To: <Yd7Rx71imniVm7UEbnSBrZg1RjsmCb4siSuf6_6DbGo=.2c8e7375-ce46-4328-ae53-7776a23ed136@github.com>
References: <tmBUHpyr0Pozu_mzKD1HROlb1dV2vgPKW9Kb4tJEZ7s=.5a8bd9b3-76ba-4781-b9f7-31243ab24e81@github.com>
 <Yd7Rx71imniVm7UEbnSBrZg1RjsmCb4siSuf6_6DbGo=.2c8e7375-ce46-4328-ae53-7776a23ed136@github.com>
Message-ID: <1XixmNqCS5lLRkkel0t8O9bDHJ7itL2zOy968aNNFsk=.742dca37-11b2-4338-8686-fabbc4ffc5c2@github.com>

On Tue, 3 Dec 2024 22:24:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Currently, Shenandoah uncommits regions from its control thread. The control thread is responsible for starting GC cycles in a timely fashion. Uncommitting memory from this thread may introduce unwanted delays in the control thread's response to GC pressure.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge jdk/master
>  - Use count of regions uncommitted to compute uncommit delta
>  - Decouple polling interval from uncommit time out
>  - Log uncommitted delta and capacity
>  - Merge remote-tracking branch 'jdk/master' into shen-uncommit-thread
>  - Restore logging format, show change in committed heap, rather than usage
>  - Allow commits initially
>  - Use idiomatic name for CADR class
>  - Improve comments
>  - Do not notify uncommit thread when uncommit is forbidden
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/05ee562a...e70d874e

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22019#pullrequestreview-2478196184

From xpeng at openjdk.org  Wed Dec  4 16:04:06 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 4 Dec 2024 16:04:06 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup
Message-ID: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>

Parallelize concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 

With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:

TIP:

[30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
[30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
[30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
[30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
[30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
[30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
[30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
[30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
[30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms

Parallelized:

[30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
[30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
[30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
[30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
[30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
[30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
[30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
[30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
[30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
[30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms


JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`


### Additional test
- [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah

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

Commit messages:
 - Remove _trash_regions
 - Completely remove heap lock from recycling trashed regions
 - Void reordering
 - Rename recycling to _recycling
 - Remove comments
 - Parallelize concurrent cleanup and make recycling trashed regions mostly lock-free

Changes: https://git.openjdk.org/jdk/pull/22538/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22538&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345423
  Stats: 211 lines in 13 files changed: 83 ins; 55 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/22538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22538/head:pull/22538

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

From ysr at openjdk.org  Wed Dec  4 17:54:44 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 4 Dec 2024 17:54:44 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks [v2]
In-Reply-To: <_aZAH2XY5f1s57YkntosDO02T6OIyfk1CsK1BGbvRns=.887cb130-66c5-42ea-a631-b71136dff7f2@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
 <kglmZ_q-4e68bc_zmP8w-t-sVTQKVUw1sa4U4KuX-mI=.e33d28f4-970d-4dbb-a5bc-33d9b13c860c@github.com>
 <_aZAH2XY5f1s57YkntosDO02T6OIyfk1CsK1BGbvRns=.887cb130-66c5-42ea-a631-b71136dff7f2@github.com>
Message-ID: <mJION6do3p3M2h4V2mTacC5cJbbDvv6y2jYgD5zN7VY=.4ef3ff75-d298-4de1-b745-7fa1b2c1066f@github.com>

On Wed, 4 Dec 2024 09:48:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Y. Srinivas Ramakrishna has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - virtual -> override missed in previous delta.
>>    Fix zero build (ReduceInitialCardMarks is defined only in
>>    JVMCI/Compiler2)
>>  - virtual -> override in derived class ShenandoahBarrierSet.
>>  - Refine previous change and future-proof ReduceInitialCardMarks for
>>    GenShen.
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.cpp line 93:
> 
>> 91: void ShenandoahBarrierSet::on_slowpath_allocation_exit(JavaThread* thread, oop new_obj) {
>> 92: #if COMPILER2_OR_JVMCI
>> 93:   assert(!(ReduceInitialCardMarks && ShenandoahCardBarrier) || ShenandoahGenerationalHeap::heap()->is_in_young(new_obj),
> 
> Not sure why first two are grouped, looks more understandable if written like this? Your call.
> 
> Suggestion:
> 
>   assert(!ReduceInitialCardMarks || !ShenandoahCardBarrier || ShenandoahGenerationalHeap::heap()->is_in_young(new_obj),

The deMorganization of the first disjunct does make it easier to read as you state. My reason to write it in its first form was because I tend to think of `(not A) or B` as `A implies B` (and written in the first form because C lacks an `implies` operator). I'll rewrite as you suggest before I push this.

Thanks for the review!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22507#discussion_r1870023768

From xpeng at openjdk.org  Wed Dec  4 19:06:55 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 4 Dec 2024 19:06:55 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v2]
In-Reply-To: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
Message-ID: <0yobXRSIWciKg1EbfQWBMX5Fhl5P7BI5TWm58IZGB_4=.34ab465c-3d30-4eed-be39-8f81c9aa226a@github.com>

> Parallelize concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
> 
> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
> 
> TIP:
> 
> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
> 
> Parallelized:
> 
> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
> 
> 
> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
> 
> 
> ### Additional test
> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah

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

 - Merge branch 'openjdk:master' into parallel-cleanup
 - Remove _trash_regions
 - Completely remove heap lock from recycling trashed regions
 - Void reordering
 - Rename recycling to _recycling
 - Remove comments
 - Parallelize concurrent cleanup and make recycling trashed regions mostly lock-free

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22538/files
  - new: https://git.openjdk.org/jdk/pull/22538/files/f3b8dff4..7f7b370a

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

  Stats: 10324 lines in 396 files changed: 5350 ins; 3376 del; 1598 mod
  Patch: https://git.openjdk.org/jdk/pull/22538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22538/head:pull/22538

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

From wkemper at openjdk.org  Wed Dec  4 19:06:58 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Dec 2024 19:06:58 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v2]
In-Reply-To: <0yobXRSIWciKg1EbfQWBMX5Fhl5P7BI5TWm58IZGB_4=.34ab465c-3d30-4eed-be39-8f81c9aa226a@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0yobXRSIWciKg1EbfQWBMX5Fhl5P7BI5TWm58IZGB_4=.34ab465c-3d30-4eed-be39-8f81c9aa226a@github.com>
Message-ID: <qANtNtY7oY9B-ZJZbd-LoJVL71U123nscKO5Bz6yAAg=.3272d84b-8e9d-409d-bed0-8224a413c50c@github.com>

On Wed, 4 Dec 2024 19:02:21 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Parallelize concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> ### Additional test
>> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah
>
> Xiaolong Peng has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into parallel-cleanup
>  - Remove _trash_regions
>  - Completely remove heap lock from recycling trashed regions
>  - Void reordering
>  - Rename recycling to _recycling
>  - Remove comments
>  - Parallelize concurrent cleanup and make recycling trashed regions mostly lock-free

Changes look good. Left some nits.

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

> 1047: 
> 1048: void ShenandoahConcurrentGC::op_cleanup_early() {
> 1049:   ShenandoahWorkerScope scope(ShenandoahHeap::heap()->workers(),

Can we align these arguments with the first argument after the `(`?

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

> 1260: public:
> 1261:   ShenandoahRecycleTrashedRegionTask() :
> 1262:     WorkerTask("Shenandoah Recycle trashed region.") {}

Should be "Shenandoah Recycle Trashed Regions" (no period, title case).

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

> 1263: 
> 1264:   void work(uint worker_id) {
> 1265:     const ShenandoahHeap* heap = ShenandoahHeap::heap();

`heap` looks unused here.

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 890:

> 888: size_t ShenandoahGeneration::decrement_affiliated_region_count() {
> 889:   // Assertions only hold true for Java threads since they call this method under heap lock.
> 890:   bool const is_java_thread = Thread::current()->is_Java_thread();

Prefer not to check `Thread::current` to gate assertions. Could we use an `#ifdef ASSERT` block here? Could this be `decrease_affiliated_region_count(1)` instead? or should we have a separate `decrement_under_lock` method?

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 592:

> 590:   shenandoah_assert_heaplocked();
> 591:   if (is_trash() && _recycling.try_set()) {
> 592:     if (is_trash()) {

Is it necessary to check `is_trash` a second time while the heap lock is held? Also, if it _is_ necessary, then it seems like we should `_recycling.unset` in the scope where `_recycling.try_set` happened. As it is, if the second check for `is_trash` was `false`, then the code would not `_recycling.unset`.

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

Changes requested by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22538#pullrequestreview-2479579023
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1870112931
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1870083766
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1870085143
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1870092090
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1870100238

From wkemper at openjdk.org  Wed Dec  4 20:52:55 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Dec 2024 20:52:55 GMT
Subject: RFR: 8342444: Shenandoah: Uncommit regions from a separate,
 STS aware thread [v11]
In-Reply-To: <tmBUHpyr0Pozu_mzKD1HROlb1dV2vgPKW9Kb4tJEZ7s=.5a8bd9b3-76ba-4781-b9f7-31243ab24e81@github.com>
References: <tmBUHpyr0Pozu_mzKD1HROlb1dV2vgPKW9Kb4tJEZ7s=.5a8bd9b3-76ba-4781-b9f7-31243ab24e81@github.com>
Message-ID: <YSijEqQu0bRurYvw-2CKimiCkU7ntFXrwMktd2-ujKA=.b84b2795-2036-4a22-8766-24a42cd621db@github.com>

> Currently, Shenandoah uncommits regions from its control thread. The control thread is responsible for starting GC cycles in a timely fashion. Uncommitting memory from this thread may introduce unwanted delays in the control thread's response to GC pressure.

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

 - Merge remote-tracking branch 'jdk/master' into shen-uncommit-thread
 - Merge jdk/master
 - Use count of regions uncommitted to compute uncommit delta
 - Decouple polling interval from uncommit time out
 - Log uncommitted delta and capacity
 - Merge remote-tracking branch 'jdk/master' into shen-uncommit-thread
 - Restore logging format, show change in committed heap, rather than usage
 - Allow commits initially
 - Use idiomatic name for CADR class
 - Improve comments
 - ... and 12 more: https://git.openjdk.org/jdk/compare/1a73c76d...c39be0f9

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

Changes: https://git.openjdk.org/jdk/pull/22019/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22019&range=10
  Stats: 514 lines in 9 files changed: 387 ins; 94 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/22019.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22019/head:pull/22019

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

From wkemper at openjdk.org  Wed Dec  4 20:52:56 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 4 Dec 2024 20:52:56 GMT
Subject: RFR: 8342444: Shenandoah: Uncommit regions from a separate,
 STS aware thread [v8]
In-Reply-To: <yIvCmwS_txWMPRAVB65hXCB10-Okzv169gL-3hb_jZ4=.ef28efb3-c29e-481b-8404-26629dd53de5@github.com>
References: <tmBUHpyr0Pozu_mzKD1HROlb1dV2vgPKW9Kb4tJEZ7s=.5a8bd9b3-76ba-4781-b9f7-31243ab24e81@github.com>
 <HripUUPUYfiN85INiVDn05zpI3FJiNjX6kEFXjp3Ucs=.c71a1a08-9b42-41a1-bb6b-09151eac3b62@github.com>
 <WD1RwtNlh4ftiRfkFnjanV227bvT1xZviGCZ1mw0rw0=.37015485-10e7-4202-8a41-1d3de4ec30bb@github.com>
 <yIvCmwS_txWMPRAVB65hXCB10-Okzv169gL-3hb_jZ4=.ef28efb3-c29e-481b-8404-26629dd53de5@github.com>
Message-ID: <WExxjIta7Uv1rr9IbvMsr1ZGQw-NNaGNrg8pY_tDaUs=.1401dec9-e292-42e9-82f5-8023d18393fa@github.com>

On Tue, 26 Nov 2024 10:16:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahUncommitThread.cpp line 75:
>> 
>>> 73:       MonitorLocker locker(&_stop_lock, Mutex::_no_safepoint_check_flag);
>>> 74:       if (!_stop_requested.is_set()) {
>>> 75:         locker.wait((int64_t)shrink_period);
>> 
>> I tried to test this on some of my toy examples, and realized this particular line may end up as `locker.wait(0)`, which means "wait indefinitely, until notified". This breaks periodic commits. The old code rode on control thread doing `MAX2(1, ...)`, so we never feed `0` into `wait`. I am also confused about units. The comment above says `shrink_period` is in seconds, but `locker.wait` accepts milliseconds?
>
> It sounds like this line should be:
> 
> 
>         locker.wait(MAX2<int64_t>(1, shrink_period * 1000));

Sorry, I missed your comments here. I noticed the same and have refactored this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22019#discussion_r1870257677

From xpeng at openjdk.org  Wed Dec  4 21:26:38 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 4 Dec 2024 21:26:38 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v2]
In-Reply-To: <qANtNtY7oY9B-ZJZbd-LoJVL71U123nscKO5Bz6yAAg=.3272d84b-8e9d-409d-bed0-8224a413c50c@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0yobXRSIWciKg1EbfQWBMX5Fhl5P7BI5TWm58IZGB_4=.34ab465c-3d30-4eed-be39-8f81c9aa226a@github.com>
 <qANtNtY7oY9B-ZJZbd-LoJVL71U123nscKO5Bz6yAAg=.3272d84b-8e9d-409d-bed0-8224a413c50c@github.com>
Message-ID: <q20vfgZaMj4XEEb5gdUKLRxiKibpNY2I9LJ-1jEB420=.fe029c2e-c15c-4648-8fd0-f432a7c30711@github.com>

On Wed, 4 Dec 2024 18:54:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Changes look good. Left some nits.

Thanks for looking into it, I'll fix them and update the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/22538#issuecomment-2518591374

From xpeng at openjdk.org  Wed Dec  4 21:41:02 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 4 Dec 2024 21:41:02 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v3]
In-Reply-To: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
Message-ID: <PTQCegW5wEIB2sUBUozsyYKt2ECrgLuNJfruYidyE1U=.36caa87d-6268-4304-8b1c-f02c968eee2b@github.com>

> Parallelize concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
> 
> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
> 
> TIP:
> 
> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
> 
> Parallelized:
> 
> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
> 
> 
> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
> 
> 
> ### Additional test
> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22538/files
  - new: https://git.openjdk.org/jdk/pull/22538/files/7f7b370a..50e633f2

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

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

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

From xpeng at openjdk.org  Wed Dec  4 21:43:52 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 4 Dec 2024 21:43:52 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v4]
In-Reply-To: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
Message-ID: <0zXiV5vIfQnOWKstBgeUMlbjqem_BoQyzqt3laUw030=.665d49f2-019c-4f98-b276-8aafe1494513@github.com>

> Parallelize concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
> 
> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
> 
> TIP:
> 
> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
> 
> Parallelized:
> 
> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
> 
> 
> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
> 
> 
> ### Additional test
> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Fix naming issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22538/files
  - new: https://git.openjdk.org/jdk/pull/22538/files/50e633f2..404f7f98

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

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

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

From xpeng at openjdk.org  Wed Dec  4 21:53:40 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 4 Dec 2024 21:53:40 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v4]
In-Reply-To: <qANtNtY7oY9B-ZJZbd-LoJVL71U123nscKO5Bz6yAAg=.3272d84b-8e9d-409d-bed0-8224a413c50c@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0yobXRSIWciKg1EbfQWBMX5Fhl5P7BI5TWm58IZGB_4=.34ab465c-3d30-4eed-be39-8f81c9aa226a@github.com>
 <qANtNtY7oY9B-ZJZbd-LoJVL71U123nscKO5Bz6yAAg=.3272d84b-8e9d-409d-bed0-8224a413c50c@github.com>
Message-ID: <OWhfMhO4cAuE9LHsOFpMVgHce5HfXaVhT08HhRbXDzk=.6631fada-f2f6-4753-abbc-6b504a8f1a52@github.com>

On Wed, 4 Dec 2024 18:42:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix naming issue
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 592:
> 
>> 590:   shenandoah_assert_heaplocked();
>> 591:   if (is_trash() && _recycling.try_set()) {
>> 592:     if (is_trash()) {
> 
> Is it necessary to check `is_trash` a second time while the heap lock is held? Also, if it _is_ necessary, then it seems like we should `_recycling.unset` in the scope where `_recycling.try_set` happened. As it is, if the second check for `is_trash` was `false`, then the code would not `_recycling.unset`.

This method is only called by mutators with heap lock, is_trash is not tested before calling the method, it might be worth to test before calling _recycling.try_set(), otherwise mutator will mostly(fast path) behaves like:
1. _recycling.try_set() -> true (always try to perform CAS, it is slower, we want to void it in fast path).
2. is_trash() -> false and skip the recycling. 

But we want to fast path for mutator to be like: `is_trash() -> false && _recycling.is_set() -> false`.


I have remove the `is_trash` from the code path executed by concurrent cleanup in the new version, that one is not needed since `is_trash` is tested in `ShenandoahRecycleTrashedRegionsTask`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1870327496

From xpeng at openjdk.org  Wed Dec  4 22:08:39 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 4 Dec 2024 22:08:39 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v4]
In-Reply-To: <qANtNtY7oY9B-ZJZbd-LoJVL71U123nscKO5Bz6yAAg=.3272d84b-8e9d-409d-bed0-8224a413c50c@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0yobXRSIWciKg1EbfQWBMX5Fhl5P7BI5TWm58IZGB_4=.34ab465c-3d30-4eed-be39-8f81c9aa226a@github.com>
 <qANtNtY7oY9B-ZJZbd-LoJVL71U123nscKO5Bz6yAAg=.3272d84b-8e9d-409d-bed0-8224a413c50c@github.com>
Message-ID: <lJzgd61G8m8XAiK827R1_TqVCma7nQs7f-4DJFyAJ5k=.9357d4a5-acce-44e1-a56b-90f5a8d16c68@github.com>

On Wed, 4 Dec 2024 18:36:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix naming issue
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 890:
> 
>> 888: size_t ShenandoahGeneration::decrement_affiliated_region_count() {
>> 889:   // Assertions only hold true for Java threads since they call this method under heap lock.
>> 890:   bool const is_java_thread = Thread::current()->is_Java_thread();
> 
> Prefer not to check `Thread::current` to gate assertions. Could we use an `#ifdef ASSERT` block here? Could this be `decrease_affiliated_region_count(1)` instead? or should we have a separate `decrement_under_lock` method?

It will be weird if I only change   `decrement_affiliated_region_count` to `decrement_affiliated_region_count_under_lock` in this file, while all the other `decrement_x` / `decrease_x` /`increment_x` / `increase_x` methods in files follow the same convention.

It is probably better to add new one like `decrement_affiliated_region_count_without_lock` and not change the existing methods' behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1870342598

From xpeng at openjdk.org  Wed Dec  4 22:16:53 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 4 Dec 2024 22:16:53 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v5]
In-Reply-To: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
Message-ID: <bP2UQizx5L02W6H6EUIxfy9oBkSvSxiDEDnTvvHV2hw=.2e15cbd2-c53e-4f59-baad-98be509a1988@github.com>

> Parallelize concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
> 
> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
> 
> TIP:
> 
> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
> 
> Parallelized:
> 
> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
> 
> 
> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
> 
> 
> ### Additional test
> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Add decrement_affiliated_region_count_without_lock

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22538/files
  - new: https://git.openjdk.org/jdk/pull/22538/files/404f7f98..75cb902c

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

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

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

From ysr at openjdk.org  Wed Dec  4 23:45:07 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 4 Dec 2024 23:45:07 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks [v3]
In-Reply-To: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
Message-ID: <ZQo1HJfsS9vrHAlMN65OVbg3weTiCIK33CKrJEksak0=.8550a939-de18-428f-9539-b11fa07f74b0@github.com>

> Fix documentation comment, and add an assertion check upon slowpath allocation.
> 
> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.

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

 - Merge branch 'master' into ricm
 - virtual -> override missed in previous delta.
   Fix zero build (ReduceInitialCardMarks is defined only in
   JVMCI/Compiler2)
 - virtual -> override in derived class ShenandoahBarrierSet.
 - Refine previous change and future-proof ReduceInitialCardMarks for
   GenShen.
 - Fix up documentation comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22507/files
  - new: https://git.openjdk.org/jdk/pull/22507/files/23b8103d..76ab8f3b

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

  Stats: 10622 lines in 392 files changed: 5385 ins; 3453 del; 1784 mod
  Patch: https://git.openjdk.org/jdk/pull/22507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22507/head:pull/22507

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

From xpeng at openjdk.org  Thu Dec  5 08:58:52 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 5 Dec 2024 08:58:52 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v6]
In-Reply-To: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
Message-ID: <ngwQZc78cB32SDjbwSm3sAFDjXzzQHJu0A6-HMpY9wU=.1e006a23-98d4-4770-9bf9-13186422c832@github.com>

> Parallelize concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
> 
> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
> 
> TIP:
> 
> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
> 
> Parallelized:
> 
> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
> 
> 
> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
> 
> 
> ### Additional test
> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision:

 - Ensure atomicity when access region state
 - Bug fix and move is_trash test into try_recycle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22538/files
  - new: https://git.openjdk.org/jdk/pull/22538/files/75cb902c..11941c57

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

  Stats: 29 lines in 2 files changed: 6 ins; 4 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/22538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22538/head:pull/22538

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

From wkemper at openjdk.org  Thu Dec  5 14:26:16 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Dec 2024 14:26:16 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <j89-T-gJKR44GGatDmAMYlVUbEyo9_sd2f_ieOmo73Y=.1c1f1488-28b0-4bb9-9d8d-7c5e2cd3ff8e@github.com>

Merges tag jdk-21.0.6+6

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

Commit messages:
 - 8335912: Add an operation mode to the jar command when extracting to not overwriting existing files
 - 8342905: Thread.setContextClassloader from thread in FJP commonPool task no longer works after JDK-8327501 redux
 - 8344993: [21u] [REDO] Backport JDK-8327501 and JDK-8328366 to JDK 21
 - 8322809: SystemModulesMap::classNames and moduleNames arrays do not match the order
 - 8344628: Test TestEnableJVMCIProduct.java run with virtual thread intermittent fails
 - 8343285: java.lang.Process is unresponsive and CPU usage spikes to 100%
 - 8334475: UnsafeIntrinsicsTest.java#ZGenerationalDebug assert(!assert_on_failure) failed: Has low-order bits set
 - 8342409: [s390x] C1 unwind_handler fails to unlock synchronized methods with LM_MONITOR
 - 8345055: [21u] ProblemList failing rtm tests on ppc platforms
 - 8325906: Problemlist vmTestbase/vm/mlvm/meth/stress/compiler/deoptimize/Test.java#id1 until JDK-8320865 is fixed
 - ... and 1 more: https://git.openjdk.org/shenandoah-jdk21u/compare/50aa07ef...e45287d1

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/140/files
  Stats: 956 lines in 22 files changed: 874 ins; 41 del; 41 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/140.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/140/head:pull/140

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

From gziemski at openjdk.org  Thu Dec  5 15:31:45 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 5 Dec 2024 15:31:45 GMT
Subject: Integrated: 8328944: NMT reports "unknown" memory
In-Reply-To: <q410XZ4jLQtnc1oedcMow7N8Dhhb9nw1dJYggeY2f6U=.00b23ac6-e99c-4784-ab1e-150f04eb7cc8@github.com>
References: <q410XZ4jLQtnc1oedcMow7N8Dhhb9nw1dJYggeY2f6U=.00b23ac6-e99c-4784-ab1e-150f04eb7cc8@github.com>
Message-ID: <xR7Sn0gare20a8_S1-ZabW1ZuqzjLfa2saK7GER35b8=.ac31de9f-5c9f-42a7-a4a1-de6151937d45@github.com>

On Fri, 1 Nov 2024 20:44:50 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> We use `mtNone` value in several functions default parameters, which may show up in NMT reports.
> 
> We address this, by avoiding using `mtNone`.
> 
> This fix only addresses the cases covered by the issue. I am not trying to replace every single `mtNone` here, but eventually the goal would be to do just that.
> 
> Testing: passes MARCH5 tier1-5

This pull request has now been integrated.

Changeset: 7513b137
Author:    Gerard Ziemski <gziemski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7513b1378de4fc2270d8e144a9c3b75859e6fe5f
Stats:     72 lines in 15 files changed: 3 ins; 23 del; 46 mod

8328944: NMT reports "unknown" memory

Reviewed-by: jsjolen, coleenp

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

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

From wkemper at openjdk.org  Thu Dec  5 17:58:46 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Dec 2024 17:58:46 GMT
Subject: Integrated: 8342444: Shenandoah: Uncommit regions from a separate,
 STS aware thread
In-Reply-To: <tmBUHpyr0Pozu_mzKD1HROlb1dV2vgPKW9Kb4tJEZ7s=.5a8bd9b3-76ba-4781-b9f7-31243ab24e81@github.com>
References: <tmBUHpyr0Pozu_mzKD1HROlb1dV2vgPKW9Kb4tJEZ7s=.5a8bd9b3-76ba-4781-b9f7-31243ab24e81@github.com>
Message-ID: <kjhwiMOrzJ_7PIjkdSa0aG2a_61bzi_fYS-9qaVDOSk=.87a28603-2cf9-4627-ad08-9f0b059685cc@github.com>

On Mon, 11 Nov 2024 17:31:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Currently, Shenandoah uncommits regions from its control thread. The control thread is responsible for starting GC cycles in a timely fashion. Uncommitting memory from this thread may introduce unwanted delays in the control thread's response to GC pressure.

This pull request has now been integrated.

Changeset: bedb68ab
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bedb68aba126c6400ce9f2182105b5294ff42021
Stats:     514 lines in 9 files changed: 387 ins; 94 del; 33 mod

8342444: Shenandoah: Uncommit regions from a separate, STS aware thread

Reviewed-by: shade, kdnilsen, ysr

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

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

From wkemper at openjdk.org  Thu Dec  5 18:22:46 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Dec 2024 18:22:46 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v6]
In-Reply-To: <OWhfMhO4cAuE9LHsOFpMVgHce5HfXaVhT08HhRbXDzk=.6631fada-f2f6-4753-abbc-6b504a8f1a52@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0yobXRSIWciKg1EbfQWBMX5Fhl5P7BI5TWm58IZGB_4=.34ab465c-3d30-4eed-be39-8f81c9aa226a@github.com>
 <qANtNtY7oY9B-ZJZbd-LoJVL71U123nscKO5Bz6yAAg=.3272d84b-8e9d-409d-bed0-8224a413c50c@github.com>
 <OWhfMhO4cAuE9LHsOFpMVgHce5HfXaVhT08HhRbXDzk=.6631fada-f2f6-4753-abbc-6b504a8f1a52@github.com>
Message-ID: <itpLt4sqm__4Q0V_phQUhOZPq4Odgbf-qPLBY9UOzZk=.7d7a06fe-a2fa-40b2-b5d2-85b4e73fa8d1@github.com>

On Wed, 4 Dec 2024 21:50:26 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 592:
>> 
>>> 590:   shenandoah_assert_heaplocked();
>>> 591:   if (is_trash() && _recycling.try_set()) {
>>> 592:     if (is_trash()) {
>> 
>> Is it necessary to check `is_trash` a second time while the heap lock is held? Also, if it _is_ necessary, then it seems like we should `_recycling.unset` in the scope where `_recycling.try_set` happened. As it is, if the second check for `is_trash` was `false`, then the code would not `_recycling.unset`.
>
> This method is only called by mutators with heap lock, is_trash is not tested before calling the method, it is worth to test before calling _recycling.try_set(), otherwise mutator will mostly(fast path) behaves like:
> 1. _recycling.try_set() -> true (always try to perform CAS, it is slower, we want to void it in fast path).
> 2. is_trash() -> false and skip the recycling. 
> 3. _recycling.unset()  (Should be also avoided in fast path)
> 
> But we want to fast path for mutator to be like: `is_trash() -> false && _recycling.is_set() -> false`.
> 
> 
> I have removed `is_trash` test from the code path executed by concurrent cleanup in the new version, that one is not needed since `is_trash` is tested in `ShenandoahRecycleTrashedRegionsTask`

Okay, I get it. The second test on line 593 is necessary because the gc workers don't hold the lock and could _in theory_ recycle the region between the first `is_trash` check on 592 and the `_recycling.try_set`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1871889122

From wkemper at openjdk.org  Thu Dec  5 18:25:39 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 5 Dec 2024 18:25:39 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v6]
In-Reply-To: <ngwQZc78cB32SDjbwSm3sAFDjXzzQHJu0A6-HMpY9wU=.1e006a23-98d4-4770-9bf9-13186422c832@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <ngwQZc78cB32SDjbwSm3sAFDjXzzQHJu0A6-HMpY9wU=.1e006a23-98d4-4770-9bf9-13186422c832@github.com>
Message-ID: <fDehcsdHQZ6Ict8DFjkl5WHLORq9fgfgKwiIIsiLjLo=.ec9d0fbd-cb7a-43a2-9732-648c05b5e04a@github.com>

On Thu, 5 Dec 2024 08:58:52 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Parallelize concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> ### Additional test
>> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah
>
> Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Ensure atomicity when access region state
>  - Bug fix and move is_trash test into try_recycle

Changes requested by wkemper (Committer).

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 629:

> 627:     _recycling.unset();
> 628:   } else {
> 629:     while (_recycling.is_set()) {

Why are adding this? Won't this make the calling worker thread wait on another worker to recycle the region?

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 385:

> 383:   void print_on(outputStream* st) const;
> 384: 
> 385:   void recycle_under_lock();

Should be `try_recycle_under_lock` for consistency.

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

PR Review: https://git.openjdk.org/jdk/pull/22538#pullrequestreview-2482551965
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1871890730
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1871891590

From xpeng at openjdk.org  Thu Dec  5 18:41:47 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 5 Dec 2024 18:41:47 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v6]
In-Reply-To: <fDehcsdHQZ6Ict8DFjkl5WHLORq9fgfgKwiIIsiLjLo=.ec9d0fbd-cb7a-43a2-9732-648c05b5e04a@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <ngwQZc78cB32SDjbwSm3sAFDjXzzQHJu0A6-HMpY9wU=.1e006a23-98d4-4770-9bf9-13186422c832@github.com>
 <fDehcsdHQZ6Ict8DFjkl5WHLORq9fgfgKwiIIsiLjLo=.ec9d0fbd-cb7a-43a2-9732-648c05b5e04a@github.com>
Message-ID: <MsWN82JvmOpR_mg0ocs5GalrmJ72dKqKrOaUYY7FHWg=.64b776af-b473-4d1f-a3a7-fbe8be29f295@github.com>

On Thu, 5 Dec 2024 18:21:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Ensure atomicity when access region state
>>  - Bug fix and move is_trash test into try_recycle
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 629:
> 
>> 627:     _recycling.unset();
>> 628:   } else {
>> 629:     while (_recycling.is_set()) {
> 
> Why are adding this? Won't this make the calling worker thread wait on another worker to recycle the region?

hmm,  didn't include this intentionally, forgot to remove it from commit, sorry I'll remove it, thanks for catching it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1871911601

From xpeng at openjdk.org  Thu Dec  5 18:47:55 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 5 Dec 2024 18:47:55 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v7]
In-Reply-To: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
Message-ID: <eiSgyO8ITdA8SGHiZUqFIoBOMFZXJJmbPMGW_eBt8wI=.f4ba848c-d554-4147-8a28-f931978020f4@github.com>

> Parallelize concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
> 
> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
> 
> TIP:
> 
> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
> 
> Parallelized:
> 
> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
> 
> 
> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
> 
> 
> ### Additional test
> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Renaming and remove unnecessary code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22538/files
  - new: https://git.openjdk.org/jdk/pull/22538/files/11941c57..368c6aae

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

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

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

From xpeng at openjdk.org  Thu Dec  5 18:50:41 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 5 Dec 2024 18:50:41 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v6]
In-Reply-To: <fDehcsdHQZ6Ict8DFjkl5WHLORq9fgfgKwiIIsiLjLo=.ec9d0fbd-cb7a-43a2-9732-648c05b5e04a@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <ngwQZc78cB32SDjbwSm3sAFDjXzzQHJu0A6-HMpY9wU=.1e006a23-98d4-4770-9bf9-13186422c832@github.com>
 <fDehcsdHQZ6Ict8DFjkl5WHLORq9fgfgKwiIIsiLjLo=.ec9d0fbd-cb7a-43a2-9732-648c05b5e04a@github.com>
Message-ID: <T2qL5hiNQ38GGwsf3MZVxFikUPxvnTG6ImeTNMJqOZU=.fb25d7e3-6bf5-4fed-98d0-e77b01916c83@github.com>

On Thu, 5 Dec 2024 18:22:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Ensure atomicity when access region state
>>  - Bug fix and move is_trash test into try_recycle
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 385:
> 
>> 383:   void print_on(outputStream* st) const;
>> 384: 
>> 385:   void recycle_under_lock();
> 
> Should be `try_recycle_under_lock` for consistency.

Thanks! I have renamed it for consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1871923713

From ysr at openjdk.org  Thu Dec  5 19:50:26 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 5 Dec 2024 19:50:26 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks [v4]
In-Reply-To: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
Message-ID: <mwlYH1wi_OSqWue7ed1UgXfKw6Mk9iylEVCZJ3zGx10=.f335ea44-e99e-4970-a45b-93211b7995d4@github.com>

> Fix documentation comment, and add an assertion check upon slowpath allocation.
> 
> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.

Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:

  Demorganization of clause in assert per review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22507/files
  - new: https://git.openjdk.org/jdk/pull/22507/files/76ab8f3b..040b7e36

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

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

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

From shade at openjdk.org  Thu Dec  5 19:50:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 5 Dec 2024 19:50:26 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks [v4]
In-Reply-To: <mwlYH1wi_OSqWue7ed1UgXfKw6Mk9iylEVCZJ3zGx10=.f335ea44-e99e-4970-a45b-93211b7995d4@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
 <mwlYH1wi_OSqWue7ed1UgXfKw6Mk9iylEVCZJ3zGx10=.f335ea44-e99e-4970-a45b-93211b7995d4@github.com>
Message-ID: <1Oe4Zice-3cTcLULF41aFpWTEYtdSWvtKGPjU5vS-OI=.8ca333b0-e3be-48ae-bae5-3b4e7302b5aa@github.com>

On Thu, 5 Dec 2024 19:47:00 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Fix documentation comment, and add an assertion check upon slowpath allocation.
>> 
>> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.
>
> Y. Srinivas Ramakrishna has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Demorganization of clause in assert per review feedback

Still fine.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22507#pullrequestreview-2482712946

From ysr at openjdk.org  Thu Dec  5 19:50:28 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 5 Dec 2024 19:50:28 GMT
Subject: RFR: 8344593: GenShen: Review of ReduceInitialCardMarks [v3]
In-Reply-To: <ZQo1HJfsS9vrHAlMN65OVbg3weTiCIK33CKrJEksak0=.8550a939-de18-428f-9539-b11fa07f74b0@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
 <ZQo1HJfsS9vrHAlMN65OVbg3weTiCIK33CKrJEksak0=.8550a939-de18-428f-9539-b11fa07f74b0@github.com>
Message-ID: <0UllfVoUy2tqPKQQHI1wozH1uw0X60ziff5--HiONJg=.57e4f59c-0e59-41d4-accc-38532eb215a8@github.com>

On Wed, 4 Dec 2024 23:45:07 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Fix documentation comment, and add an assertion check upon slowpath allocation.
>> 
>> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.
>
> Y. Srinivas Ramakrishna has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into ricm
>  - virtual -> override missed in previous delta.
>    Fix zero build (ReduceInitialCardMarks is defined only in
>    JVMCI/Compiler2)
>  - virtual -> override in derived class ShenandoahBarrierSet.
>  - Refine previous change and future-proof ReduceInitialCardMarks for
>    GenShen.
>  - Fix up documentation comment.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22507#issuecomment-2521256371

From ysr at openjdk.org  Thu Dec  5 19:50:28 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 5 Dec 2024 19:50:28 GMT
Subject: Integrated: 8344593: GenShen: Review of ReduceInitialCardMarks
In-Reply-To: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
References: <-VSOzYldcT3fuR13S0xOXlf9e1bnXaTXl-bvGqcsuFw=.f04f82b7-a195-4906-bb1e-ec005a8f53d8@github.com>
Message-ID: <QfCiilxdZQG0l6CymvXIhrDAFguhWWIEIoIfTFytPC0=.a01acd54-6575-4cbb-bbe3-8af16f1a0107@github.com>

On Tue, 3 Dec 2024 02:41:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Fix documentation comment, and add an assertion check upon slowpath allocation.
> 
> I also checked the impact of +/-ReduceInitialCardMarks on GenShen using SPECjbb and didn't see any difference. We've left it enabled by default because less card marking is better in this case.

This pull request has now been integrated.

Changeset: a97dca52
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a97dca52c9257121fc96613a4b591920c1c3e31a
Stats:     28 lines in 3 files changed: 18 ins; 0 del; 10 mod

8344593: GenShen: Review of ReduceInitialCardMarks

Reviewed-by: shade, cslucas

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

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

From stefank at openjdk.org  Fri Dec  6 10:04:16 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 10:04:16 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
Message-ID: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>

I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.

Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

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

Commit messages:
 - 8345656: Move os alignment functions out of ReservedSpace

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

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

From azafari at openjdk.org  Fri Dec  6 13:20:37 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 6 Dec 2024 13:20:37 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
In-Reply-To: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
Message-ID: <K6PpmxV6vsLOp2_oO04hptICBFWBdKPFzRrObBxDjAE=.e187d8a7-2221-4514-a243-c84fd8f4583b@github.com>

On Fri, 6 Dec 2024 09:58:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
> 
> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

Thanks for cleaning up the Reserved Space stuff. I found that Copyright years are not up-to-date for these files:

gc/g1/g1CardTable.cpp
gc/g1/g1CardTable.hpp
gc/shared/markBitMap.cpp
gc/shenandoah/shenandoahMarkBitMap.cpp

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

PR Review: https://git.openjdk.org/jdk/pull/22600#pullrequestreview-2484821614

From wkemper at openjdk.org  Fri Dec  6 14:18:51 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 6 Dec 2024 14:18:51 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <uVnN2YHWAZGvVHCBfiV74YhprHHSFgs-I9VP6Hbmb9E=.eb4a2751-08b5-4dfe-b488-2c455997af03@github.com>

Merges tag jdk-24+27

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

Commit messages:
 - 8344607: Link Time Optimization - basic support for clang
 - 8345302: Building microbenchmarks require larger Java heap
 - 8345514: Should use internal class name when calling ClassLoader.getResourceAsByteArray
 - 8345591: [aarch64] macroAssembler_aarch64.cpp compile fails ceil_log2 not declared
 - 8328944: NMT reports "unknown" memory
 - 8345565: Remove remaining SecurityManager motivated APIs from sun.reflect.util
 - 8345339: JFR: Missing javadoc for RecordingStream::onMetadata
 - 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
 - 8345578: New test in JDK-8343622 fails with a promoted build
 - 8344831: [REDO] CDS: Parallel relocation
 - ... and 161 more: https://git.openjdk.org/shenandoah/compare/8485cb1c...85fedbf6

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

Changes: https://git.openjdk.org/shenandoah/pull/555/files
  Stats: 78810 lines in 1157 files changed: 62839 ins; 10951 del; 5020 mod
  Patch: https://git.openjdk.org/shenandoah/pull/555.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/555/head:pull/555

PR: https://git.openjdk.org/shenandoah/pull/555

From stefank at openjdk.org  Fri Dec  6 14:54:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 14:54:13 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
Message-ID: <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>

> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
> 
> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22600/files
  - new: https://git.openjdk.org/jdk/pull/22600/files/326f32f7..2da8bade

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

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

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

From stefank at openjdk.org  Fri Dec  6 14:54:13 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 6 Dec 2024 14:54:13 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <K6PpmxV6vsLOp2_oO04hptICBFWBdKPFzRrObBxDjAE=.e187d8a7-2221-4514-a243-c84fd8f4583b@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <K6PpmxV6vsLOp2_oO04hptICBFWBdKPFzRrObBxDjAE=.e187d8a7-2221-4514-a243-c84fd8f4583b@github.com>
Message-ID: <sGff5lGLIdIpzYLS11fXJzjEnPtfLt9RiR1XbbuLWLU=.3a972edb-7a8c-4d49-a80f-783310528b6a@github.com>

On Fri, 6 Dec 2024 13:17:44 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright
>
> Thanks for cleaning up the Reserved Space stuff. I found that Copyright years are not up-to-date for these files:
> 
> gc/g1/g1CardTable.cpp
> gc/g1/g1CardTable.hpp
> gc/shared/markBitMap.cpp
> gc/shenandoah/shenandoahMarkBitMap.cpp

Thanks @afshin-zafari for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22600#issuecomment-2523420791

From wkemper at openjdk.org  Fri Dec  6 22:07:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 6 Dec 2024 22:07:34 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <j89-T-gJKR44GGatDmAMYlVUbEyo9_sd2f_ieOmo73Y=.1c1f1488-28b0-4bb9-9d8d-7c5e2cd3ff8e@github.com>
References: <j89-T-gJKR44GGatDmAMYlVUbEyo9_sd2f_ieOmo73Y=.1c1f1488-28b0-4bb9-9d8d-7c5e2cd3ff8e@github.com>
Message-ID: <_AXsqqprpM4b6HLunJqIrN0QeWCZHSWNcUgzsywD_EY=.483c48d9-0178-4a18-947e-61b314444b5e@github.com>

> Merges tag jdk-21.0.6+6

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/140/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/140/files/e45287d1..e45287d1

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

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

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

From wkemper at openjdk.org  Fri Dec  6 22:07:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 6 Dec 2024 22:07:36 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <j89-T-gJKR44GGatDmAMYlVUbEyo9_sd2f_ieOmo73Y=.1c1f1488-28b0-4bb9-9d8d-7c5e2cd3ff8e@github.com>
References: <j89-T-gJKR44GGatDmAMYlVUbEyo9_sd2f_ieOmo73Y=.1c1f1488-28b0-4bb9-9d8d-7c5e2cd3ff8e@github.com>
Message-ID: <LuCb502LwR6kL_CQxZmfuyWF2lL3YM5Zc2Vr1rzKNBw=.dd178846-5d18-4456-9471-cae15c6dda93@github.com>

On Thu, 5 Dec 2024 14:20:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.6+6

This pull request has now been integrated.

Changeset: 9738579b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/9738579b71e29235da8243e082f7d089f5d1ccf4
Stats:     956 lines in 22 files changed: 874 ins; 41 del; 41 mod

Merge

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

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

From wkemper at openjdk.org  Fri Dec  6 22:39:42 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 6 Dec 2024 22:39:42 GMT
Subject: RFR: 8341992: GenShen:  Fix formatting, remove unreachable code,
 unused imports and unnecessary comments
Message-ID: <iOzQgmPBbsuMNl86c4a065zvlD5gRXql2bcuI8OUn9E=.a4242e17-13d5-4117-8ade-5fa751405176@github.com>

Clean backport.

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

Commit messages:
 - Backport bb7938446b3b6d6729df627cd580957f4a3a2116

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

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

From wkemper at openjdk.org  Fri Dec  6 23:11:02 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 6 Dec 2024 23:11:02 GMT
Subject: Integrated: 8341992: GenShen:  Fix formatting,
 remove unreachable code, unused imports and unnecessary comments
In-Reply-To: <iOzQgmPBbsuMNl86c4a065zvlD5gRXql2bcuI8OUn9E=.a4242e17-13d5-4117-8ade-5fa751405176@github.com>
References: <iOzQgmPBbsuMNl86c4a065zvlD5gRXql2bcuI8OUn9E=.a4242e17-13d5-4117-8ade-5fa751405176@github.com>
Message-ID: <fbQsRuUym-buEkk3JlxDl_X9MNHHTeRZcX0KaDdEX9c=.b1a71f4f-94a6-40fd-a37b-853eb4aad43e@github.com>

On Fri, 6 Dec 2024 22:34:17 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

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

8341992: GenShen:  Fix formatting, remove unreachable code, unused imports and unnecessary comments

Backport-of: bb7938446b3b6d6729df627cd580957f4a3a2116

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

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

From wkemper at openjdk.org  Fri Dec  6 23:45:42 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 6 Dec 2024 23:45:42 GMT
Subject: RFR: 8342001: GenShen: Factor cases for allocation type into separate
 methods
Message-ID: <NLEAj8WSKyGfvydZmPvvVxKbSumW7irGSimRMRltqnQ=.e9c0558c-12be-4e55-8a8e-70c0761b9212@github.com>

Clean backport.

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

Commit messages:
 - Backport 81b631fbc7fc7078786b11c7a85971735ce93b86

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/142/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=142&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342001
  Stats: 293 lines in 2 files changed: 140 ins; 105 del; 48 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/142.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/142/head:pull/142

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

From kdnilsen at openjdk.org  Sat Dec  7 00:18:53 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 7 Dec 2024 00:18:53 GMT
Subject: RFR: 8342001: GenShen: Factor cases for allocation type into
 separate methods
In-Reply-To: <NLEAj8WSKyGfvydZmPvvVxKbSumW7irGSimRMRltqnQ=.e9c0558c-12be-4e55-8a8e-70c0761b9212@github.com>
References: <NLEAj8WSKyGfvydZmPvvVxKbSumW7irGSimRMRltqnQ=.e9c0558c-12be-4e55-8a8e-70c0761b9212@github.com>
Message-ID: <GVu9TxyuQLGkCldOc8fraIsU97cUjCT1JmpJoXcGVMU=.5722f30d-0842-4653-b426-dcbb20697fb1@github.com>

On Fri, 6 Dec 2024 23:40:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/142#pullrequestreview-2486186961

From wkemper at openjdk.org  Sat Dec  7 00:23:05 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 7 Dec 2024 00:23:05 GMT
Subject: Integrated: 8342001: GenShen: Factor cases for allocation type into
 separate methods
In-Reply-To: <NLEAj8WSKyGfvydZmPvvVxKbSumW7irGSimRMRltqnQ=.e9c0558c-12be-4e55-8a8e-70c0761b9212@github.com>
References: <NLEAj8WSKyGfvydZmPvvVxKbSumW7irGSimRMRltqnQ=.e9c0558c-12be-4e55-8a8e-70c0761b9212@github.com>
Message-ID: <0HY_ktdpIf23SEek-12syQdwSM9fChGDVjLU4y-Mqu4=.e5222341-48bf-47a8-b7f6-4a3e0f51d630@github.com>

On Fri, 6 Dec 2024 23:40:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 842a0d8b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/842a0d8b8adc7a91a3256e30105709ffefae818d
Stats:     293 lines in 2 files changed: 140 ins; 105 del; 48 mod

8342001: GenShen: Factor cases for allocation type into separate methods

Reviewed-by: kdnilsen
Backport-of: 81b631fbc7fc7078786b11c7a85971735ce93b86

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

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

From dholmes at openjdk.org  Mon Dec  9 02:38:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 9 Dec 2024 02:38:38 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>
Message-ID: <ozMtEvudBELN1jZOMk3GrscjV3UBH8JIJpIVBkLXBsw=.16da4a51-7106-4942-a0c5-9d3bfe266660@github.com>

On Fri, 6 Dec 2024 14:54:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
>> 
>> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

I don't see the removal of the "moved" functions from ./share/memory/virtualspace.cpp ??

src/hotspot/share/runtime/os.hpp line 408:

> 406:   static size_t vm_page_size() { return OSInfo::vm_page_size(); }
> 407: 
> 408:   static size_t align_up_vm_page_size(size_t size)   { return align_up  (size, os::vm_page_size()); }

Style Nit: please don't add extra whitespace before the opening function parenthesis.

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

PR Review: https://git.openjdk.org/jdk/pull/22600#pullrequestreview-2487519426
PR Review Comment: https://git.openjdk.org/jdk/pull/22600#discussion_r1875194126

From ihse at openjdk.org  Mon Dec  9 12:17:44 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:17:44 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files where
 it was missed
Message-ID: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

Commit messages:
 - 8345795: Update copyright year to 2024 for hotspot in files where it was missed

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

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

From ihse at openjdk.org  Mon Dec  9 12:41:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:41:45 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
Message-ID: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add more hotspot files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22637/files
  - new: https://git.openjdk.org/jdk/pull/22637/files/0605277d..0166c68e

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

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

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

From ihse at openjdk.org  Mon Dec  9 12:48:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:48:41 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
Message-ID: <QAwIZoxKKlbCIi_y4S8m9-u90W07cOngKe20_eEa7i8=.e9705ec8-2461-4805-80c5-a59a411f773e@github.com>

On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more hotspot files

Apologies for the force push; I accidentally pushed a commit that belonged to another branch here, and I just rolled back that commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/22637#issuecomment-2527832604

From stefank at openjdk.org  Mon Dec  9 13:07:55 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Dec 2024 13:07:55 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v3]
In-Reply-To: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
Message-ID: <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>

> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
> 
> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Remove functions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22600/files
  - new: https://git.openjdk.org/jdk/pull/22600/files/2da8bade..b0f91bfe

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

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

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

From dnsimon at openjdk.org  Mon Dec  9 13:08:41 2024
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 9 Dec 2024 13:08:41 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
Message-ID: <oJRwVuQi7noeBJd-Rdac4oj_L6vLi70y7_Ciac8FkPM=.730ca59e-2dfe-4918-aec3-b1bcf287204b@github.com>

On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more hotspot files

JVMCI changes looks good.

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

Marked as reviewed by dnsimon (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2488753749

From stefank at openjdk.org  Mon Dec  9 13:11:40 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 9 Dec 2024 13:11:40 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <ozMtEvudBELN1jZOMk3GrscjV3UBH8JIJpIVBkLXBsw=.16da4a51-7106-4942-a0c5-9d3bfe266660@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>
 <ozMtEvudBELN1jZOMk3GrscjV3UBH8JIJpIVBkLXBsw=.16da4a51-7106-4942-a0c5-9d3bfe266660@github.com>
Message-ID: <GhOOeqWMkuK0VixIQvaxHfjNtiS9L9FRAtWeeM9N00w=.fcb068b4-bdab-4bd2-af55-ebadb411cca9@github.com>

On Mon, 9 Dec 2024 02:36:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I don't see the removal of the "moved" functions from ./share/memory/virtualspace.cpp ??

Good point. That got lost in the split-out from my other rewrites.

> src/hotspot/share/runtime/os.hpp line 408:
> 
>> 406:   static size_t vm_page_size() { return OSInfo::vm_page_size(); }
>> 407: 
>> 408:   static size_t align_up_vm_page_size(size_t size)   { return align_up  (size, os::vm_page_size()); }
> 
> Style Nit: please don't add extra whitespace before the opening function parenthesis.

I find that it makes the code easier to read and the rest of the code uses various extra whitespace to make the code clearer. Is this a strong request?

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

PR Comment: https://git.openjdk.org/jdk/pull/22600#issuecomment-2527880191
PR Review Comment: https://git.openjdk.org/jdk/pull/22600#discussion_r1875955997

From sspitsyn at openjdk.org  Mon Dec  9 20:04:38 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 9 Dec 2024 20:04:38 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v2]
In-Reply-To: <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <FhUqPo1RUwq95_cVd0K-7DhvzzZ7JuWW09wE7r59D50=.ea1dcf63-9597-42d1-87a4-37f5240d3a11@github.com>
Message-ID: <qHJoOG-oixqaOUOjQwxGRYPzhlrzp_7Q5QzaSvDkeqE=.7f469a1b-946e-4da9-8efa-0a8bf222ceab@github.com>

On Mon, 9 Dec 2024 12:41:45 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more hotspot files

I've looked at the Serviceability related copyright updates (prims, SA, debugger and tests). They are good.

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

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2489952883

From xpeng at openjdk.org  Mon Dec  9 20:42:21 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 9 Dec 2024 20:42:21 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
Message-ID: <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>

> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
> 
> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
> 
> TIP:
> 
> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
> 
> Parallelized:
> 
> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
> 
> 
> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
> 
> 
> ### Additional test
> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Use parallel_heap_region_iterate to walk the regions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22538/files
  - new: https://git.openjdk.org/jdk/pull/22538/files/368c6aae..4507656e

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

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

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

From ihse at openjdk.org  Mon Dec  9 21:09:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 21:09:41 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
Message-ID: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert mistaken changes to binary files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22637/files
  - new: https://git.openjdk.org/jdk/pull/22637/files/0166c68e..5610a605

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

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

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

From wkemper at openjdk.org  Mon Dec  9 22:13:38 2024
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 9 Dec 2024 22:13:38 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
Message-ID: <7dozpUw8xDi1lZPEjbaKvAwsaQJrM6piABij7_hwXzI=.33525ec5-f57d-40cd-b312-c0eed413034b@github.com>

On Mon, 9 Dec 2024 20:42:21 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> ### Additional test
>> - [x] MacOS AArch64 server fastdebug, hotspot_gc_shenandoah
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use parallel_heap_region_iterate to walk the regions

Thanks for the updates. It looks good to me!

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22538#pullrequestreview-2490222353

From xpeng at openjdk.org  Tue Dec 10 01:18:52 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 10 Dec 2024 01:18:52 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
Message-ID: <imrKWqnBY45-II-3W4DvheRzyeAcrYHDgsI4eJiJTb8=.7205645d-1355-4203-8f4f-31a0505249f1@github.com>

On Mon, 9 Dec 2024 20:42:21 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> For the same test test, but with large heap with 32G memory, the improvement on concurrent cleanup is much smaller, which might be related t...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use parallel_heap_region_iterate to walk the regions

@kdnilsen @ysramakrishna @shipilev 

I'm gonna need more reviews for the change, thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/22538#issuecomment-2529963162

From dholmes at openjdk.org  Tue Dec 10 04:01:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 04:01:38 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
Message-ID: <FQqaRMK8sCtC8DH4iJZXU2jWhNYIWiDtVgT0DTyN1jQ=.3df4d81c-39ef-4496-8ba5-ee17cb00e606@github.com>

On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

I scanned the full diff and also did some random checks. Looks good. Thanks for fixing.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2490894140

From tschatzl at openjdk.org  Tue Dec 10 07:20:38 2024
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 10 Dec 2024 07:20:38 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
Message-ID: <46K2W9LUIv9jOu7TEtm4Js4TfgzBRyfwhntnqdaQTUY=.f4c7b046-942b-4fc9-9bb5-8690b1f33391@github.com>

On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

lgtm, looked at gc files in both shared and cpu and os specific directories.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22637#pullrequestreview-2491237029

From dholmes at openjdk.org  Tue Dec 10 07:31:44 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 07:31:44 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v3]
In-Reply-To: <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>
Message-ID: <954m7aVM_NrvlBuiYfZnDyb3uQkzTZ8G9s3MqQ8ggYE=.96c4002a-19c5-40e4-ae14-886459154b45@github.com>

On Mon, 9 Dec 2024 13:07:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
>> 
>> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove functions

Looks good. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22600#pullrequestreview-2491269342

From dholmes at openjdk.org  Tue Dec 10 07:31:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Dec 2024 07:31:45 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v2]
In-Reply-To: <GhOOeqWMkuK0VixIQvaxHfjNtiS9L9FRAtWeeM9N00w=.fcb068b4-bdab-4bd2-af55-ebadb411cca9@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <uz6l7FhQQ8o4fAknVFmd5hxGOIJHntgjchshIAQVS4g=.046c6a48-e0eb-4f02-a925-873db72b281b@github.com>
 <ozMtEvudBELN1jZOMk3GrscjV3UBH8JIJpIVBkLXBsw=.16da4a51-7106-4942-a0c5-9d3bfe266660@github.com>
 <GhOOeqWMkuK0VixIQvaxHfjNtiS9L9FRAtWeeM9N00w=.fcb068b4-bdab-4bd2-af55-ebadb411cca9@github.com>
Message-ID: <FkXy9ZnN_MN_E0b9lZjvxh0rndeGy54eOYO6k-V5cQk=.41aaf05b-ee97-4335-868e-c630fdb6b4b5@github.com>

On Mon, 9 Dec 2024 13:08:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> src/hotspot/share/runtime/os.hpp line 408:
>> 
>>> 406:   static size_t vm_page_size() { return OSInfo::vm_page_size(); }
>>> 407: 
>>> 408:   static size_t align_up_vm_page_size(size_t size)   { return align_up  (size, os::vm_page_size()); }
>> 
>> Style Nit: please don't add extra whitespace before the opening function parenthesis.
>
> I find that it makes the code easier to read and the rest of the code uses various extra whitespace to make the code clearer. Is this a strong request?

No not a strong request. I see there is precedent for this already in the file - though in some cases it isn't even needed for alignment purposes. I find extra whitespace between a function name and the opening parenthesis to be visually jarring and it makes me have to re-read to ensure I'm not mis-reading something. YMMV.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22600#discussion_r1877485988

From ihse at openjdk.org  Tue Dec 10 08:51:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Dec 2024 08:51:45 GMT
Subject: RFR: 8345795: Update copyright year to 2024 for hotspot in files
 where it was missed [v3]
In-Reply-To: <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
 <0TATGf2SyXxL9BAJlx3Xky0kpjQPFNtYOJDOwjEHJzo=.1d2af5d1-308a-4403-82c7-13ab2a614ee8@github.com>
Message-ID: <cxbGNoeWXFNqKVFrQM26GTNE3i40jFwyXPW87pUXSjU=.cdcf3cec-99a6-45ad-aabc-9569a19ac46c@github.com>

On Mon, 9 Dec 2024 21:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary files

Thanks for all reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22637#issuecomment-2530834262

From ihse at openjdk.org  Tue Dec 10 08:51:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Dec 2024 08:51:46 GMT
Subject: Integrated: 8345795: Update copyright year to 2024 for hotspot in
 files where it was missed
In-Reply-To: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
References: <YI9VXfcg2_uWmGWixTCKb5kmVXOfO0m9Xd6vH-bzB1k=.eedb5be8-57c2-45f1-87f6-3aaadd523ed6@github.com>
Message-ID: <L5e5EQstNUh6-uYcJ2g3fXB4YlyVbBVqorjQlw4f6ms=.7a58b6dd-6b71-432d-b2c5-d93fa998b3c9@github.com>

On Mon, 9 Dec 2024 12:11:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This pull request has now been integrated.

Changeset: 2979806c
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2979806c72561cb4d4e8ac3d44dbcea347ace966
Stats:     921 lines in 921 files changed: 0 ins; 0 del; 921 mod

8345795: Update copyright year to 2024 for hotspot in files where it was missed

Reviewed-by: dholmes, tschatzl, dnsimon, sspitsyn

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

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

From shade at openjdk.org  Tue Dec 10 15:01:13 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 10 Dec 2024 15:01:13 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <7Ni9wGl0-v-mm2CxhsfWrZxLeqtyGJsPxkfdMRenqSY=.bb67598a-7c69-4fe5-a258-8d28f2b64c6e@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

Well, it is not technically a `NULL -> nullptr` changes we handle with PRs like these, but I guess it is good to have a consistent wording.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22647#pullrequestreview-2491632690

From szaldana at openjdk.org  Tue Dec 10 15:01:13 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Tue, 10 Dec 2024 15:01:13 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
Message-ID: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>

Hi all, 

This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 

I verified where those uses are with: 
`git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`

The relevant output: 

File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
9:-  // No need for post barrier if storing NULL
File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
9:-    // must be either an oop or NULL
12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)


Changes affect comments only. 

Thanks, 
Sonia

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

Commit messages:
 - 8345647: Fix recent NULL usage backsliding in Shenandoah

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

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

From jwaters at openjdk.org  Tue Dec 10 15:01:13 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 10 Dec 2024 15:01:13 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <5I1bO6M3SO1HZWjEh5vPL0sxBFjfMX036OoulYxWWvg=.4228977a-7b82-4c75-a850-b00af55150b8@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

Not really sure if just a comment change warrants a Pull Request, but since it is already done and is trivial why not

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22647#pullrequestreview-2492312867

From ysr at openjdk.org  Tue Dec 10 18:13:46 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 10 Dec 2024 18:13:46 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
Message-ID: <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>

On Mon, 9 Dec 2024 20:42:21 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> For the same test test, but with large heap with 32G memory, the improvement on concurrent cleanup is much smaller, which might be related t...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use parallel_heap_region_iterate to walk the regions

Good improvement. 

Just some minor comments.

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

> 1270: void ShenandoahFreeSet::recycle_trash() {
> 1271:   // lock is not reentrable, check we don't have it
> 1272:   shenandoah_assert_not_heaplocked();

Not your change but may be a good time to fix:

"not reentrable" -> "non-reentrant" (which is the more traditional term)

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 884:

> 882:   // During full gc, multiple GC worker threads may change region affiliations without a lock.  No lock is enforced
> 883:   // on read and write of _affiliated_region_count.  At the end of full gc, a single thread overwrites the count with
> 884:   // a coherent value.

Is the comment in its entirety still valid now? The part about "No lock is enforced" seems a bit dubious given the atomic op.

Similarly the comment in `decrement_...` below.

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 91:

> 89:     SpaceMangler::mangle_region(MemRegion(_bottom, _end));
> 90:   }
> 91:   _recycling.unset();

Was this necessary, given the c'tor of the struct ShenandoiahFlag is called for the `_recycling` field? To check, I'd assert:

assert(!_recycling.is_set(), "C'tor should have been called by now.");

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 574:

> 572: 
> 573: 
> 574: void ShenandoahHeapRegion::recycle_internal() {

A paranoid assertion would be: ```assert(_recycling.is_set() && is_trash(), "Wrong state");```
But may be this is too paranoid since callers already check.

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 192:

> 190:   void make_committed_bypass();
> 191: 
> 192:   // Individual states:

// Primitive state predicates

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 199:

> 197: 
> 198:   bool is_empty_state(RegionState state) const { return state == _empty_committed || state == _empty_uncommitted; }
> 199:   bool is_humongous_start_state(RegionState state) const { return state == _humongous_start || state == _pinned_humongous_start; }

These should move below line 201 which states:


// Participation in logical groups:

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 201:

> 199:   bool is_humongous_start_state(RegionState state) const { return state == _humongous_start || state == _pinned_humongous_start; }
> 200: 
> 201:   // Participation in logical groups:

// Derived state predicates (boolean combinations of individual states)

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 210:

> 208:   bool is_cset()                   const { auto cur_state = state(); return cur_state == _cset || cur_state == _pinned_cset; }
> 209:   bool is_pinned()                 const { auto cur_state = state(); return cur_state == _pinned || cur_state == _pinned_cset || cur_state == _pinned_humongous_start; }
> 210:   bool is_regular_pinned()         const { return state() == _pinned; }

Should go up into the primitive list at the top.

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 268:

> 266:   CENSUS_NOISE(uint _youth;)   // tracks epochs of retrograde ageing (rejuvenation)
> 267: 
> 268:   ShenandoahSharedFlag _recycling;

1-line documentation of what it represents.

// Used to indicate that the region is being recycled; see try_recycle*().

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22538#pullrequestreview-2490587106
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1877048744
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1877055108
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1877164961
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1877167040
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1877076166
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1877075569
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1877092813
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1877113173
PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1877134362

From wkemper at openjdk.org  Tue Dec 10 19:20:33 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 10 Dec 2024 19:20:33 GMT
Subject: RFR: Merge openjdk/jdk:master [v2]
In-Reply-To: <uVnN2YHWAZGvVHCBfiV74YhprHHSFgs-I9VP6Hbmb9E=.eb4a2751-08b5-4dfe-b488-2c455997af03@github.com>
References: <uVnN2YHWAZGvVHCBfiV74YhprHHSFgs-I9VP6Hbmb9E=.eb4a2751-08b5-4dfe-b488-2c455997af03@github.com>
Message-ID: <LAv3yeeVKxlQzWM_O6t2YuZcieAuAifeayWu6Pyy9NU=.b4a8c6bf-6a09-4358-bd98-c709d7d46667@github.com>

> Merges tag jdk-24+27

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

 - Merge branch 'master' into merge-jdk-24+27
 - 8344607: Link Time Optimization - basic support for clang
   
   Reviewed-by: lucy, jkern, ihse
 - 8345302: Building microbenchmarks require larger Java heap
   
   Reviewed-by: shade, mcimadamore
 - 8345514: Should use internal class name when calling ClassLoader.getResourceAsByteArray
   
   Reviewed-by: iklam, matsaave
 - 8345591: [aarch64] macroAssembler_aarch64.cpp compile fails ceil_log2 not declared
   
   Reviewed-by: coleenp, alanb, syan
 - 8328944: NMT reports "unknown" memory
   
   Reviewed-by: jsjolen, coleenp
 - 8345565: Remove remaining SecurityManager motivated APIs from sun.reflect.util
   
   Reviewed-by: mullan, rriggs, liach
 - 8345339: JFR: Missing javadoc for RecordingStream::onMetadata
   
   Reviewed-by: nbenalla, liach
 - 8343699: [aarch64] Bug in MacroAssembler::klass_decode_mode()
   
   Reviewed-by: adinn, coleenp
 - 8345578: New test in JDK-8343622 fails with a promoted build
   
   Reviewed-by: mullan
 - ... and 162 more: https://git.openjdk.org/shenandoah/compare/d5668df7...a8faa293

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

Changes: https://git.openjdk.org/shenandoah/pull/555/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=555&range=01
  Stats: 55937 lines in 932 files changed: 41721 ins; 10039 del; 4177 mod
  Patch: https://git.openjdk.org/shenandoah/pull/555.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah.git pull/555/head:pull/555

PR: https://git.openjdk.org/shenandoah/pull/555

From xpeng at openjdk.org  Tue Dec 10 19:48:40 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 10 Dec 2024 19:48:40 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
 <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
Message-ID: <zwsqGr0v08wgiC9EeLTNyPqCD41UaAFJ6lYpT4rIk80=.db7d5ce9-dea4-4fc4-bd0d-10d00b16244e@github.com>

On Tue, 10 Dec 2024 02:42:50 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use parallel_heap_region_iterate to walk the regions
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 91:
> 
>> 89:     SpaceMangler::mangle_region(MemRegion(_bottom, _end));
>> 90:   }
>> 91:   _recycling.unset();
> 
> Was this necessary, given the c'tor of the struct ShenandoiahFlag is called for the `_recycling` field? To check, I'd assert:
> 
> assert(!_recycling.is_set(), "C'tor should have been called by now.");

There could be race condition that other caller immoderately set the flag, hence the assert may fail, notice similar race condition in test, that is why the double check for is_trash() was added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1878729609

From wkemper at openjdk.org  Tue Dec 10 19:49:21 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 10 Dec 2024 19:49:21 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <uVnN2YHWAZGvVHCBfiV74YhprHHSFgs-I9VP6Hbmb9E=.eb4a2751-08b5-4dfe-b488-2c455997af03@github.com>
References: <uVnN2YHWAZGvVHCBfiV74YhprHHSFgs-I9VP6Hbmb9E=.eb4a2751-08b5-4dfe-b488-2c455997af03@github.com>
Message-ID: <E00g23_xXpyCbcAAgQw1clfuk4tkskEkKGxUxW2nIlU=.b5a8154a-3aa5-488c-8ff6-0b036331189e@github.com>

On Fri, 6 Dec 2024 14:13:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-24+27

This pull request has now been integrated.

Changeset: 9065ccbd
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/9065ccbd6fb9686d7c0ebb18894049e555603335
Stats:     55937 lines in 932 files changed: 41721 ins; 10039 del; 4177 mod

Merge

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

PR: https://git.openjdk.org/shenandoah/pull/555

From xpeng at openjdk.org  Tue Dec 10 19:55:20 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 10 Dec 2024 19:55:20 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v9]
In-Reply-To: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
Message-ID: <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>

> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
> 
> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
> 
> TIP:
> 
> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
> 
> Parallelized:
> 
> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
> 
> 
> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
> 
> 
> For the same test test, but with large heap with 32G memory, the improvement on concurrent cleanup is much smaller, which might be related to less race and contention with mutator threads when the heap size i...

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22538/files
  - new: https://git.openjdk.org/jdk/pull/22538/files/4507656e..1bce0d7e

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

  Stats: 13 lines in 3 files changed: 3 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22538.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22538/head:pull/22538

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

From xpeng at openjdk.org  Tue Dec 10 21:02:42 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 10 Dec 2024 21:02:42 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
 <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
Message-ID: <qH28gKkhZbvoUnTba9senQjaRUrd0zeww6OQxaUB3NM=.ac3eac16-e577-4517-84c5-9644510bc12c@github.com>

On Tue, 10 Dec 2024 01:52:41 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use parallel_heap_region_iterate to walk the regions
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 884:
> 
>> 882:   // During full gc, multiple GC worker threads may change region affiliations without a lock.  No lock is enforced
>> 883:   // on read and write of _affiliated_region_count.  At the end of full gc, a single thread overwrites the count with
>> 884:   // a coherent value.
> 
> Is the comment in its entirety still valid now? The part about "No lock is enforced" seems a bit dubious given the atomic op.
> 
> Similarly the comment in `decrement_...` below.

Yes It is atomic, the lock/safepoint seems not needed. I'll probably keep the comment  as it is in this PR, since the are called from different places of FullGC and concurrentGC, we can cleanup these methods later I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1878849089

From xpeng at openjdk.org  Tue Dec 10 21:05:41 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 10 Dec 2024 21:05:41 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
 <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
Message-ID: <_lfJtyNS419Ur3V2hhwLdcP0EPntP-nmP8Rn8HdJxm4=.a654a75b-d72d-4436-bd80-317178bac8f6@github.com>

On Tue, 10 Dec 2024 18:10:46 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Good improvement.
> 
> Just some minor comments.

Thank you @ysramakrishna,  I have addressed all the comments except the one for comment on decrement_/increment_ methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/22538#issuecomment-2532885946

From ysr at openjdk.org  Tue Dec 10 23:10:40 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 10 Dec 2024 23:10:40 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <zwsqGr0v08wgiC9EeLTNyPqCD41UaAFJ6lYpT4rIk80=.db7d5ce9-dea4-4fc4-bd0d-10d00b16244e@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
 <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
 <zwsqGr0v08wgiC9EeLTNyPqCD41UaAFJ6lYpT4rIk80=.db7d5ce9-dea4-4fc4-bd0d-10d00b16244e@github.com>
Message-ID: <79DiuHxGpHadOKlUi5pVkg28taCXNWLIl3G08y_9jBY=.c543ba6b-0af6-458e-95f9-8e51e5033efb@github.com>

On Tue, 10 Dec 2024 19:46:08 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> There could be race condition that other caller immoderately set the flag, hence the assert may fail, 

Which other caller? We are asserting here in the constructor of the SHR object. Is this object visible to anyone other than the constructing thread at this point? I am not sure I understand the reason for a race here.

It's possible I am missing something in the lifecycle of the SHR object here.

If so, it would be good to add a brief comment on why this needs to occur here despite the constructor for the `_recycling` flag which should have been called by this point, so it should already be unset by now.

> notice similar race condition in test, that is why the double check for is_trash() was added.

Yes, I understood that race, which is between multiple threads potentially racing to recycle a trashed region, and resolves such a race in favor of the thread that manages to CAS  true into `_recycling` with interlocking checks for its `trash`ness.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1879042788

From ysr at openjdk.org  Tue Dec 10 23:15:41 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 10 Dec 2024 23:15:41 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v9]
In-Reply-To: <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
Message-ID: <HAZ_3poP7oT3bqZ0fXIb9rJqFMvSoF79WmQMlNLPvXs=.09e69451-3ff5-4ba1-9c3d-cbe63e0956c0@github.com>

On Tue, 10 Dec 2024 19:55:20 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> For the same test test, but with large heap with 32G memory, the improvement on concurrent cleanup is much smaller, which might be related t...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Reviewed and left a couple of comments. No need for a re-review, since neither of my comments is a correctness issue that necessarily needs any code changes.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22538#pullrequestreview-2493890753

From ysr at openjdk.org  Tue Dec 10 23:15:42 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 10 Dec 2024 23:15:42 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <qH28gKkhZbvoUnTba9senQjaRUrd0zeww6OQxaUB3NM=.ac3eac16-e577-4517-84c5-9644510bc12c@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
 <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
 <qH28gKkhZbvoUnTba9senQjaRUrd0zeww6OQxaUB3NM=.ac3eac16-e577-4517-84c5-9644510bc12c@github.com>
Message-ID: <r6L2_oVpEnaxzrfdPjkYuB3x-3qQQ3nqwl1EMcaQZpE=.a5546a55-2610-4f9e-849c-bf33518997b1@github.com>

On Tue, 10 Dec 2024 21:00:00 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 884:
>> 
>>> 882:   // During full gc, multiple GC worker threads may change region affiliations without a lock.  No lock is enforced
>>> 883:   // on read and write of _affiliated_region_count.  At the end of full gc, a single thread overwrites the count with
>>> 884:   // a coherent value.
>> 
>> Is the comment in its entirety still valid now? The part about "No lock is enforced" seems a bit dubious given the atomic op.
>> 
>> Similarly the comment in `decrement_...` below.
>
> Yes It is atomic, the lock/safepoint seems not needed. I'll probably keep the comment  as it is in this PR, since the are called from different places of FullGC and concurrentGC, we can cleanup these methods later I think.

ok for now. Will be worth examining the uses from full at some point but this was just a comment so ok for now. May be leave a `TODO` comment to track if you feel like.


// TODO: Check and correct comment, if obsolete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1879050043

From xpeng at openjdk.org  Tue Dec 10 23:24:40 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 10 Dec 2024 23:24:40 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <79DiuHxGpHadOKlUi5pVkg28taCXNWLIl3G08y_9jBY=.c543ba6b-0af6-458e-95f9-8e51e5033efb@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
 <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
 <zwsqGr0v08wgiC9EeLTNyPqCD41UaAFJ6lYpT4rIk80=.db7d5ce9-dea4-4fc4-bd0d-10d00b16244e@github.com>
 <79DiuHxGpHadOKlUi5pVkg28taCXNWLIl3G08y_9jBY=.c543ba6b-0af6-458e-95f9-8e51e5033efb@github.com>
Message-ID: <3LbG7L0omjTTXfYRPN2GoKQfnyxHquumNGy_G63vKlI=.a6b6c244-af12-4ebe-8b91-224a674dbde5@github.com>

On Tue, 10 Dec 2024 23:07:00 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Which other caller? 

Sorry for the confusion, not the caller of this specific method.

I meant to say the the mutator thread, mutator may call try_recycle_trashed here https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L1005 under heap-lock, we have removed the heap-lock from GC concurrent cleanup, therefore it becomes race condition between mutator and GC threads.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1879060999

From xpeng at openjdk.org  Wed Dec 11 00:38:40 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 11 Dec 2024 00:38:40 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <r6L2_oVpEnaxzrfdPjkYuB3x-3qQQ3nqwl1EMcaQZpE=.a5546a55-2610-4f9e-849c-bf33518997b1@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
 <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
 <qH28gKkhZbvoUnTba9senQjaRUrd0zeww6OQxaUB3NM=.ac3eac16-e577-4517-84c5-9644510bc12c@github.com>
 <r6L2_oVpEnaxzrfdPjkYuB3x-3qQQ3nqwl1EMcaQZpE=.a5546a55-2610-4f9e-849c-bf33518997b1@github.com>
Message-ID: <JPx_zrE9_ZoaXOALaM6_fxJgF7DGtmAQjn0uEZ_IPyI=.fa4c1029-7108-4454-b1d6-3a1786d93e26@github.com>

On Tue, 10 Dec 2024 23:11:32 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Yes It is atomic, the lock/safepoint seems not needed. I'll probably keep the comment  as it is in this PR, since the are called from different places of FullGC and concurrentGC, we can cleanup these methods later I think.
>
> ok for now. Will be worth examining the uses from full at some point but this was just a comment so ok for now. May be leave a `TODO` comment to track if you feel like.
> 
> 
> // TODO: Check and correct comment, if obsolete.

Thanks, I'll add it if I amend any new change to this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1879139672

From kdnilsen at openjdk.org  Wed Dec 11 06:38:40 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 11 Dec 2024 06:38:40 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v9]
In-Reply-To: <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
Message-ID: <arHtyAcJwx6r3KG2Mrnk3pScWYlaQhojrfFefK0OIV8=.ea6bc296-e554-41f0-b02c-56ccfb4d3e21@github.com>

On Tue, 10 Dec 2024 19:55:20 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> For the same test test, but with large heap with 32G memory, the improvement on concurrent cleanup is much smaller, which might be related t...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Thanks.  This looks like a nice improvement.

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

Marked as reviewed by kdnilsen (Author).

PR Review: https://git.openjdk.org/jdk/pull/22538#pullrequestreview-2494439957

From mli at openjdk.org  Wed Dec 11 09:33:37 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 11 Dec 2024 09:33:37 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <xBKuMroVJrlcdbXhx5iSzGF0DQn0G5K2Ur0OPNBAQOk=.5f5d06ce-efbd-4a26-8513-e65c0e883412@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

Looks good.

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22647#pullrequestreview-2494906046

From stefank at openjdk.org  Wed Dec 11 11:55:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Dec 2024 11:55:43 GMT
Subject: RFR: 8345656: Move os alignment functions out of ReservedSpace
 [v3]
In-Reply-To: <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
 <8vCk8qHXFLcm4CflJnPoruVEzrbznDT-Oh1JLDa3Cto=.40948df2-054d-4469-89aa-7306dbf9f3b1@github.com>
Message-ID: <anpQYvgRmsvKVLHBuQUFsbgyMXHO7EvA8ThpcngK3Ek=.c65f371c-20cb-4223-9cf7-1bf8fb67f328@github.com>

On Mon, 9 Dec 2024 13:07:55 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
>> 
>> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove functions

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22600#issuecomment-2535755486

From stefank at openjdk.org  Wed Dec 11 11:55:43 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 11 Dec 2024 11:55:43 GMT
Subject: Integrated: 8345656: Move os alignment functions out of ReservedSpace
In-Reply-To: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
References: <SkvbJ5BQYU3Yk7z6RIaX4Y1qf_AVdAyzrMArcuQ2cSs=.f87e1c97-b2b4-4b19-a1d5-d7739f90d493@github.com>
Message-ID: <LdeXgZEdp1Gr0heKcIHpvkTZJw2ZkZZvSDunkRELo4M=.57fc50c8-5a97-49a8-82e7-7745bb3f00d3@github.com>

On Fri, 6 Dec 2024 09:58:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> I have a wish to simplify the ReservedSpace classes (See: [JDK-8345655](https://bugs.openjdk.org/browse/JDK-8345655)) and as a small step I would like to move the small helper functions that align addresses and sizes to `os::vm_page_size()` and `os::vm_allocation_granularity()` out to be `os::` helpers.
> 
> Tested tier1-3 together with the other patches in the JDK-8345655 prototype.

This pull request has now been integrated.

Changeset: 076bfa68
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/076bfa688c8ee19fa5eea1d18cfa84a3504af762
Stats:     79 lines in 14 files changed: 29 ins; 33 del; 17 mod

8345656: Move os alignment functions out of ReservedSpace

Reviewed-by: dholmes

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

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

From szaldana at openjdk.org  Wed Dec 11 14:50:14 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 11 Dec 2024 14:50:14 GMT
Subject: Integrated: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <9bywElNShJzZIwGpmwpdD1hefpWszNwoQr7wLc79PrU=.a3a5fe85-b4c2-4788-b768-27a532d27832@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

This pull request has now been integrated.

Changeset: e2948991
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e2948991544d50a901be509fbc6406c2a16849ec
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8345647: Fix recent NULL usage backsliding in Shenandoah

Reviewed-by: shade, jwaters, mli

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

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

From kbarrett at openjdk.org  Wed Dec 11 15:04:54 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 15:04:54 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <7Ni9wGl0-v-mm2CxhsfWrZxLeqtyGJsPxkfdMRenqSY=.bb67598a-7c69-4fe5-a258-8d28f2b64c6e@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
 <7Ni9wGl0-v-mm2CxhsfWrZxLeqtyGJsPxkfdMRenqSY=.bb67598a-7c69-4fe5-a258-8d28f2b64c6e@github.com>
Message-ID: <gVa2Sd7boIugLNRXDNXXV11b6UDIo19fYZ1XVt4TWWc=.13aab68a-8902-42a0-a7e6-3d362d487bf1@github.com>

On Tue, 10 Dec 2024 09:28:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Well, it is not technically a `NULL -> nullptr` changes we handle with PRs like these, but I guess it is good to have a consistent wording.

We've also been changing "NULL" in comments and strings.  This avoids having an identifier in those that isn't actually
present in code.  Perhaps more importantly, it prepares for JDK-8343802.  In comments and strings we sometimes use
"null" and sometimes use "nullptr", depending on whether the context code-like or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536242322

From kbarrett at openjdk.org  Wed Dec 11 15:04:54 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 15:04:54 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <5I1bO6M3SO1HZWjEh5vPL0sxBFjfMX036OoulYxWWvg=.4228977a-7b82-4c75-a850-b00af55150b8@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
 <5I1bO6M3SO1HZWjEh5vPL0sxBFjfMX036OoulYxWWvg=.4228977a-7b82-4c75-a850-b00af55150b8@github.com>
Message-ID: <ptSdI5eaf3btdbMkSkXRJ3tpZ8Vkb8JyZPOmt3JZWkE=.aa2ff0d0-a027-4933-9416-1b36b806d516@github.com>

On Tue, 10 Dec 2024 13:22:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Not really sure if just a comment change warrants a Pull Request, but since it is already done and is trivial why not

*Any* change requires a JBS issue and a PR.  Sometimes something simple like this can be folded into another change.

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

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536247617

From kbarrett at openjdk.org  Wed Dec 11 15:12:14 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 15:12:14 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <ugDcpsY9uL9lqnDNLplnrh6cEtUKxLGq4C0NVfT-J18=.70e68690-3151-4352-96cb-f1ba10259ac3@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

Unfortunately, this change was incomplete.  It missed these:

./share/gc/shenandoah/shenandoahFreeSet.cpp:  // Overwrite with non-zero (non-NULL) values only if necessary for allocation bookkeeping.
./share/gc/shenandoah/shenandoahGenerationalEvacuationTask.cpp:      assert(obj->klass() != nullptr, "klass should not be NULL");

In both of those lines, s/NULL/null/

Sorry I didn't point this out before this PR was integrated.  I only noticed the PR this morning. Guess we'll need
another JBS issue and PR...

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

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536264494

From kbarrett at openjdk.org  Wed Dec 11 15:17:19 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 15:17:19 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
Message-ID: <O1g478Sj9KWm55u7TfcPHuWIxAmZ08tIJuWmr30qM4k=.d1e0c68c-fdeb-4997-a1dc-78f4344af404@github.com>

On Mon, 9 Dec 2024 15:29:56 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
> 
> I verified where those uses are with: 
> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
> 
> The relevant output: 
> 
> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
> 9:-  // No need for post barrier if storing NULL
> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
> 9:-    // must be either an oop or NULL
> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
> 
> 
> Changes affect comments only. 
> 
> Thanks, 
> Sonia

New JBS issue for the missed cases:
https://bugs.openjdk.org/browse/JDK-8346008

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

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536277486

From szaldana at openjdk.org  Wed Dec 11 16:08:21 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 11 Dec 2024 16:08:21 GMT
Subject: RFR: 8345647: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <O1g478Sj9KWm55u7TfcPHuWIxAmZ08tIJuWmr30qM4k=.d1e0c68c-fdeb-4997-a1dc-78f4344af404@github.com>
References: <h2aZToh-J8WdKucL_FAI8_kIomI9bGLr-u7w9jqCqPk=.f8912871-f369-4563-b37d-d0d645c564df@github.com>
 <O1g478Sj9KWm55u7TfcPHuWIxAmZ08tIJuWmr30qM4k=.d1e0c68c-fdeb-4997-a1dc-78f4344af404@github.com>
Message-ID: <fkpsEeGTrCCaL6xISp6w2T6bdfl-8xsHlL2yNpOT134=.d94f6052-8c65-4ed4-99b1-034bc0d520ee@github.com>

On Wed, 11 Dec 2024 15:14:06 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all, 
>> 
>> This PR addresses [8345647](https://bugs.openjdk.org/browse/JDK-8345647) addressing uses of `NULL` in Shenandoah. These should be replaced to `null`. 
>> 
>> I verified where those uses are with: 
>> `git show <commit-id> --name-only | while read file; do echo "File: $file"; git diff <commit-id> -- "$file" | grep -n -F 'NULL'; done`
>> 
>> The relevant output: 
>> 
>> File: src/hotspot/cpu/ppc/gc/shenandoah/shenandoahBarrierSetAssembler_ppc.cpp
>> 9:-  // No need for post barrier if storing NULL
>> File: src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp
>> 9:-    // must be either an oop or NULL
>> 12:     if (t == TypePtr::NULL_PTR || t == Type::TOP)
>> 
>> 
>> Changes affect comments only. 
>> 
>> Thanks, 
>> Sonia
>
> New JBS issue for the missed cases:
> https://bugs.openjdk.org/browse/JDK-8346008

Hi @kimbarrett, thanks for taking a look. Apologies for missing those. I can follow up with a PR for the remaining changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/22647#issuecomment-2536415158

From szaldana at openjdk.org  Wed Dec 11 16:14:21 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 11 Dec 2024 16:14:21 GMT
Subject: RFR: 8346008: Fix recent NULL usage backsliding in Shenandoah
Message-ID: <KlNjQciLX6t___EWH9xyUdgTSSzsuoKlCj6tXL8jtsY=.2cfe8e46-d914-4bcf-927b-65cdfb40f5b6@github.com>

Hi all, 

This PR addresses [8346008](https://bugs.openjdk.org/browse/JDK-8346008). It's a follow-up from [8345647](https://bugs.openjdk.org/browse/JDK-8345647) with some cases I missed. 

Thanks, 
Sonia

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

Commit messages:
 - 8346008: Fix recent NULL usage backsliding in Shenandoah

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

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

From kbarrett at openjdk.org  Wed Dec 11 16:56:11 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 11 Dec 2024 16:56:11 GMT
Subject: RFR: 8346008: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <KlNjQciLX6t___EWH9xyUdgTSSzsuoKlCj6tXL8jtsY=.2cfe8e46-d914-4bcf-927b-65cdfb40f5b6@github.com>
References: <KlNjQciLX6t___EWH9xyUdgTSSzsuoKlCj6tXL8jtsY=.2cfe8e46-d914-4bcf-927b-65cdfb40f5b6@github.com>
Message-ID: <nAkixRT0G42aq0NN02Elq9r_MGOJtcsZjgWk70b88j0=.ab4bf2f2-69ff-49e0-989e-48acc82a7726@github.com>

On Wed, 11 Dec 2024 16:10:06 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8346008](https://bugs.openjdk.org/browse/JDK-8346008). It's a follow-up from [8345647](https://bugs.openjdk.org/browse/JDK-8345647) with some cases I missed. 
> 
> Thanks, 
> Sonia

Looks good, and trivial.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22684#pullrequestreview-2496271535

From ysr at openjdk.org  Wed Dec 11 17:07:16 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 11 Dec 2024 17:07:16 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v9]
In-Reply-To: <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
Message-ID: <_9vmQOMCXU2ENdRzJn9U1ajdPOA9VQqCuESleQiLHWA=.f3bf455c-c38c-47c0-9268-11c60bf75ce1@github.com>

On Tue, 10 Dec 2024 19:55:20 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> For the same test test, but with large heap with 32G memory, the improvement on concurrent cleanup is much smaller, which might be related t...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22538#pullrequestreview-2496299420

From ysr at openjdk.org  Wed Dec 11 17:07:18 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 11 Dec 2024 17:07:18 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v8]
In-Reply-To: <3LbG7L0omjTTXfYRPN2GoKQfnyxHquumNGy_G63vKlI=.a6b6c244-af12-4ebe-8b91-224a674dbde5@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <sZyxDkGu_fDBLABvtobFxIHjGZA94o5oo4Uxjcw8L4M=.09c972f1-125b-4b6c-917d-66832bf263df@github.com>
 <9_mdklCBz6MYBwvRw2GWIBL5zN9pz2UZ4ZnhsjgsryU=.0f8a2340-7a97-4659-8b65-b82e4cefd3dd@github.com>
 <zwsqGr0v08wgiC9EeLTNyPqCD41UaAFJ6lYpT4rIk80=.db7d5ce9-dea4-4fc4-bd0d-10d00b16244e@github.com>
 <79DiuHxGpHadOKlUi5pVkg28taCXNWLIl3G08y_9jBY=.c543ba6b-0af6-458e-95f9-8e51e5033efb@github.com>
 <3LbG7L0omjTTXfYRPN2GoKQfnyxHquumNGy_G63vKlI=.a6b6c244-af12-4ebe-8b91-224a674dbde5@github.com>
Message-ID: <2nhU3rIBr8AYy4B9ZEdj8kkBmu2McIF8amVZWoXbEo8=.f7708324-3000-45f9-93d7-5f90fdf972b1@github.com>

On Tue, 10 Dec 2024 23:22:02 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>>> There could be race condition that other caller immoderately set the flag, hence the assert may fail, 
>> 
>> Which other caller? We are asserting here in the constructor of the SHR object. Is this object visible to anyone other than the constructing thread at this point? I am not sure I understand the reason for a race here.
>> 
>> It's possible I am missing something in the lifecycle of the SHR object here.
>> 
>> If so, it would be good to add a brief comment on why this needs to occur here despite the constructor for the `_recycling` flag which should have been called by this point, so it should already be unset by now.
>> 
>>> notice similar race condition in test, that is why the double check for is_trash() was added.
>> 
>> Yes, I understood that race, which is between multiple threads potentially racing to recycle a trashed region, and resolves such a race in favor of the thread that manages to CAS  true into `_recycling` with interlocking checks for its `trash`ness.
>
>> Which other caller? 
> 
> Sorry for the confusion, not the caller of this specific method.
> 
> I meant to say the the mutator thread, mutator may call try_recycle_trashed here https://github.com/openjdk/jdk/blob/master/src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp#L1005 under heap-lock, we have removed the heap-lock from GC concurrent cleanup, therefore it becomes race condition between mutator and GC threads.

OK, that's what I meant. I didn't think the region would be visible to any other thread in the time that the constructor is being executed (which, my guess was, would be when the ShenandoahHeap is first initialized -- before any mutators exist that can access the heap), but I may be missing something here in the lifecycle of a region. Thanks for pointing out the possibility of a race (but that makes me wonder about other things that may go wrong if there were such a race.) I'll think more about this later.

In any case, what I was pointing out (based on my mental model) was not a correctness issue, so I'll go away and try and understand the race you mention.

No change is needed here. It's good as is, and my review approval stands. Thanks Xiaolong!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22538#discussion_r1880574386

From xpeng at openjdk.org  Wed Dec 11 18:37:20 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 11 Dec 2024 18:37:20 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v9]
In-Reply-To: <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
Message-ID: <uWqkQW8BDumMXQ7dQ4xgTnp61qqkEIUq4zdl59lW4H0=.17ba3826-9943-482f-b257-969df12e6377@github.com>

On Tue, 10 Dec 2024 19:55:20 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> For the same test test, but with large heap with 32G memory, the improvement on concurrent cleanup is much smaller, which might be related t...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Thanks all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22538#issuecomment-2536824758

From duke at openjdk.org  Wed Dec 11 18:37:20 2024
From: duke at openjdk.org (duke)
Date: Wed, 11 Dec 2024 18:37:20 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup [v9]
In-Reply-To: <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
 <0lQjdkCZMaEzHYRRr544yx3kxkG6GLniucGZWFDW2-E=.2326ebc9-c64d-4d1f-a1d9-8c7f4a76cd6a@github.com>
Message-ID: <rYjc7_i4GjW5UKwcqHXw06zEtm_6eB6jynxdblaUQbI=.a9953b65-cc7d-4ba5-9954-baabb13d96ba@github.com>

On Tue, 10 Dec 2024 19:55:20 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
>> 
>> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
>> 
>> TIP:
>> 
>> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
>> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
>> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
>> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
>> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
>> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
>> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
>> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
>> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
>> 
>> Parallelized:
>> 
>> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
>> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
>> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
>> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
>> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
>> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
>> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
>> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
>> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
>> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
>> 
>> 
>> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
>> 
>> 
>> For the same test test, but with large heap with 32G memory, the improvement on concurrent cleanup is much smaller, which might be related t...
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

@pengxiaolong 
Your change (at version 1bce0d7e212bb3b1468c3455043226c2d37ddd7f) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22538#issuecomment-2536826985

From wkemper at openjdk.org  Wed Dec 11 18:56:12 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Dec 2024 18:56:12 GMT
Subject: RFR: 8342214: GenShen: Reduce code duplication in shFreeSet with
 iterator abstraction
Message-ID: <yQI8pxVwohIIciM0Bh-Qu1ec37I5KGeZCr146KESb0A=.4c5cac74-f978-4e7b-9a39-aa8c2253b371@github.com>

These were almost all clean. All pipeline tests have passed.

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

Commit messages:
 - 8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational
 - 8344985: GenShen: Refactor arraycopy barrier for generational mode
 - 8344797: GenShen: Update and rename confusing method
 - 8344779: GenShen: Consolidate shared heap region closures into one header
 - 8344670: GenShen: Use concurrent worker session for concurrent mark phase
 - 8344640: GenShen: Reuse existing card mark barrier function when dropping references
 - 8344638: GenShen: Verifier should not touch claim token
 - 8344592: GenShen: Remove unnecessary comments and changes
 - 8344321: GenShen: Fix various sonar scan warnings
 - 8344320: GenShen: Possible null pointer usage in shGenerationalHeap
 - ... and 15 more: https://git.openjdk.org/shenandoah-jdk21u/compare/842a0d8b...1aed2ff5

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/143/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342214
  Stats: 950 lines in 59 files changed: 315 ins; 360 del; 275 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/143.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/143/head:pull/143

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

From wkemper at openjdk.org  Wed Dec 11 18:57:12 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Dec 2024 18:57:12 GMT
Subject: RFR: 8346008: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <KlNjQciLX6t___EWH9xyUdgTSSzsuoKlCj6tXL8jtsY=.2cfe8e46-d914-4bcf-927b-65cdfb40f5b6@github.com>
References: <KlNjQciLX6t___EWH9xyUdgTSSzsuoKlCj6tXL8jtsY=.2cfe8e46-d914-4bcf-927b-65cdfb40f5b6@github.com>
Message-ID: <5OBJ0O7NFOKqlh0W1fjfLX_XKXfe3Bdy8ytUncM6iKo=.4877c6aa-4b1a-4448-9954-e6cc5c69ed1d@github.com>

On Wed, 11 Dec 2024 16:10:06 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8346008](https://bugs.openjdk.org/browse/JDK-8346008). It's a follow-up from [8345647](https://bugs.openjdk.org/browse/JDK-8345647) with some cases I missed. 
> 
> Thanks, 
> Sonia

Thank you - looks good to me!

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22684#pullrequestreview-2496572142

From wkemper at openjdk.org  Wed Dec 11 19:50:28 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Dec 2024 19:50:28 GMT
Subject: RFR: 8344049: Shenandoah: Eliminate init-update-refs safepoint
Message-ID: <6ZVLoWPco9LC3XZOturDKG9F42n20Ie4h61f5Ap5iIY=.bbeb52d3-3de0-4778-b504-a69dc6ef7d3b@github.com>

Shenandoah typically takes 4 safepoints per GC cycle. Although Shenandoah itself does not spend much time on these safepoints, it may still take quite some time for all of the mutator threads to reach the safepoint. The occasionally long time-to-safepoint increases latency in the higher percentiles.

The `init-update-refs` safepoint is responsible for retiring GCLABs (and PLABs) used during evacuation. Once evacuation is complete, no threads will access these LABs. This need not be done on a safepoint. `init-update-refs` is also where the global and thread local copies of the `gc_state` are updated. However, here we are turning off the `WEAK_ROOTS` flag _after_ all of the unmarked weak referents have been `nulled` out, so this does not need to happen atomically with respect to the mutators. Neither is it necessary to change the other state flags (EVACUATION, UPDATE_REFS) atomically across all mutators.

Note that the `init-update-refs` safepoint is still taken if either verification or `ShenandoahPacing` are enabled.

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

Commit messages:
 - Fix comments
 - Fix comment, revert unnecessary change
 - Merge remote-tracking branch 'jdk/master' into remove-init-update-refs-safepoint
 - Fix phase encoding to handle weak roots
 - WIP: Use Threads::threads_do for propagating gc state (consolidated)
 - WIP: Use Threads::threads_do for propagating gc state
 - Remove unnecessary gc state propagations
 - Encapsulate gc state
 - Revert unnecessary changes
 - Merge tag 'jdk-25+1' into two-steps-backward
 - ... and 20 more: https://git.openjdk.org/jdk/compare/c6317191...9aaef708

Changes: https://git.openjdk.org/jdk/pull/22688/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22688&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344049
  Stats: 232 lines in 11 files changed: 125 ins; 70 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/22688.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22688/head:pull/22688

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

From ysr at openjdk.org  Wed Dec 11 20:04:10 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 11 Dec 2024 20:04:10 GMT
Subject: RFR: 8342214: GenShen: Reduce code duplication in shFreeSet with
 iterator abstraction
In-Reply-To: <yQI8pxVwohIIciM0Bh-Qu1ec37I5KGeZCr146KESb0A=.4c5cac74-f978-4e7b-9a39-aa8c2253b371@github.com>
References: <yQI8pxVwohIIciM0Bh-Qu1ec37I5KGeZCr146KESb0A=.4c5cac74-f978-4e7b-9a39-aa8c2253b371@github.com>
Message-ID: <bb3umNkDiaLw98VMFF4mWGdHNxfFOG1wETos-Wown90=.4b9fd32e-6236-4b8d-937d-12d516ed8474@github.com>

On Wed, 11 Dec 2024 18:48:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> These were almost all clean. All pipeline tests have passed.

LGTM based on a cursory glance at the changes, the correctness of the testing, and the clean-ness of the backports.

I did a cursory check and it looks good. As regards:

> Issue is already resolved. Consider making this a "backport pull request" by setting the PR title to Backport <hash> with the hash of the original commit.

May be check if that works better and quiets the complaints of the robot overlords? I am guessing `\backport` takes only a single parameter, and multiple `\backport`s can't be composed/nested.

Not sure what the right process is that is recommended here. May be @shipilev has a suggestion?

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/143#pullrequestreview-2496718939
PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/143#issuecomment-2536991385

From wkemper at openjdk.org  Wed Dec 11 22:32:02 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Dec 2024 22:32:02 GMT
Subject: Integrated: 8346044: GenShen: ShenandoahGenerationalHeap entry missing
 from Universe.java
Message-ID: <m8IU2vWnv-zS7NWqnbpj4tugrRTeiiPOFmIh_QtYzE4=.eed71d15-f5b2-44e8-97da-fa56b75ed6df@github.com>

Looks the genshen backport/merge missed this one.

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

Commit messages:
 - Add shenandoah generational heap to type DB

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

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

From ysr at openjdk.org  Wed Dec 11 22:32:03 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 11 Dec 2024 22:32:03 GMT
Subject: Integrated: 8346044: GenShen: ShenandoahGenerationalHeap entry
 missing from Universe.java
In-Reply-To: <m8IU2vWnv-zS7NWqnbpj4tugrRTeiiPOFmIh_QtYzE4=.eed71d15-f5b2-44e8-97da-fa56b75ed6df@github.com>
References: <m8IU2vWnv-zS7NWqnbpj4tugrRTeiiPOFmIh_QtYzE4=.eed71d15-f5b2-44e8-97da-fa56b75ed6df@github.com>
Message-ID: <tKiko6WCqfDkVzN7c6RAoxLJUFQPfGGLub10xFfakLc=.866642be-9aaf-4bf4-906f-caadafad3d65@github.com>

On Wed, 11 Dec 2024 22:06:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Looks the genshen backport/merge missed this one.

Marked as reviewed by ysr (Committer).

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/144#pullrequestreview-2497125644
PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/144#pullrequestreview-2497129460

From wkemper at openjdk.org  Wed Dec 11 22:32:03 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Dec 2024 22:32:03 GMT
Subject: Integrated: 8346044: GenShen: ShenandoahGenerationalHeap entry missing
 from Universe.java
In-Reply-To: <m8IU2vWnv-zS7NWqnbpj4tugrRTeiiPOFmIh_QtYzE4=.eed71d15-f5b2-44e8-97da-fa56b75ed6df@github.com>
References: <m8IU2vWnv-zS7NWqnbpj4tugrRTeiiPOFmIh_QtYzE4=.eed71d15-f5b2-44e8-97da-fa56b75ed6df@github.com>
Message-ID: <qpiqavRo5fCxftDekp1VWiHP6_Oi1snJH3yE9lqpquQ=.023ca58d-1ba1-4451-b1a1-820650e890f8@github.com>

On Wed, 11 Dec 2024 22:06:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Looks the genshen backport/merge missed this one.

This pull request has now been integrated.

Changeset: 562224ca
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/562224ca5925bcf54b517cd5144722944066aa76
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8346044: GenShen: ShenandoahGenerationalHeap entry missing from Universe.java

Reviewed-by: ysr

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

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

From wkemper at openjdk.org  Wed Dec 11 22:36:14 2024
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 11 Dec 2024 22:36:14 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests
Message-ID: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>

I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.

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

Commit messages:
 - Do not get cpu time for threads that have terminated

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

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

From xpeng at openjdk.org  Thu Dec 12 01:11:53 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 12 Dec 2024 01:11:53 GMT
Subject: Integrated: 8345423: Shenandoah: Parallelize concurrent cleanup
In-Reply-To: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
References: <f1KbYLWXx_U_JNrwfSesgVTUdNe2NghfueHqLswqps4=.a8027cad-8434-4253-8696-218b562f9a84@github.com>
Message-ID: <BPoE2wPkS-DC0cjnbn-l4RQ9XzTSWIK6iK_6GnZ0MWg=.34e6077e-fa38-4623-8a49-aad93252a71f@github.com>

On Wed, 4 Dec 2024 08:25:40 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Concurrent cleanup after Shenandoah collection cycle is executed by single thread(Shenandoah control thread), since currently recycling trashed regions requires heap lock even it can be done w/o heap lock. This PR is a proposal to parallelize the execution of Shenandoah concurrent cleanup after making recycling trashed regions lock free. 
> 
> With the change the time execute Concurrent cleanup has been significantly improved by 10+ times, throughput/allocation rate is also improved significantly:
> 
> TIP:
> 
> [30.380s][info][gc] GC(1245) Concurrent cleanup (Young) 3491M->739M(4096M) 3.634ms
> [30.404s][info][gc] GC(1246) Concurrent cleanup (Young) 3258M->377M(4096M) 2.233ms
> [30.434s][info][gc] GC(1247) Concurrent cleanup (Young) 2887M->333M(4096M) 7.958ms
> [30.464s][info][gc] GC(1248) Concurrent cleanup (Young) 3134M->472M(4096M) 6.097ms
> [30.487s][info][gc] GC(1249) Concurrent cleanup (Young) 2922M->212M(4096M) 3.072ms
> [30.519s][info][gc] GC(1250) Concurrent cleanup (Young) 3404M->549M(4096M) 3.730ms
> [30.552s][info][gc] GC(1251) Concurrent cleanup (Young) 3542M->712M(4096M) 6.118ms
> [30.579s][info][gc] GC(1252) Concurrent cleanup (Young) 3257M->373M(4096M) 5.049ms
> [30.608s][info][gc] GC(1253) Concurrent cleanup (Young) 3390M->418M(4096M) 2.779ms
> 
> Parallelized:
> 
> [30.426s][info][gc] GC(1557) Concurrent cleanup (Young) 3208M->43M(4096M) 0.177ms
> [30.510s][info][gc] GC(1560) Concurrent cleanup (Young) 2938M->161M(4096M) 0.220ms
> [30.534s][info][gc] GC(1561) Concurrent cleanup (Young) 2960M->57M(4096M) 0.164ms
> [30.564s][info][gc] GC(1562) Concurrent cleanup (Young) 3189M->106M(4096M) 0.176ms
> [30.595s][info][gc] GC(1563) Concurrent cleanup (Young) 3389M->367M(4096M) 0.247ms
> [30.625s][info][gc] GC(1564) Concurrent cleanup (Young) 3662M->628M(4096M) 0.246ms
> [30.649s][info][gc] GC(1565) Concurrent cleanup (Young) 3190M->150M(4096M) 0.172ms
> [30.678s][info][gc] GC(1566) Concurrent cleanup (Young) 3225M->69M(4096M) 0.175ms
> [30.709s][info][gc] GC(1567) Concurrent cleanup (Young) 3250M->107M(4096M) 0.179ms
> [30.765s][info][gc] GC(1570) Concurrent cleanup (Young) 2932M->211M(4096M) 0.422ms
> 
> 
> JVM args for the tests: `-Xms4G -Xmx4G -XX:+AlwaysPreTouch -XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational -XX:-ShenandoahPacing -XX:+UseTLAB -Xlog:gc`
> 
> 
> For the same test test, but with large heap with 32G memory, the improvement on concurrent cleanup is much smaller, which might be related to less race and contention with mutator threads when the heap size i...

This pull request has now been integrated.

Changeset: 4da6fd42
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4da6fd4283a13be1711e7ad948f1d05a0a9148a5
Stats:     228 lines in 13 files changed: 79 ins; 56 del; 93 mod

8345423: Shenandoah: Parallelize concurrent cleanup

Reviewed-by: ysr, kdnilsen, wkemper

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

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

From duke at openjdk.org  Thu Dec 12 02:04:08 2024
From: duke at openjdk.org (duke)
Date: Thu, 12 Dec 2024 02:04:08 GMT
Subject: Withdrawn: 8338534: GenShen: Handle alloc failure differently when
 immediate garbage is pending
In-Reply-To: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
References: <6H95t8NJ4xvUe0xClp8yZEVtaVqfpg85E1zZ9jnh0nk=.9e68ac2d-342c-4f4c-ac97-250db7592420@github.com>
Message-ID: <-XoIsRFQte6RzZr6vqiTEFHuvJNqvSfB3S5R8YHpGZI=.ac12dd40-5c15-4177-81a0-3ae590c577ac@github.com>

On Wed, 21 Aug 2024 14:48:55 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Several changes are implemented here:
> 
> 1. Re-order the phases that execute immediately after final-mark so that we do concurrent-cleanup quicker (but still after concurrent weak references)
> 2. After immediate garbage has been reclaimed by concurrent cleanup, notify waiting allocators
> 3. If an allocation failure occurs while immediate garbage recycling is pending, stall the allocation but do not cancel the concurrent gc.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah/pull/479

From ysr at openjdk.org  Thu Dec 12 02:29:35 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 12 Dec 2024 02:29:35 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests
In-Reply-To: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
Message-ID: <4R-kS9FPgXdBjB3YIz22BJjnq5WacC5bZvl1xiZDNao=.a3795c17-887f-4566-9642-ec3e709fa6db@github.com>

On Wed, 11 Dec 2024 22:32:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.

src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.cpp line 51:

> 49:   ThreadTimeAccumulator() : total_time(0) {}
> 50:   void do_thread(Thread* thread) override {
> 51:     if (!thread->has_terminated()) {

There's an inherent race here at destruction time because the target thread may be terminated between the check and the cpu time call -- thus you've narrowed the race window but not closed it.

Note that this is today called only on GC-worker-like threads (include controller & regulator & worker threads).

I agree that the crashes are likely occurring during shutdown, just as you surmised. I'd suggest looking at the constructor and destructor (enroll and disenroll) of the MMU Tracker Task, and disenroll it before the GC-workers et al. are shutdown. That would be the most surgical and cleanest fix, and closes the race.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22693#discussion_r1881283986

From ysr at openjdk.org  Thu Dec 12 02:32:34 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 12 Dec 2024 02:32:34 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests
In-Reply-To: <4R-kS9FPgXdBjB3YIz22BJjnq5WacC5bZvl1xiZDNao=.a3795c17-887f-4566-9642-ec3e709fa6db@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
 <4R-kS9FPgXdBjB3YIz22BJjnq5WacC5bZvl1xiZDNao=.a3795c17-887f-4566-9642-ec3e709fa6db@github.com>
Message-ID: <NxMPndvxcsnS4_pdIpS68Vv9QgCr7Ad_c6tImw8-nrE=.d9feb7ac-613b-4062-b5e9-36701c2d820a@github.com>

On Thu, 12 Dec 2024 02:26:17 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.
>
> src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.cpp line 51:
> 
>> 49:   ThreadTimeAccumulator() : total_time(0) {}
>> 50:   void do_thread(Thread* thread) override {
>> 51:     if (!thread->has_terminated()) {
> 
> There's an inherent race here at destruction time because the target thread may be terminated between the check and the cpu time call -- thus you've narrowed the race window but not closed it.
> 
> Note that this is today called only on GC-worker-like threads (include controller & regulator & worker threads).
> 
> I agree that the crashes are likely occurring during shutdown, just as you surmised. I'd suggest looking at the constructor and destructor (enroll and disenroll) of the MMU Tracker Task, and disenroll it before the GC-workers et al. are shutdown. That would be the most surgical and cleanest fix, and closes the race.

Right now the disenroll is done a tad late, since the task is disenrolled in the task's destructor which doesn't happen until the heap is destructed. I think at least the disenroll should be done before we start shutting down GC worker threads etc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22693#discussion_r1881289328

From stefank at openjdk.org  Thu Dec 12 13:51:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 12 Dec 2024 13:51:54 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
Message-ID: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>

The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.

See the first comment for the full description:

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

Commit messages:
 - 8345655: Move reservation code out of ReservedSpace

Changes: https://git.openjdk.org/jdk/pull/22712/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22712&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345655
  Stats: 2107 lines in 59 files changed: 1182 ins; 806 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/22712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22712/head:pull/22712

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

From stefank at openjdk.org  Thu Dec 12 13:51:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 12 Dec 2024 13:51:54 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <PyVpptUQ7h-jDOalpYvXbGOFsNtu1n9fdu7TOpTn0Cc=.277baa16-ef60-464b-823a-ad4a4ee9725e@github.com>

On Thu, 12 Dec 2024 13:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

The dual functionality of `ReservedSpace` makes the code hard to read and it is hard to see / realize that the constructors reserve memory. However, this is not the only reason to try to take a step back and clean up `ReservedSpace`. So while doing a restructure here I also want to clean up things like:

1) Move the `_noaccess_prefix` and related code out from `ReservedSpace` into `ReservedHeapSpace`.
2) Move `_fd_for_heap` out out of `ReservedSpace`.
3) Clearer requirements and asserts w.r.t. the input arguments size, alignment, and page_size. 
4) ... and some more along the way while creating the patch. See the items below.

When reviewing this I would suggest that you compare the old code in virtualspace.cpp with the code in reservedSpace.cpp.

A guide to changes in the diff:

a) Whether memory reservation is for executable memory is confined to a limited number of places: The top-level memory reservation function and the function that reserves code. There's no need for other reservation places to pass in !ExecMem (or false), that is hidden from most callers.

b) The old code had shared helpers to handled the case when we map anonymous memory and the case when we mapped the heap to a file. I separated the two paths. This adds a small amount of code duplication, but IMHO it makes the code easier to read and it removes a bunch of dispatch if-statements in the lower level functions.

c) When starting with this patch I wanted to cleanup so that it would be slightly cleaner to pass down NMT MemTags, but I backed off because we need to make a couple of changes and fixes to NMT and CDS before that will be possible. Therefore you can see places where we don't pass down MemTags and you can see `mtNone` default values. My intention for this patch is to try to not change any of the places where NMT is called. Hopefully, we can get rid of the `mtNone` in the time frame of JDK 25.

d) G1 and Shenandoah used to call one `ReservedSpace` constructor that also changed the size of the requested memory. I've removed that convenience and let the GC fix the parameters themselves before calling the code that reserves memory. This allows us to have stricter argument validation checks. It also makes the reservation functions that we have left more consistent and therefore easier to understand also to call the right function.

e) As a future change, I would like to remove the memory reservation overload that helps the caller guess if they want large pages or not. There's a lot of confusion around that functionality, and I would prefer to let the callers that want to set up explicit large pages make that request explicitly instead. In fact, if you check the code today you could find a place where the GC code says that it doesn't want large pages, but if you follow the code you see that it still gets it. For now I have left this "capability" as-is.

f) I removed `MemRegion* ReservedSpace::region()`, since `HeapWords*` are so tied to the GC / Heap. An alternative could have been to move it to `ReservedHeapSpace`, but I don't think it is worth keeping that function.

g) You will see a few changes to the include files as a result of code moving.

h) I've stopped allowing 0 as an alignment argument. The required minimum alignment is `os::vm_allocation_granularity()`. Note, that we still have an overload for those who don't want to care about the alignment. That functions uses `os::vm_allocation_granularity()` under the hood. This allows for stricter checks and removes the code that changed alignment inside the reservation code.

i) `ReservedSpace::release()` used to clear the members of the `Reservedspace` instance. Since I have decoupled reserving/releasing from `ReservedSpace`. Code that want's to clear the `ReservedSpace` will do it explicitly.

j) I've somewhat restructured the compressed heap space reservation code. The previous code used its instance variables to keep track of previous attempts and didn't release failed reservation memory until the next attempt to reserve memory. I've moved the code to release the memory to be explicit instead. The code that reserves memory is now responsible to check if the returned `ReservedSpace` is good enough to use. Instead of repeatedly changing the instance members of `ReservedHeapSpace`, I let the code keep track of a local `ReservedSpace` that contain the latest reservation attempt. When all memory reservation attempts are done a noaccess prefix is created if needed and a `ResevedHeapSpace` is created and returned.

I've tested this by running the full tier1-7

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

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2539001078

From wkemper at openjdk.org  Thu Dec 12 17:30:40 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Dec 2024 17:30:40 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests
In-Reply-To: <NxMPndvxcsnS4_pdIpS68Vv9QgCr7Ad_c6tImw8-nrE=.d9feb7ac-613b-4062-b5e9-36701c2d820a@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
 <4R-kS9FPgXdBjB3YIz22BJjnq5WacC5bZvl1xiZDNao=.a3795c17-887f-4566-9642-ec3e709fa6db@github.com>
 <NxMPndvxcsnS4_pdIpS68Vv9QgCr7Ad_c6tImw8-nrE=.d9feb7ac-613b-4062-b5e9-36701c2d820a@github.com>
Message-ID: <JCd9AzKkSeNRb1_74n9XsMn946wGU348xVZKzAHenVM=.31b83a1d-cb0a-4ec7-8735-4d1d3780538d@github.com>

On Thu, 12 Dec 2024 02:30:21 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.cpp line 51:
>> 
>>> 49:   ThreadTimeAccumulator() : total_time(0) {}
>>> 50:   void do_thread(Thread* thread) override {
>>> 51:     if (!thread->has_terminated()) {
>> 
>> There's an inherent race here at destruction time because the target thread may be terminated between the check and the cpu time call -- thus you've narrowed the race window but not closed it.
>> 
>> Note that this is today called only on GC-worker-like threads (include controller & regulator & worker threads).
>> 
>> I agree that the crashes are likely occurring during shutdown, just as you surmised. I'd suggest looking at the constructor and destructor (enroll and disenroll) of the MMU Tracker Task, and disenroll it before the GC-workers et al. are shutdown. That would be the most surgical and cleanest fix, and closes the race.
>
> Right now the disenroll is done a tad late, since the task is disenrolled in the task's destructor which doesn't happen until the heap is destructed. I think at least the disenroll should be done before we start shutting down GC worker threads etc.

Good catch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22693#discussion_r1882595612

From wkemper at openjdk.org  Thu Dec 12 17:41:51 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Dec 2024 17:41:51 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v2]
In-Reply-To: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
Message-ID: <joNUEVvSnK1xW8rZKT0lFlhKeE-4fnO2-mre0pr30r0=.0b829629-4beb-4e84-84ce-7340c69bce32@github.com>

> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.

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

  Stop periodic mmu task before stopping GC threads

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22693/files
  - new: https://git.openjdk.org/jdk/pull/22693/files/c3b93aec..e99aaa5f

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

  Stats: 16 lines in 3 files changed: 13 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22693.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22693/head:pull/22693

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

From szaldana at openjdk.org  Thu Dec 12 18:17:40 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Thu, 12 Dec 2024 18:17:40 GMT
Subject: Integrated: 8346008: Fix recent NULL usage backsliding in Shenandoah
In-Reply-To: <KlNjQciLX6t___EWH9xyUdgTSSzsuoKlCj6tXL8jtsY=.2cfe8e46-d914-4bcf-927b-65cdfb40f5b6@github.com>
References: <KlNjQciLX6t___EWH9xyUdgTSSzsuoKlCj6tXL8jtsY=.2cfe8e46-d914-4bcf-927b-65cdfb40f5b6@github.com>
Message-ID: <vP0TKXCoRMv9p-xjdagItapVaY23rMPCQxksGjFzFFA=.7b909178-5074-4efd-8506-b9d8b5b9e276@github.com>

On Wed, 11 Dec 2024 16:10:06 GMT, Sonia Zaldana Calles <szaldana at openjdk.org> wrote:

> Hi all, 
> 
> This PR addresses [8346008](https://bugs.openjdk.org/browse/JDK-8346008). It's a follow-up from [8345647](https://bugs.openjdk.org/browse/JDK-8345647) with some cases I missed. 
> 
> Thanks, 
> Sonia

This pull request has now been integrated.

Changeset: ff85865b
Author:    Sonia Zaldana Calles <szaldana at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ff85865b752b7a2e765e2035d372a4dbb9279fea
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8346008: Fix recent NULL usage backsliding in Shenandoah

Reviewed-by: kbarrett, wkemper

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

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

From duke at openjdk.org  Thu Dec 12 18:52:09 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 12 Dec 2024 18:52:09 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
Message-ID: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>

[JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)

Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

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

Commit messages:
 - Fix whitespace
 - Add compile time check for ldr/str

Changes: https://git.openjdk.org/jdk/pull/22623/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22623&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344880
  Stats: 345 lines in 24 files changed: 32 ins; 1 del; 312 mod
  Patch: https://git.openjdk.org/jdk/pull/22623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22623/head:pull/22623

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

From aph at openjdk.org  Thu Dec 12 18:52:09 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 12 Dec 2024 18:52:09 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
Message-ID: <l1_kxwJTQc2Kt7WqmxEOD7oI6awLtRCHNprZ65TOMmA=.d0d6ddf5-ae87-461c-95b2-7fa6e58ab104@github.com>

On Fri, 6 Dec 2024 23:57:41 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)
> 
> Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

Perhaps I'm missing something here, but isn't the main problem immediate offsets that are not constant when HotSpot itself is compiled by a C++ compiler? Or is your intention to find all the uses of offsetted immediate that are non-constant?

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

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2535455202

From duke at openjdk.org  Thu Dec 12 18:52:09 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Thu, 12 Dec 2024 18:52:09 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
Message-ID: <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>

On Fri, 6 Dec 2024 23:57:41 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)
> 
> Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

I think all immediate offsets should be safe (constant or non-constant) and this addresses the constants.

You're correct the non-constants are the main problem. As for those [JDK-8342736](https://bugs.openjdk.org/browse/JDK-8342736) can be to go through remaining instructions and update. My opinion is that providing a temp register should be required for all non-constant in the event of an overflow. This will guarantee the size always gets checked. Compile when possible and runtime if not.

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

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2539768611

From stuefe at openjdk.org  Thu Dec 12 19:54:43 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 12 Dec 2024 19:54:43 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
Message-ID: <tZYSTEcJTgBwpkZDwaTjGK1FEjujk1c8ZInrKF7GQ70=.9a3e8920-4a29-4875-a860-e85e82bcc2a6@github.com>

On Fri, 6 Dec 2024 23:57:41 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)
> 
> Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

Some drive-by comments. Using sizeof class is a smart workaround that is fine as long as we don't use `create_imm_offset`  to check offsets that are beyond sizeof its class. E.g. things like InstanceKlass::start_of_itable().

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 675:

> 673:   }
> 674: 
> 675:   #define create_imm_offset(klass, field_offset_func) \

I would avoid "klass" as name, since it is usually implied to mean an object of class `Klass`.

src/hotspot/cpu/aarch64/assembler_aarch64.hpp line 680:

> 678:     static_assert(Address::offset_ok_for_immed_compile_time<max_possible_offset, 0>(), "must fit in instruction"); \
> 679:     return klass::field_offset_func(); \
> 680:   }())

This could be done without a Lambda, which subjectively would be a bit simpler, by using the comma operator like this:


  template <class K> static void class_size_check() {
    constexpr size_t max_possible_offset = sizeof(K); \
    static_assert(Address::offset_ok_for_immed_compile_time<max_possible_offset, 0>(), "must fit in instruction"); \
  }
  #define create_imm_offset(klass, field_offset_func) \
    (Address::class_size_check<klass>(), klass::field_offset_func())

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

PR Review: https://git.openjdk.org/jdk/pull/22623#pullrequestreview-2500588169
PR Review Comment: https://git.openjdk.org/jdk/pull/22623#discussion_r1882758934
PR Review Comment: https://git.openjdk.org/jdk/pull/22623#discussion_r1882778201

From wkemper at openjdk.org  Thu Dec 12 23:19:13 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Dec 2024 23:19:13 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v3]
In-Reply-To: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
Message-ID: <_0Lmlae5oSCw1kiPVaXIUF090ldn6P4GohQr9XWlF9s=.81d00eb2-6296-41c2-a77f-21b18f8ba3c1@github.com>

> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.

William Kemper has updated the pull request incrementally with two additional commits since the last revision:

 - Stop regulator thread after control thread
 - Revert unnecessary change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22693/files
  - new: https://git.openjdk.org/jdk/pull/22693/files/e99aaa5f..6b2f74e5

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

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

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

From wkemper at openjdk.org  Thu Dec 12 23:42:10 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Dec 2024 23:42:10 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v4]
In-Reply-To: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
Message-ID: <Kj6k8cKS9X1eKzsAQgUR40PoiHi0ImXws8YA6VA5sJs=.6c1bdc64-b8d9-4060-a4ac-1e69638b80b8@github.com>

> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.

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

  Remove debug logging

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22693/files
  - new: https://git.openjdk.org/jdk/pull/22693/files/6b2f74e5..88bcf9ab

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

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

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

From wkemper at openjdk.org  Thu Dec 12 23:42:10 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Dec 2024 23:42:10 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v4]
In-Reply-To: <Kj6k8cKS9X1eKzsAQgUR40PoiHi0ImXws8YA6VA5sJs=.6c1bdc64-b8d9-4060-a4ac-1e69638b80b8@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
 <Kj6k8cKS9X1eKzsAQgUR40PoiHi0ImXws8YA6VA5sJs=.6c1bdc64-b8d9-4060-a4ac-1e69638b80b8@github.com>
Message-ID: <0k4EwyBsiOqaL8HK3NDFz7HjOQijRL011-_2yvvhnKs=.d707b67d-094e-4f5b-a6ea-365afd4a9c6d@github.com>

On Thu, 12 Dec 2024 23:39:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug logging

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

> 182: void ShenandoahGenerationalHeap::stop() {
> 183:   ShenandoahHeap::stop();
> 184:   regulator_thread()->stop();

This is the fix for the crash reported in https://bugs.openjdk.org/browse/JDK-8345970.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22693#discussion_r1883034809

From wkemper at openjdk.org  Thu Dec 12 23:42:10 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 12 Dec 2024 23:42:10 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v4]
In-Reply-To: <JCd9AzKkSeNRb1_74n9XsMn946wGU348xVZKzAHenVM=.31b83a1d-cb0a-4ec7-8735-4d1d3780538d@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
 <4R-kS9FPgXdBjB3YIz22BJjnq5WacC5bZvl1xiZDNao=.a3795c17-887f-4566-9642-ec3e709fa6db@github.com>
 <NxMPndvxcsnS4_pdIpS68Vv9QgCr7Ad_c6tImw8-nrE=.d9feb7ac-613b-4062-b5e9-36701c2d820a@github.com>
 <JCd9AzKkSeNRb1_74n9XsMn946wGU348xVZKzAHenVM=.31b83a1d-cb0a-4ec7-8735-4d1d3780538d@github.com>
Message-ID: <mHECZSYWqou1cTnnAlKJIUGGV1b7Jm7MNTizfrczvew=.5277c66f-3886-41e7-bde3-390ddb25a22f@github.com>

On Thu, 12 Dec 2024 17:28:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Right now the disenroll is done a tad late, since the task is disenrolled in the task's destructor which doesn't happen until the heap is destructed. I think at least the disenroll should be done before we start shutting down GC worker threads etc.
>
> Good catch!

It wasn't actually the periodic task causing the crash (though that issue has been fixed here as well). The crash was caused by the control thread trying to `ShenandoahHeap::do_gc_threads` which included the regulator thread that had already been stopped by `ShenandoahHeap::stop`. The fix here was to stop the control thread before stopping the regulator thread, thereby preventing the control thread from trying to access stopped threads.

This was fairly easy to reproduce (and verify) once I had an Alpine Linux environment set up.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22693#discussion_r1883032058

From ysr at openjdk.org  Fri Dec 13 00:00:35 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 13 Dec 2024 00:00:35 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v4]
In-Reply-To: <Kj6k8cKS9X1eKzsAQgUR40PoiHi0ImXws8YA6VA5sJs=.6c1bdc64-b8d9-4060-a4ac-1e69638b80b8@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
 <Kj6k8cKS9X1eKzsAQgUR40PoiHi0ImXws8YA6VA5sJs=.6c1bdc64-b8d9-4060-a4ac-1e69638b80b8@github.com>
Message-ID: <XmQ0BxhyoAlfisL7w8Q3GCFAwV9hYE88EqZzfx_rZw4=.2fca2286-1c21-4bf6-a2c4-a47bbca9b701@github.com>

On Thu, 12 Dec 2024 23:42:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove debug logging

Looks good; a few more comments for your consideration in tightening the downstream code perhaps? (I haven't examined it, but thought it might be worthwhile, if not in this ticket then in a follow-up separately?)

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22693#pullrequestreview-2500989938

From ysr at openjdk.org  Fri Dec 13 00:00:36 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 13 Dec 2024 00:00:36 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v4]
In-Reply-To: <mHECZSYWqou1cTnnAlKJIUGGV1b7Jm7MNTizfrczvew=.5277c66f-3886-41e7-bde3-390ddb25a22f@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
 <4R-kS9FPgXdBjB3YIz22BJjnq5WacC5bZvl1xiZDNao=.a3795c17-887f-4566-9642-ec3e709fa6db@github.com>
 <NxMPndvxcsnS4_pdIpS68Vv9QgCr7Ad_c6tImw8-nrE=.d9feb7ac-613b-4062-b5e9-36701c2d820a@github.com>
 <JCd9AzKkSeNRb1_74n9XsMn946wGU348xVZKzAHenVM=.31b83a1d-cb0a-4ec7-8735-4d1d3780538d@github.com>
 <mHECZSYWqou1cTnnAlKJIUGGV1b7Jm7MNTizfrczvew=.5277c66f-3886-41e7-bde3-390ddb25a22f@github.com>
Message-ID: <WqoK1OI-KFyxk-ZhaKyttIjALOdCeN7UKl_jSB_HECI=.67f0973c-a7bf-459a-80e6-97b308c9e69d@github.com>

On Thu, 12 Dec 2024 23:35:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Good catch!
>
> It wasn't actually the periodic task causing the crash (though that issue has been fixed here as well). The crash was caused by the control thread trying to `ShenandoahHeap::do_gc_threads` which included the regulator thread that had already been stopped by `ShenandoahHeap::stop`. The fix here was to stop the control thread before stopping the regulator thread, thereby preventing the control thread from trying to access stopped threads.
> 
> This was fairly easy to reproduce (and verify) once I had an Alpine Linux environment set up.

In light of the new findings, should the `if` test be converted now into an `assert` of some sort about the threads not having been terminated during any test (I know the assert is still "racy" -- it doesn't cover the entire window -- but sound to call here. Also wondering if the original when run with a fastdebug build may have asserted down in the `os::` method because of finding a null `osthread`? Should the `os::` methods assert on non-nullness of associated `osthread`? Worth checking now that you have an AlpineLinux box to test on?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22693#discussion_r1883044632

From wkemper at openjdk.org  Fri Dec 13 00:26:55 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 00:26:55 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v5]
In-Reply-To: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
Message-ID: <tc1SnvuvSkDIlREHX66vbx6mQEkJY6TRFibhYhlfADw=.e4af7435-c115-475a-9e3b-2099b630826e@github.com>

> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.

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

  Turn test into assert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22693/files
  - new: https://git.openjdk.org/jdk/pull/22693/files/88bcf9ab..0e3d0a86

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

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

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

From wkemper at openjdk.org  Fri Dec 13 00:30:40 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 00:30:40 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v5]
In-Reply-To: <WqoK1OI-KFyxk-ZhaKyttIjALOdCeN7UKl_jSB_HECI=.67f0973c-a7bf-459a-80e6-97b308c9e69d@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
 <4R-kS9FPgXdBjB3YIz22BJjnq5WacC5bZvl1xiZDNao=.a3795c17-887f-4566-9642-ec3e709fa6db@github.com>
 <NxMPndvxcsnS4_pdIpS68Vv9QgCr7Ad_c6tImw8-nrE=.d9feb7ac-613b-4062-b5e9-36701c2d820a@github.com>
 <JCd9AzKkSeNRb1_74n9XsMn946wGU348xVZKzAHenVM=.31b83a1d-cb0a-4ec7-8735-4d1d3780538d@github.com>
 <mHECZSYWqou1cTnnAlKJIUGGV1b7Jm7MNTizfrczvew=.5277c66f-3886-41e7-bde3-390ddb25a22f@github.com>
 <WqoK1OI-KFyxk-ZhaKyttIjALOdCeN7UKl_jSB_HECI=.67f0973c-a7bf-459a-80e6-97b308c9e69d@github.com>
Message-ID: <Uaod_0CcsWS3MzXE7Z9Vjl7_ltNSLpemreZNtU8oxjY=.cae6a7be-aa19-46cc-8e11-a7eaed72da36@github.com>

On Thu, 12 Dec 2024 23:51:52 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> It wasn't actually the periodic task causing the crash (though that issue has been fixed here as well). The crash was caused by the control thread trying to `ShenandoahHeap::do_gc_threads` which included the regulator thread that had already been stopped by `ShenandoahHeap::stop`. The fix here was to stop the control thread before stopping the regulator thread, thereby preventing the control thread from trying to access stopped threads.
>> 
>> This was fairly easy to reproduce (and verify) once I had an Alpine Linux environment set up.
>
> In light of the new findings, should the `if` test be converted now into an `assert` of some sort about the threads not having been terminated during any test (I know the assert is still "racy" -- it doesn't cover the entire window -- but sound to call here. Also wondering if the original when run with a fastdebug build may have asserted down in the `os::` method because of finding a null `osthread`? Should the `os::` methods assert on non-nullness of associated `osthread`? Worth checking now that you have an AlpineLinux box to test on?)

I don't think we can readily test the validity of the `osthread's`  native thread handle. I'm sure it _could_ be done, but it's platform specific. In this case, for example, the [glibc version](https://github.com/lattera/glibc/blob/master/nptl/pthread_getcpuclockid.c) of `pthread_getcpuclockid` returns an error code if the handle is `INVALID_TD_P`. The [musl version](https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_getcpuclockid.c) (used for Alpine Linux), on the other hand, has no such check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22693#discussion_r1883069731

From ysr at openjdk.org  Fri Dec 13 01:41:40 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 13 Dec 2024 01:41:40 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v5]
In-Reply-To: <tc1SnvuvSkDIlREHX66vbx6mQEkJY6TRFibhYhlfADw=.e4af7435-c115-475a-9e3b-2099b630826e@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
 <tc1SnvuvSkDIlREHX66vbx6mQEkJY6TRFibhYhlfADw=.e4af7435-c115-475a-9e3b-2099b630826e@github.com>
Message-ID: <O9BTVtc6YwU7YwW7CrW__ACzHXkMHk_t8CFLCg-zWOg=.a1f5df12-e01a-4360-aa9c-c52a2580a13e@github.com>

On Fri, 13 Dec 2024 00:26:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Turn test into assert

? ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22693#pullrequestreview-2501082206

From aph at openjdk.org  Fri Dec 13 10:27:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 13 Dec 2024 10:27:39 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
 <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>
Message-ID: <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>

On Thu, 12 Dec 2024 18:47:53 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> I think all immediate offsets should be safe (constant or non-constant) and this addresses the constants.

We should not do this. In the overwhelming majority of cases a maintainer does not (and should not have to) care whether an address will fit in an immediate or not. It is purely an encoding issue, not a semantic one, and should be handled internally by the assembler.

If instead of this PR we were to use some variant of `form_address()` on register+offset addresses, we wouldn't need to care about whether the offsets were compile-time constants or not, we wouldn't need this extra code, and  the result would be easier to read and maintain.

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

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2541107157

From aph at openjdk.org  Fri Dec 13 12:06:40 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 13 Dec 2024 12:06:40 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
 <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>
 <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>
Message-ID: <sxk7vgsL2MGEuZdkGiCEDuzDbI1PlIva1AyfKgDY8yo=.1cd85be4-482d-407b-9a64-72dcae32352a@github.com>

On Fri, 13 Dec 2024 10:24:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> If instead of this PR we were to use some variant of `form_address()` on register+offset addresses, we wouldn't need to care about whether the offsets were compile-time constants or not, we wouldn't need this extra code, and the result would be easier to read and maintain.

e.g. a new `Address` constructor that takes an extra register and (optionally) an operand size.

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

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2541299635

From jsjolen at openjdk.org  Fri Dec 13 12:50:37 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 13 Dec 2024 12:50:37 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>

On Thu, 12 Dec 2024 13:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

src/hotspot/share/memory/memoryReserver.cpp line 238:

> 236: }
> 237: 
> 238: bool MemoryReserver::release(const ReservedSpace& reserved) {

Should `release(release(R)) == release(R)` and should `release(R& r)` do `r = {}`? Then `release({})` is no-op.

In other words, instead of this:

```c++
if (rs.is_reserved()) {
  MemoryReserver::release(rs);
  rs = {};
}


we can have

```c++
MemoryReserver::release(rs);


which to me seems like a good simplification when using the API.

src/hotspot/share/memory/reservedSpace.hpp line 137:

> 135: };
> 136: 
> 137: // Class encapsulating behavior specific of memory space reserved for Java heap.

"of the", "for the"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883745379
PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883865400

From jsjolen at openjdk.org  Fri Dec 13 12:50:37 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 13 Dec 2024 12:50:37 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
Message-ID: <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>

On Fri, 13 Dec 2024 10:51:16 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> src/hotspot/share/memory/memoryReserver.cpp line 238:
> 
>> 236: }
>> 237: 
>> 238: bool MemoryReserver::release(const ReservedSpace& reserved) {
> 
> Should `release(release(R)) == release(R)` and should `release(R& r)` do `r = {}`? Then `release({})` is no-op.
> 
> In other words, instead of this:
> 
> ```c++
> if (rs.is_reserved()) {
>   MemoryReserver::release(rs);
>   rs = {};
> }
> 
> 
> we can have
> 
> ```c++
> MemoryReserver::release(rs);
> 
> 
> which to me seems like a good simplification when using the API.

It seems like you've explicitly decided against this in the new API, is there a particular reason for that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883886748

From stefank at openjdk.org  Fri Dec 13 13:13:36 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Dec 2024 13:13:36 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
 <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>
Message-ID: <7vWI962XXDBJPgStyp0eEYuMf0IWqe44gSQiLSkO6n8=.d9ec7e5a-0031-4999-acff-8ee2bfb94059@github.com>

On Fri, 13 Dec 2024 12:45:28 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/memory/memoryReserver.cpp line 238:
>> 
>>> 236: }
>>> 237: 
>>> 238: bool MemoryReserver::release(const ReservedSpace& reserved) {
>> 
>> Should `release(release(R)) == release(R)` and should `release(R& r)` do `r = {}`? Then `release({})` is no-op.
>> 
>> In other words, instead of this:
>> 
>> ```c++
>> if (rs.is_reserved()) {
>>   MemoryReserver::release(rs);
>>   rs = {};
>> }
>> 
>> 
>> we can have
>> 
>> ```c++
>> MemoryReserver::release(rs);
>> 
>> 
>> which to me seems like a good simplification when using the API.
>
> It seems like you've explicitly decided against this in the new API, is there a particular reason for that?

My reasoning was that MemoryReserver does not have the ownership of the ReservedSpace instance, so I didn't want it to be the one clearing the members. If others feel the same way as you do, then I would prefer to add a function release_and_clear to make it clearer (:)) what's going on.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883916256

From stefank at openjdk.org  Fri Dec 13 13:23:14 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 13 Dec 2024 13:23:14 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v2]
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <kp5cKHqFUADE4Rl3cttLj2ddw8FgwU_iFNEg14LPK48=.939c65d7-2c73-438b-9460-12e182a93682@github.com>

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge remote-tracking branch 'upstream/master' into reserved_space_rewrite
 - Fix comment
 - 8345655: Move reservation code out of ReservedSpace

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

Changes: https://git.openjdk.org/jdk/pull/22712/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22712&range=01
  Stats: 2107 lines in 59 files changed: 1182 ins; 806 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/22712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22712/head:pull/22712

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

From jsjolen at openjdk.org  Fri Dec 13 13:38:40 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 13 Dec 2024 13:38:40 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v2]
In-Reply-To: <7vWI962XXDBJPgStyp0eEYuMf0IWqe44gSQiLSkO6n8=.d9ec7e5a-0031-4999-acff-8ee2bfb94059@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
 <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>
 <7vWI962XXDBJPgStyp0eEYuMf0IWqe44gSQiLSkO6n8=.d9ec7e5a-0031-4999-acff-8ee2bfb94059@github.com>
Message-ID: <0DIQXJDLaUvtZOhwOROXFP4YPhDIfTEJZ1v7ib-_6_s=.3c84c791-d338-4e18-a4ba-a7f0a2b984e2@github.com>

On Fri, 13 Dec 2024 13:10:38 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> It seems like you've explicitly decided against this in the new API, is there a particular reason for that?
>
> My reasoning was that MemoryReserver does not have the ownership of the ReservedSpace instance, so I didn't want it to be the one clearing the members. If others feel the same way as you do, then I would prefer to add a function release_and_clear to make it clearer (:)) what's going on.

`release_and_clear`does sound clearer :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1883947587

From aph at openjdk.org  Fri Dec 13 15:32:39 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 13 Dec 2024 15:32:39 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
Message-ID: <ZJKxX1cjMX7aZTne9bSNOHNDgn93wGdUHtOze18VSLs=.ee4d5fa7-605f-4311-af3f-4aaf7bc27fde@github.com>

On Fri, 6 Dec 2024 23:57:41 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8344880](https://bugs.openjdk.org/browse/JDK-8344880)
> 
> Adds compile time checks for str/ldr instructions to verify that the immediate offset will fit. This adds static_assert for constant offsets that are checked at compile time. The macro offset_of is not constexpr so instead the class size is checked. If the size of a class fits into a memory instructions then any offset in it will fit.

We could instead add a few static_asserts that the size of a native structure which is accessed by the runtime code (there are not many of these, and we know what they are) is less than an `ldr`/`str` will reach. It's a simple-enough thing to do, and such a change has a much smaller blast radius than this PR would have.
It really would be useful to make sure we can generate correct code for variable-sized field offsets, as is the case for Java statics at some offset from the Klass base. C2 is already fine, C1 might need a few more calls to `form_address()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2541704444

From wkemper at openjdk.org  Fri Dec 13 17:44:59 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 17:44:59 GMT
Subject: Integrated: 8345970: pthread_getcpuclockid related crashes in
 shenandoah tests
In-Reply-To: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
References: <1y0l9ZPDQ_8jXY7DBgOfTuxd5tPIIZZZ-ZghysBEqGM=.04c92181-0fd9-4ca8-9d55-ab0e519932bf@github.com>
Message-ID: <ZU7aO28sgmHmjWy610ZjtKjAsE819Mp1kLDDZlbWW7M=.9bb66034-747a-4e78-a11c-c2540c013c12@github.com>

On Wed, 11 Dec 2024 22:32:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I haven't seen this failure mode in our Alpine Linux test pipelines, but the suggestion to avoid getting cpu time for terminated threads sounds sensible.

This pull request has now been integrated.

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

8345970: pthread_getcpuclockid related crashes in shenandoah tests

Reviewed-by: ysr

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

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

From wkemper at openjdk.org  Fri Dec 13 17:48:21 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 17:48:21 GMT
Subject: Integrated: 8342214: GenShen: Reduce code duplication in shFreeSet
 with iterator abstraction
In-Reply-To: <yQI8pxVwohIIciM0Bh-Qu1ec37I5KGeZCr146KESb0A=.4c5cac74-f978-4e7b-9a39-aa8c2253b371@github.com>
References: <yQI8pxVwohIIciM0Bh-Qu1ec37I5KGeZCr146KESb0A=.4c5cac74-f978-4e7b-9a39-aa8c2253b371@github.com>
Message-ID: <_kFbqUStzS-awk8C9yZJkRHzJgX6JeFFtG6AJOQE1ow=.01879d80-d604-4343-ab56-082ecf8a2ec3@github.com>

On Wed, 11 Dec 2024 18:48:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> These were almost all clean. All pipeline tests have passed.

This pull request has now been integrated.

Changeset: 71c448f5
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/71c448f567a597a12675eb42935a89b05bd954d1
Stats:     950 lines in 59 files changed: 315 ins; 360 del; 275 mod

8342214: GenShen: Reduce code duplication in shFreeSet with iterator abstraction
8342255: GenShen: Remove unnecessary enum initial values
8342278: GenShen: Move non-generational mode test out of generational test configuration
8342560: GenShen: Fix confusing method name
8342564: GenShen: Only reference young/old generation names in generational mode
8342580: GenShen: TestChurnNotifications fails executing in unintended test-id modes with ShenandoahGCMode=generational
8342848: Shenandoah: Marking bitmap may not be completely cleared in generational mode
8342919: GenShen: Fix whitespace
8343227: GenShen: Fold resource mark into management of preselected regions
8344151: GenShen: Improve comments, clean up unnecessary changes
8344152: GenShen: Initialize RegionData in product builds
8344260: GenShen: Excess unaffiliated regions reserved for old will not be transferred to young
8344264: GenShen: Improve comments and method names
8344263: GenShen: Reduce extraneous log messages at INFO level
8344339: GenShen: Avoid using namespaces
8344320: GenShen: Possible null pointer usage in shGenerationalHeap
8344321: GenShen: Fix various sonar scan warnings
8344592: GenShen: Remove unnecessary comments and changes
8344638: GenShen: Verifier should not touch claim token
8344640: GenShen: Reuse existing card mark barrier function when dropping references
8344670: GenShen: Use concurrent worker session for concurrent mark phase
8344779: GenShen: Consolidate shared heap region closures into one header
8344797: GenShen: Update and rename confusing method
8344985: GenShen: Refactor arraycopy barrier for generational mode
8342734: GenShen: Test failure gc/shenandoah/TestReferenceRefersToShenandoah.java#generational

Reviewed-by: ysr
Backport-of: 60c6dd9d274ae5b880406d4242f6fe0f6658d0c4

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

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

From wkemper at openjdk.org  Fri Dec 13 18:31:16 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 18:31:16 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests
Message-ID: <VB16FKUw7SkUoObo6GfPdmXtu_vZUTfutsJD5GGQCvc=.83f2c4c0-b247-42df-a286-547526da8347@github.com>

Clean backport.

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

Commit messages:
 - Backport 2ce53e88481659734bc5424c643c5e31c116bc5d

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

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

From azafari at openjdk.org  Fri Dec 13 18:45:37 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 13 Dec 2024 18:45:37 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v2]
In-Reply-To: <kp5cKHqFUADE4Rl3cttLj2ddw8FgwU_iFNEg14LPK48=.939c65d7-2c73-438b-9460-12e182a93682@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <kp5cKHqFUADE4Rl3cttLj2ddw8FgwU_iFNEg14LPK48=.939c65d7-2c73-438b-9460-12e182a93682@github.com>
Message-ID: <LNu02wrDFHOXfRFGMvEcRXkU63l0oa1euAK27HQq9cw=.22f2eb3e-11d0-4272-906f-8ecc319b21cf@github.com>

On Fri, 13 Dec 2024 13:23:14 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge remote-tracking branch 'upstream/master' into reserved_space_rewrite
>  - Fix comment
>  - 8345655: Move reservation code out of ReservedSpace

Thanks for this work.
I found no problem in logic and replacements. However, some Copyright years have to be updated:

- New files should have only one year in Copyright text:
`memoryReserver.?pp`
`reservedSpace.?pp`

- Changed files:
`cds/dynamicArchive.hpp`
`gc/g1/g1PageBasedVirtualSpace.hpp`
`gc/parallel/psVirtualspace.hpp`
`gc/shared/generationCounters.cpp` + `.hpp`
`memory/metaspace/virtualSpaceNode.hpp`

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

PR Review: https://git.openjdk.org/jdk/pull/22712#pullrequestreview-2502915973

From wkemper at openjdk.org  Fri Dec 13 19:04:13 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 19:04:13 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v2]
In-Reply-To: <VB16FKUw7SkUoObo6GfPdmXtu_vZUTfutsJD5GGQCvc=.83f2c4c0-b247-42df-a286-547526da8347@github.com>
References: <VB16FKUw7SkUoObo6GfPdmXtu_vZUTfutsJD5GGQCvc=.83f2c4c0-b247-42df-a286-547526da8347@github.com>
Message-ID: <bGFoqyyyNZQq_OLblbPKsbhuD7lBnx8QvLXrAppQco4=.7b7a8d56-50f1-4621-8a6e-788beba697cd@github.com>

> Clean backport.

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

  Do not use API that does not exist in 21

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/145/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/145/files/0c969cc4..8401a30a

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

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

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

From wkemper at openjdk.org  Fri Dec 13 18:59:15 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 18:59:15 GMT
Subject: RFR: 8346051: MemoryTest fails when Shenandoah's generational mode is
 enabled
Message-ID: <T16z5RqtHZ820HOYLftZhOhpnO4cNxa0P2nFUqVlaI8=.3250bc83-48da-44ef-913a-b8f78ee9fda2@github.com>

Clean backport. Test only fix.

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

Commit messages:
 - Backport cfa04d31ddff49cbf5dfdfedd61264d5556a283c

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

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

From wkemper at openjdk.org  Fri Dec 13 19:08:54 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 13 Dec 2024 19:08:54 GMT
Subject: Integrated: 8346051: MemoryTest fails when Shenandoah's generational
 mode is enabled
In-Reply-To: <T16z5RqtHZ820HOYLftZhOhpnO4cNxa0P2nFUqVlaI8=.3250bc83-48da-44ef-913a-b8f78ee9fda2@github.com>
References: <T16z5RqtHZ820HOYLftZhOhpnO4cNxa0P2nFUqVlaI8=.3250bc83-48da-44ef-913a-b8f78ee9fda2@github.com>
Message-ID: <1E9bhnwYl6LueUEOJN1WhUVKZ6pHxG8GH7c9nrjbydc=.2561af5f-7a16-48ba-8121-eb7373e13da7@github.com>

On Fri, 13 Dec 2024 18:54:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Test only fix.

This pull request has now been integrated.

Changeset: b0898aee
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/b0898aeea35160af04c9dd32ee9f00a3c9c1b1b5
Stats:     16 lines in 1 file changed: 12 ins; 0 del; 4 mod

8346051: MemoryTest fails when Shenandoah's generational mode is enabled

Backport-of: cfa04d31ddff49cbf5dfdfedd61264d5556a283c

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

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

From aph at openjdk.org  Sat Dec 14 10:05:47 2024
From: aph at openjdk.org (Andrew Haley)
Date: Sat, 14 Dec 2024 10:05:47 GMT
Subject: RFR: 8344880: AArch64: Add compile time check for class offsets
In-Reply-To: <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>
References: <axMGQNFft8YRtpwLxP8a6DgDiRzIetPwr2lRN78pTbk=.2c614059-a00a-4379-8d53-145ac832fe92@github.com>
 <rzJ-Ppc_MNL-0A4HYLJkTFU4Yvjl5io-rMcpJx25nEI=.3fc5a8d8-2889-4d8d-9d2c-4ea4d99907c6@github.com>
 <Y5_7egyknykMSMpn6VFY7rXDpYS1Z_uc20rtinQinOM=.6058109b-db54-451b-be16-397b6f51eede@github.com>
Message-ID: <Tr7TUZOufbH6KR6R_NzEtvmkMv_CjCRMfhBRONAh9FI=.5abcafd3-713d-43b6-962e-3457195416a0@github.com>

On Fri, 13 Dec 2024 10:24:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> 
> If instead of this PR we were to use some variant of `form_address()` on register+offset addresses, we wouldn't need to care about whether the offsets were compile-time constants or not, we wouldn't need this extra code, and the result would be easier to read and maintain.

Note: we only should do that on register+offset addresses that we don't already know to be safe.

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

PR Comment: https://git.openjdk.org/jdk/pull/22623#issuecomment-2543036787

From stefank at openjdk.org  Mon Dec 16 10:39:17 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Dec 2024 10:39:17 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22712/files
  - new: https://git.openjdk.org/jdk/pull/22712/files/7b053084..c936bd44

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

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

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

From stefank at openjdk.org  Mon Dec 16 10:39:17 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 16 Dec 2024 10:39:17 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v2]
In-Reply-To: <LNu02wrDFHOXfRFGMvEcRXkU63l0oa1euAK27HQq9cw=.22f2eb3e-11d0-4272-906f-8ecc319b21cf@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <kp5cKHqFUADE4Rl3cttLj2ddw8FgwU_iFNEg14LPK48=.939c65d7-2c73-438b-9460-12e182a93682@github.com>
 <LNu02wrDFHOXfRFGMvEcRXkU63l0oa1euAK27HQq9cw=.22f2eb3e-11d0-4272-906f-8ecc319b21cf@github.com>
Message-ID: <WCpMVbxiH3jtb5Q9Vuw4MLXo94xwvm2wojs81Hqa6hs=.c08ac4c4-4211-43cf-b683-a422f0a105be@github.com>

On Fri, 13 Dec 2024 18:42:38 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> Thanks for this work.
> I found no problem in logic and replacements.

Thanks for reviewing!

> New files should have only one year in Copyright text:
> memoryReserver.?pp
> reservedSpace.?pp

I don't think this is correct. Code was copied from other files, so I transferred the copyright from those files. When I previously have asked around about this situation, the guidance I've been given the guidance that this is preferred over only using the current year.

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

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2545208396

From ysr at openjdk.org  Tue Dec 17 01:19:04 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 17 Dec 2024 01:19:04 GMT
Subject: RFR: 8345970: pthread_getcpuclockid related crashes in shenandoah
 tests [v2]
In-Reply-To: <bGFoqyyyNZQq_OLblbPKsbhuD7lBnx8QvLXrAppQco4=.7b7a8d56-50f1-4621-8a6e-788beba697cd@github.com>
References: <VB16FKUw7SkUoObo6GfPdmXtu_vZUTfutsJD5GGQCvc=.83f2c4c0-b247-42df-a286-547526da8347@github.com>
 <bGFoqyyyNZQq_OLblbPKsbhuD7lBnx8QvLXrAppQco4=.7b7a8d56-50f1-4621-8a6e-788beba697cd@github.com>
Message-ID: <4eDSX-2ScB30SI9YUNDY62TvQ8OIiH_Di3QHit90LCg=.78818ecb-1a72-4522-8a9c-e44a51539db1@github.com>

On Fri, 13 Dec 2024 19:04:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Clean backport.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not use API that does not exist in 21

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/145#pullrequestreview-2507660682

From stefank at openjdk.org  Tue Dec 17 09:57:39 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 17 Dec 2024 09:57:39 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <9vUxbGkHbRb3E6VJ75e_RdkjfqQPAcnXQogLbNu0qgc=.75e18df2-1ee7-455f-9242-818ac679d0b3@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

@jdksjolen @afshin-zafari Are you OK with me pushing the code as it is right now?

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

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2547992385

From stefank at openjdk.org  Tue Dec 17 09:57:39 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 17 Dec 2024 09:57:39 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <0DIQXJDLaUvtZOhwOROXFP4YPhDIfTEJZ1v7ib-_6_s=.3c84c791-d338-4e18-a4ba-a7f0a2b984e2@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <o138HLYD2SvZPDgtt5KLP4KDNHGlYh-W-ZKg6Dymin0=.00086488-41c7-41cb-9d39-f16c2ed307fa@github.com>
 <2AsNiLgxBeMg4aQASmj6dPe_INF7h0lI415c8JGwXPI=.137f95af-e0fa-4564-a073-972ac49e89cc@github.com>
 <7vWI962XXDBJPgStyp0eEYuMf0IWqe44gSQiLSkO6n8=.d9ec7e5a-0031-4999-acff-8ee2bfb94059@github.com>
 <0DIQXJDLaUvtZOhwOROXFP4YPhDIfTEJZ1v7ib-_6_s=.3c84c791-d338-4e18-a4ba-a7f0a2b984e2@github.com>
Message-ID: <EE5SvoPGjvyriMMJ8-tLrfOiYXxG60NRUEn7o2Rwxjg=.f662de8c-141d-4260-8f16-dc2f0767bcd9@github.com>

On Fri, 13 Dec 2024 13:36:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> My reasoning was that MemoryReserver does not have the ownership of the ReservedSpace instance, so I didn't want it to be the one clearing the members. If others feel the same way as you do, then I would prefer to add a function release_and_clear to make it clearer (:)) what's going on.
>
> `release_and_clear`does sound clearer :)

My preference is to stay with the current proposal and let code that requested reserve memory decide if and when the ReservedSpace should be cleared. I think it would be an easy thing to reevaluate in another RFE if we change our minds later on.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22712#discussion_r1888222021

From jsjolen at openjdk.org  Tue Dec 17 10:07:42 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Tue, 17 Dec 2024 10:07:42 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <2YJoDesdWv0qP6-wF0SEdUpK8EXoE3-c8PB_puxNEhw=.bd0b4600-d2b4-440c-b20c-218252bf46a3@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

I am okay with this, I wanted to defer an approval to see whether others would chime in. Thank you for this work.

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22712#pullrequestreview-2508408235

From azafari at openjdk.org  Tue Dec 17 11:07:45 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 17 Dec 2024 11:07:45 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <glB1Z0sSyCh0gLVLYew9E9b2NwH7Biqp55FIt-yX5d8=.e071e756-b1ee-4e11-9ad5-06fa5519448a@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

Thanks again for this work. No comments.

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

Marked as reviewed by azafari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22712#pullrequestreview-2508563728

From stefank at openjdk.org  Tue Dec 17 13:16:40 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 17 Dec 2024 13:16:40 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <DPTT-_rvoLVJ5QsRuryH-E3dZ3J9liV8r0249loIxu8=.3ba7bc2a-7856-4142-b672-ffb33dadbb39@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

OK. Thanks. I'll give it one more day to let any reviewers get a chance to take a look.

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

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2548430738

From wkemper at openjdk.org  Tue Dec 17 19:25:09 2024
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 17 Dec 2024 19:25:09 GMT
Subject: Integrated: 8345970: pthread_getcpuclockid related crashes in
 shenandoah tests
In-Reply-To: <VB16FKUw7SkUoObo6GfPdmXtu_vZUTfutsJD5GGQCvc=.83f2c4c0-b247-42df-a286-547526da8347@github.com>
References: <VB16FKUw7SkUoObo6GfPdmXtu_vZUTfutsJD5GGQCvc=.83f2c4c0-b247-42df-a286-547526da8347@github.com>
Message-ID: <KEVuYFVYHayfTWY6zp28v_sDi00uW1qTbZO3jB0OIFA=.a27af906-bf85-4d92-a671-b41c1a85c14a@github.com>

On Fri, 13 Dec 2024 18:26:36 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 1d7e999f
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/1d7e999f5c694f3c3a28544c9e9a38ca0b65c364
Stats:     18 lines in 4 files changed: 15 ins; 3 del; 0 mod

8345970: pthread_getcpuclockid related crashes in shenandoah tests

Reviewed-by: ysr
Backport-of: 2ce53e88481659734bc5424c643c5e31c116bc5d

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

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

From fyang at openjdk.org  Wed Dec 18 04:46:08 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 18 Dec 2024 04:46:08 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines
Message-ID: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>

Hi, please consider this cleanup change.

Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check
about the immediate range and save the tmp register used by the latter as well. In order to make the code more readable, this
also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.

Testing: tier1-3 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

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

Commit messages:
 - 8346478: RISC-V: Refactor add/sub assembler routines

Changes: https://git.openjdk.org/jdk/pull/22804/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22804&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346478
  Stats: 392 lines in 19 files changed: 14 ins; 6 del; 372 mod
  Patch: https://git.openjdk.org/jdk/pull/22804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22804/head:pull/22804

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

From stefank at openjdk.org  Wed Dec 18 10:21:49 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 18 Dec 2024 10:21:49 GMT
Subject: RFR: 8345655: Move reservation code out of ReservedSpace [v3]
In-Reply-To: <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
 <hj_0wuZLh62KVPkwrUuaEYqCvKPOGiCX3GbokKPZeqk=.8357337c-9f3c-48b5-b8de-e3ed67a5ffd8@github.com>
Message-ID: <tdhhNj0l3--1dPqKYi2cUz5t1B8mrQUbCNwICGthPhI=.6d5bac90-9375-4cc9-887e-a0af6a73097d@github.com>

On Mon, 16 Dec 2024 10:39:17 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
>> 
>> See the first comment for the full description:
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

I merged and ran tier1 internally and GHA. Thanks again for reviewing!

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

PR Comment: https://git.openjdk.org/jdk/pull/22712#issuecomment-2550930159

From stefank at openjdk.org  Wed Dec 18 10:21:52 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 18 Dec 2024 10:21:52 GMT
Subject: Integrated: 8345655: Move reservation code out of ReservedSpace
In-Reply-To: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
References: <mZs9vUk1IQfRgxai91_Jolx4NeE4ojRXfY3Hj7hrXr4=.9c82a402-5006-4007-b65d-8513fc998ca9@github.com>
Message-ID: <wIdt2Qz9l1hmnuN6WG4M1PszURSof4VEYv0rllrNjHI=.21eba295-4030-42e7-b56b-9c95cf418d92@github.com>

On Thu, 12 Dec 2024 13:36:07 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The ReservedSpace class and its friends has a dual functionality of describing a reserved memory region AND it also reserves memory. I would like to split this so that the ReservedSpace classes only acts as data carrier about reserved memory and then have a more explicit API for reserving memory and baking a ReservedSpace given the outcome of the reservation.
> 
> See the first comment for the full description:

This pull request has now been integrated.

Changeset: 73b5dbae
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73b5dbaec340b3e8c958d63f510df92ec621c04e
Stats:     2113 lines in 59 files changed: 1182 ins; 806 del; 125 mod

8345655: Move reservation code out of ReservedSpace

Reviewed-by: azafari, jsjolen

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

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

From zgu at openjdk.org  Wed Dec 18 14:51:45 2024
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 18 Dec 2024 14:51:45 GMT
Subject: RFR: 8346569: Shenandoah: Worker initializes ShenandoahThreadLocalData
 twice results in memory leak
Message-ID: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>

Worker thread initializes ShenandoahThreadLocalData twice, from Thread's constructor and ShenandoahWorkerThreads::on_create_worker(), that results in leaking ShenandoahEvacuationStats.

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

Commit messages:
 - 8346569: Shenandoah: Worker initializes ShenandoahThreadLocalData twice results in memory leak

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

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

From fyang at openjdk.org  Thu Dec 19 03:19:06 2024
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 19 Dec 2024 03:19:06 GMT
Subject: RFR: 8346478: RISC-V: Refactor add/sub assembler routines [v2]
In-Reply-To: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
References: <MMSWEzRZo8bLWNUGC3ndUelgl2Kxy7alAvvHZYqXHrk=.bd1feb2b-e004-47a1-9609-543971f6d2a8@github.com>
Message-ID: <LtH9C6pYxZPkHeB3uIg8qGKYGT-uRbqaSWU_fZCrhlQ=.1a8e3d7f-ef68-477e-a2a4-32a85780c693@github.com>

> Hi, please consider this cleanup change.
> 
> Currently, we have mixed use of `addi` and `add(int64_t)`/`sub(int64_t)`. The former adds a 12-bit immediate while the latter
> does not have a constraint on the immediate range. We should use `addi` when possible, which would help save one runtime check
> about the immediate range and save the tmp register used by the latter as well. In order to make the code more readable, this
> also introduces helper routines `subi`/`subiw` and adapts callsites of `addi`/`addiw` with negative immediates.
> 
> Testing: tier1-3 and gtest:all are clean on Premier-P550 SBC running Ubuntu-24.04.

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

 - Merge branch 'master' into JDK-8346478
 - 8346478: RISC-V: Refactor add/sub assembler routines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22804/files
  - new: https://git.openjdk.org/jdk/pull/22804/files/22d2397f..58e9a0eb

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

  Stats: 3103 lines in 121 files changed: 1813 ins; 1008 del; 282 mod
  Patch: https://git.openjdk.org/jdk/pull/22804.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22804/head:pull/22804

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

From stefank at openjdk.org  Thu Dec 19 09:40:07 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 19 Dec 2024 09:40:07 GMT
Subject: RFR: 8346572: Check is_reserved() before using ReservedSpace instances
Message-ID: <ThG3rqVZAr9dfCjGMeJ4exzq5shpUDxkgqAsKou3Ub4=.13a74468-3724-4df4-b279-0e5ad49a683c@github.com>

There are a number of places where we reserve memory and create a ReservedSpace, and after the use the created instance without checking if the memory actually got reserved and the instance got initialized. This mostly affects code paths during JVM initialization and fixing this will mostly give better error handling and tracing.

The patch also includes some minor restructuring to get early returns and remove redundant null checks after calls to new.

Tested tier1 and GHA, but will run more tests when/if this gets accepted.

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

Commit messages:
 - 8346572: Check is_reserved() before using ReservedSpace instances

Changes: https://git.openjdk.org/jdk/pull/22825/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22825&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346572
  Stats: 117 lines in 10 files changed: 47 ins; 31 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/22825.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22825/head:pull/22825

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

From wkemper at openjdk.org  Thu Dec 19 18:46:36 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Dec 2024 18:46:36 GMT
Subject: RFR: 8346681: Shenandoah: Does not throw OOME when EATests expects it
Message-ID: <uDps4vFyV68UgAUH0qEiK6EnYFFvns7K6Ohf-rq0BYU=.324d4d1e-25c4-4f2f-af68-12934d26f27f@github.com>

The changes to this test reflect the similar changes for ZGC. The test was never backported to 21.

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

Commit messages:
 - Shenandoah does not throw OOME when this tests expects it

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

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

From kdnilsen at openjdk.org  Thu Dec 19 18:53:52 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 19 Dec 2024 18:53:52 GMT
Subject: RFR: 8346681: Shenandoah: Does not throw OOME when EATests expects
 it
In-Reply-To: <uDps4vFyV68UgAUH0qEiK6EnYFFvns7K6Ohf-rq0BYU=.324d4d1e-25c4-4f2f-af68-12934d26f27f@github.com>
References: <uDps4vFyV68UgAUH0qEiK6EnYFFvns7K6Ohf-rq0BYU=.324d4d1e-25c4-4f2f-af68-12934d26f27f@github.com>
Message-ID: <rSCikgf2bgVVGFCuVoLSGd5K27UTlPG9mq8RU-UK3mQ=.a0b8f9fa-6969-4249-b1c9-8324c2a092b5@github.com>

On Thu, 19 Dec 2024 18:41:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The changes to this test reflect the similar changes for ZGC. The test was never backported to 21.

Thanks for addressing this.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/147#pullrequestreview-2515938506

From wkemper at openjdk.org  Thu Dec 19 19:04:54 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Dec 2024 19:04:54 GMT
Subject: Integrated: 8346681: Shenandoah: Does not throw OOME when EATests
 expects it
In-Reply-To: <uDps4vFyV68UgAUH0qEiK6EnYFFvns7K6Ohf-rq0BYU=.324d4d1e-25c4-4f2f-af68-12934d26f27f@github.com>
References: <uDps4vFyV68UgAUH0qEiK6EnYFFvns7K6Ohf-rq0BYU=.324d4d1e-25c4-4f2f-af68-12934d26f27f@github.com>
Message-ID: <KR1PNoXtCiLHJwtrQvlLjzkmdFtJfhCLBA88TPwpVi8=.5d0fd769-4c56-417d-a6cd-211fc3206687@github.com>

On Thu, 19 Dec 2024 18:41:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The changes to this test reflect the similar changes for ZGC. The test was never backported to 21.

This pull request has now been integrated.

Changeset: 463eb230
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/463eb2302349d44f2f78039c76c1f87015a40b32
Stats:     16 lines in 1 file changed: 10 ins; 0 del; 6 mod

8346681: Shenandoah: Does not throw OOME when EATests expects it

Reviewed-by: kdnilsen

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

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

From wkemper at openjdk.org  Thu Dec 19 23:12:50 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Dec 2024 23:12:50 GMT
Subject: RFR: 8346688: GenShen: Missing metadata trigger log message
Message-ID: <2Z7snRh4sOgooDgZsjShb7M59GrTay0BRjVfq9tLLb4=.ea98e839-5173-4ebb-ac4d-4c5088c39d4a@github.com>

The generational mode may trigger a global collection when metaspace is exhausted. When this happens, it should log this trigger as the reason for starting a cycle.

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

Commit messages:
 - Missing metadata trigger log message in generational mode

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

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

From wkemper at openjdk.org  Thu Dec 19 23:35:34 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Dec 2024 23:35:34 GMT
Subject: RFR: 8346569: Shenandoah: Worker initializes
 ShenandoahThreadLocalData twice results in memory leak
In-Reply-To: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
References: <qNVhaOQ7mLcVbDO0zNLA6ZTMKeo39FgmmxS0lBgawrw=.a07e6f1d-c76c-44a3-83d6-8b1cc6a1bebb@github.com>
Message-ID: <CIH8Ty37pKj53G8mQB-I26QjEHCgzSnNEJEfUgws1rM=.ea1aabfe-87af-4af7-bcdb-8c883d1dc76e@github.com>

On Wed, 18 Dec 2024 14:46:57 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Worker thread initializes ShenandoahThreadLocalData twice, from Thread's constructor and ShenandoahWorkerThreads::on_create_worker(), that results in leaking ShenandoahEvacuationStats.

Good catch! How'd you find this?

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

Marked as reviewed by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22812#pullrequestreview-2516415866

From wkemper at openjdk.org  Thu Dec 19 23:52:56 2024
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 19 Dec 2024 23:52:56 GMT
Subject: RFR: 8346690: Shenandoah: Fix log message for end of GC usage report
Message-ID: <oPzePSWxb1du1NcJYggj1ajNabawMKTtFPRegEOpnsE=.0a3066b9-2c4d-46f0-990c-a568d91e683e@github.com>

At the end of a cycle, the non-generational mode usage report has an errant reference to 'generation':

GC(1) At end of GC: generation used: 835M ...

After this change, the message is:

GC(0) At end of GC: used: 1793K ...


The message is unchanged for the generational mode:

GC(0) At end of Concurrent Global GC: Young generation used: 1544K ...
GC(0) At end of Concurrent Global GC: Old generation used: 0B ...

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

Commit messages:
 - Fix usage report log message for non-generational modes

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

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

From ysr at openjdk.org  Fri Dec 20 01:39:33 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 20 Dec 2024 01:39:33 GMT
Subject: RFR: 8346688: GenShen: Missing metadata trigger log message
In-Reply-To: <2Z7snRh4sOgooDgZsjShb7M59GrTay0BRjVfq9tLLb4=.ea98e839-5173-4ebb-ac4d-4c5088c39d4a@github.com>
References: <2Z7snRh4sOgooDgZsjShb7M59GrTay0BRjVfq9tLLb4=.ea98e839-5173-4ebb-ac4d-4c5088c39d4a@github.com>
Message-ID: <DsiTKdISyQaG3XdLoV3N8BxR5gN0i4LyzM-9kJaUWgw=.b40edd2f-7659-4b92-b88b-7035ce90db76@github.com>

On Thu, 19 Dec 2024 23:08:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The generational mode may trigger a global collection when metaspace is exhausted. When this happens, it should log this trigger as the reason for starting a cycle.

May be also add the affected (previously failing) test names to the ticket as a future archeological aid.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22838#pullrequestreview-2516543634

From ysr at openjdk.org  Fri Dec 20 01:43:34 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 20 Dec 2024 01:43:34 GMT
Subject: RFR: 8346690: Shenandoah: Fix log message for end of GC usage
 report
In-Reply-To: <oPzePSWxb1du1NcJYggj1ajNabawMKTtFPRegEOpnsE=.0a3066b9-2c4d-46f0-990c-a568d91e683e@github.com>
References: <oPzePSWxb1du1NcJYggj1ajNabawMKTtFPRegEOpnsE=.0a3066b9-2c4d-46f0-990c-a568d91e683e@github.com>
Message-ID: <nhdoYVCNMGQD_zBvX33QH-T_ftDomFbTQFVh0lMHmiM=.d7844e27-e7a8-4d8a-8dd9-7c47b9bf3a6f@github.com>

On Thu, 19 Dec 2024 23:48:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

> At the end of a cycle, the non-generational mode usage report has an errant reference to 'generation':
> 
> GC(1) At end of GC: generation used: 835M ...
> 
> After this change, the message is:
> 
> GC(0) At end of GC: used: 1793K ...
> 
> 
> The message is unchanged for the generational mode:
> 
> GC(0) At end of Concurrent Global GC: Young generation used: 1544K ...
> GC(0) At end of Concurrent Global GC: Old generation used: 0B ...

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22839#pullrequestreview-2516551704

From xpeng at openjdk.org  Fri Dec 20 07:58:10 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 20 Dec 2024 07:58:10 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
Message-ID: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>

Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.

I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.

GenShen:
Before:

[33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)


After:

[33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
[33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)


Shenandoah:
Before:

[33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)

After:

[33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
[33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)


Additional changes:
* Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
* Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
-  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
-  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
* When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
* Clean up FullGC code, remove duplicate code.

Additional tests:
- [x] CONF=macosx-aarch64-server-fastdebug make test TEST=hotspot_gc_shenandoah

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

Commit messages:
 - Merge branch 'openjdk:master' into reset-bitmap
 - Remove ShenandoahResetUpdateRegionStateClosure
 - Always set_mark_incomplete when reset mark bitmap
 - Fix
 - Add comments
 - fix
 - Not reset_mark_bitmap after cycle when  is_concurrent_old_mark_in_progress or is_prepare_for_old_mark_in_progress
 - Not invoke set_mark_incomplete when reset bitmap after cycle
 - Renaming, comments, cleanup
 - Merge Concurrent reset (Old) into Concurrent reset
 - ... and 5 more: https://git.openjdk.org/jdk/compare/b2811a0c...2b9f28a1

Changes: https://git.openjdk.org/jdk/pull/22778/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22778&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338737
  Stats: 176 lines in 9 files changed: 93 ins; 62 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/22778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22778/head:pull/22778

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

From kdnilsen at openjdk.org  Fri Dec 20 16:57:36 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 20 Dec 2024 16:57:36 GMT
Subject: RFR: 8346688: GenShen: Missing metadata trigger log message
In-Reply-To: <2Z7snRh4sOgooDgZsjShb7M59GrTay0BRjVfq9tLLb4=.ea98e839-5173-4ebb-ac4d-4c5088c39d4a@github.com>
References: <2Z7snRh4sOgooDgZsjShb7M59GrTay0BRjVfq9tLLb4=.ea98e839-5173-4ebb-ac4d-4c5088c39d4a@github.com>
Message-ID: <J6EQ2dz0tfVHcznAnU8QTi5vPye76gelz5sH4hoO88o=.02d4c802-8709-4fe0-b813-d052bfb1adf2@github.com>

On Thu, 19 Dec 2024 23:08:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The generational mode may trigger a global collection when metaspace is exhausted. When this happens, it should log this trigger as the reason for starting a cycle.

Marked as reviewed by kdnilsen (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/22838#pullrequestreview-2517956956

From kdnilsen at openjdk.org  Fri Dec 20 16:59:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 20 Dec 2024 16:59:35 GMT
Subject: RFR: 8346690: Shenandoah: Fix log message for end of GC usage
 report
In-Reply-To: <oPzePSWxb1du1NcJYggj1ajNabawMKTtFPRegEOpnsE=.0a3066b9-2c4d-46f0-990c-a568d91e683e@github.com>
References: <oPzePSWxb1du1NcJYggj1ajNabawMKTtFPRegEOpnsE=.0a3066b9-2c4d-46f0-990c-a568d91e683e@github.com>
Message-ID: <Jo6hnAj9OhA-1xOw_G1YjYxAfLvgAmz4tW17QbC0KP8=.b2fc42ca-b805-42e0-9745-426ef1e7c63d@github.com>

On Thu, 19 Dec 2024 23:48:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

> At the end of a cycle, the non-generational mode usage report has an errant reference to 'generation':
> 
> GC(1) At end of GC: generation used: 835M ...
> 
> After this change, the message is:
> 
> GC(0) At end of GC: used: 1793K ...
> 
> 
> The message is unchanged for the generational mode:
> 
> GC(0) At end of Concurrent Global GC: Young generation used: 1544K ...
> GC(0) At end of Concurrent Global GC: Old generation used: 0B ...

Marked as reviewed by kdnilsen (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/22839#pullrequestreview-2517959678

From wkemper at openjdk.org  Fri Dec 20 17:32:42 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 17:32:42 GMT
Subject: Integrated: 8346690: Shenandoah: Fix log message for end of GC usage
 report
In-Reply-To: <oPzePSWxb1du1NcJYggj1ajNabawMKTtFPRegEOpnsE=.0a3066b9-2c4d-46f0-990c-a568d91e683e@github.com>
References: <oPzePSWxb1du1NcJYggj1ajNabawMKTtFPRegEOpnsE=.0a3066b9-2c4d-46f0-990c-a568d91e683e@github.com>
Message-ID: <prUDs6waSD_ig595RZ67DyM75BQnMUkBETMNKASaqGU=.8c656b38-f220-496f-a1fe-0032bb9ca64a@github.com>

On Thu, 19 Dec 2024 23:48:26 GMT, William Kemper <wkemper at openjdk.org> wrote:

> At the end of a cycle, the non-generational mode usage report has an errant reference to 'generation':
> 
> GC(1) At end of GC: generation used: 835M ...
> 
> After this change, the message is:
> 
> GC(0) At end of GC: used: 1793K ...
> 
> 
> The message is unchanged for the generational mode:
> 
> GC(0) At end of Concurrent Global GC: Young generation used: 1544K ...
> GC(0) At end of Concurrent Global GC: Old generation used: 0B ...

This pull request has now been integrated.

Changeset: d2a48634
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d2a48634b872b65668b57d3975f805277ae96f83
Stats:     18 lines in 1 file changed: 3 ins; 0 del; 15 mod

8346690: Shenandoah: Fix log message for end of GC usage report

Reviewed-by: ysr, kdnilsen

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

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

From wkemper at openjdk.org  Fri Dec 20 17:34:43 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 17:34:43 GMT
Subject: RFR: 8346688: GenShen: Missing metadata trigger log message
In-Reply-To: <2Z7snRh4sOgooDgZsjShb7M59GrTay0BRjVfq9tLLb4=.ea98e839-5173-4ebb-ac4d-4c5088c39d4a@github.com>
References: <2Z7snRh4sOgooDgZsjShb7M59GrTay0BRjVfq9tLLb4=.ea98e839-5173-4ebb-ac4d-4c5088c39d4a@github.com>
Message-ID: <WvoZlukIAgLLgDw2kbnTBP4vCy5snN93Sts7X_wydH8=.6ccc6403-071a-4494-9b80-ad3c71cb07fc@github.com>

On Thu, 19 Dec 2024 23:08:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The generational mode may trigger a global collection when metaspace is exhausted. When this happens, it should log this trigger as the reason for starting a cycle.

The failing tests are mentioned in the comment, but for posterity and specificity, they were:
* vmTestbase/metaspace/gc/watermark_0_1/TestDescription.java 
* vmTestbase/metaspace/gc/watermark_10_20/TestDescription.java 
* vmTestbase/metaspace/gc/watermark_70_80/TestDescription.java

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

PR Comment: https://git.openjdk.org/jdk/pull/22838#issuecomment-2557434836

From wkemper at openjdk.org  Fri Dec 20 17:34:44 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 17:34:44 GMT
Subject: Integrated: 8346688: GenShen: Missing metadata trigger log message
In-Reply-To: <2Z7snRh4sOgooDgZsjShb7M59GrTay0BRjVfq9tLLb4=.ea98e839-5173-4ebb-ac4d-4c5088c39d4a@github.com>
References: <2Z7snRh4sOgooDgZsjShb7M59GrTay0BRjVfq9tLLb4=.ea98e839-5173-4ebb-ac4d-4c5088c39d4a@github.com>
Message-ID: <v2orDPKrVJv_r4Qs3DDbQWYqD9o5wE-h1xAxcecpFgY=.a7dc5efe-be9d-4839-9754-c8e64e8438d3@github.com>

On Thu, 19 Dec 2024 23:08:19 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The generational mode may trigger a global collection when metaspace is exhausted. When this happens, it should log this trigger as the reason for starting a cycle.

This pull request has now been integrated.

Changeset: b8e40b9c
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8e40b9c2dfecdad9096015c1aa208ea077db7f5
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8346688: GenShen: Missing metadata trigger log message

Reviewed-by: ysr, kdnilsen

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

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

From wkemper at openjdk.org  Fri Dec 20 17:56:19 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 17:56:19 GMT
Subject: RFR: 8346688: GenShen: Missing metadata trigger log message
Message-ID: <49-IZoT52ngfJf-1PGXCGj3pP97r1MCDUBGJGyUAheY=.0354c7de-6852-474b-88ec-710ceda1b550@github.com>

Clean backport. Logging changes only. Fixes tests.

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

Commit messages:
 - Backport b8e40b9c2dfecdad9096015c1aa208ea077db7f5

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

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

From wkemper at openjdk.org  Fri Dec 20 17:56:32 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 17:56:32 GMT
Subject: RFR: 8346690: Shenandoah: Fix log message for end of GC usage report
Message-ID: <LR6pvVWnIzs4ILwJUJLxvSbbCvM1zBjTUFys7LIHDig=.007c4a2f-f0a4-4a0f-8d29-177d31f5d2c1@github.com>

Clean backport. Logging changes only.

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

Commit messages:
 - Backport d2a48634b872b65668b57d3975f805277ae96f83

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

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

From wkemper at openjdk.org  Fri Dec 20 17:59:57 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 17:59:57 GMT
Subject: Integrated: 8346688: GenShen: Missing metadata trigger log message
In-Reply-To: <49-IZoT52ngfJf-1PGXCGj3pP97r1MCDUBGJGyUAheY=.0354c7de-6852-474b-88ec-710ceda1b550@github.com>
References: <49-IZoT52ngfJf-1PGXCGj3pP97r1MCDUBGJGyUAheY=.0354c7de-6852-474b-88ec-710ceda1b550@github.com>
Message-ID: <QdNuMBlq6ET0XF8ZlLbrTx3ssEIBXa_YUnQFQjY9R8E=.aea7c6f0-3835-4631-8e1d-b7c1f95e33ab@github.com>

On Fri, 20 Dec 2024 17:50:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Logging changes only. Fixes tests.

This pull request has now been integrated.

Changeset: 48cd85fd
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/48cd85fd2b84915211f9db18a538fcca5c4d3afd
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8346688: GenShen: Missing metadata trigger log message

Backport-of: b8e40b9c2dfecdad9096015c1aa208ea077db7f5

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

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

From wkemper at openjdk.org  Fri Dec 20 18:01:06 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 18:01:06 GMT
Subject: Integrated: 8346690: Shenandoah: Fix log message for end of GC usage
 report
In-Reply-To: <LR6pvVWnIzs4ILwJUJLxvSbbCvM1zBjTUFys7LIHDig=.007c4a2f-f0a4-4a0f-8d29-177d31f5d2c1@github.com>
References: <LR6pvVWnIzs4ILwJUJLxvSbbCvM1zBjTUFys7LIHDig=.007c4a2f-f0a4-4a0f-8d29-177d31f5d2c1@github.com>
Message-ID: <3Ev1tVjVIgxj9eD0XZPHI9DeR4Rb2EsET6zMNxHRsO8=.8b3a10f2-92d2-4a9d-9a47-8dd3892e0a3f@github.com>

On Fri, 20 Dec 2024 17:50:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Logging changes only.

This pull request has now been integrated.

Changeset: ae45b94b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/ae45b94bb61f375f139abbc9bc5cc91c716bb5b4
Stats:     18 lines in 1 file changed: 3 ins; 0 del; 15 mod

8346690: Shenandoah: Fix log message for end of GC usage report

Backport-of: d2a48634b872b65668b57d3975f805277ae96f83

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

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

From wkemper at openjdk.org  Fri Dec 20 18:13:48 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 18:13:48 GMT
Subject: RFR: 8346737: GenShen: Generational memory pools should not report
 zero for maximum capacity
Message-ID: <FKm-SlM-3p_bCBr-iV7eFeXFdL5ZVehtieTrcbyPvIw=.991ed215-0abb-4054-a9bc-559627558270@github.com>

The following tests fail in generational mode because the old generation reports a _maximum_ capacity of zero when it is empty. It makes sense to treat maximum capacity as a _theoretical_ maximum and let it equal the total size of the heap.

- vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded001/TestDescription.java 
- vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java 
- vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded003/TestDescription.java 
- vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded004/TestDescription.java 
- vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded005/TestDescription.java 
- vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold001/TestDescription.java 
- vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold002/TestDescription.java 
- vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold003/TestDescription.java 
- vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold004/TestDescription.java 
- vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold005/TestDescription.java

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

Commit messages:
 - Fix usage report log message for non-generational modes

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

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

From wkemper at openjdk.org  Fri Dec 20 18:59:54 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 18:59:54 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
In-Reply-To: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
Message-ID: <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>

On Tue, 17 Dec 2024 00:09:25 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
> 
> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
> 
> GenShen:
> Before:
> 
> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
> 
> 
> After:
> 
> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
> 
> 
> Shenandoah:
> Before:
> 
> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
> 
> After:
> 
> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
> 
> 
> Additional changes:
> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
> * Clean up FullGC code, remove duplicate code.
> 
> Additional tests:
> - [x] CONF=macosx-aarch64-server-fastdebug make test T...

Looks good. Left a few nits and a few questions in the review.

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

> 1209:       // Only reset for young generation, bitmap for old generation must be retained,
> 1210:       // except there is collection(global/old/degen/full) trigged to collect regions in old gen.
> 1211:       heap->young_generation()->reset_mark_bitmap<false>();

Shouldn't it be safe to reset young region bitmaps even when old marking is in progress?

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 58:

> 56:     if (PREPARE_FOR_CURRENT_CYCLE) {
> 57:       if (region->need_bitmap_reset() && _heap->is_bitmap_slice_committed(region)) {
> 58:         _ctx->clear_bitmap(region);

Should this also `region->unset_need_bitmap_reset()`?

src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 66:

> 64:         // Reset live data and set TAMS optimistically. We would recheck these under the pause
> 65:         // anyway to capture any updates that happened since now.
> 66:         _ctx->capture_top_at_mark_start(region);

Full GC used to do this unconditionally for all affiliated regions. Do we not still need that to happen?

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 92:

> 90:   }
> 91:   _recycling.unset();
> 92:   _need_bitmap_reset = true;

Move to initializers? Why does it start with `true`? A new region would have a clear bitmap, right?

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 269:

> 267:   ShenandoahSharedFlag _recycling; // Used to indicate that the region is being recycled; see try_recycle*().
> 268: 
> 269:   bool _need_bitmap_reset;

Nit pick, but I think this would read better as `_needs_bitmap_reset`.

src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp line 161:

> 159:   }
> 160: 
> 161:   entry_reset_after_collect();

Not sure we want to reset old region bitmaps after old marking is compete. Shenandoah opportunistically uses the bitmap for old regions during remembered set scan (it's faster than walking the heap).

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

Changes requested by wkemper (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22778#pullrequestreview-2518128727
PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894270072
PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894273795
PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894277047
PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894278663
PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894283547
PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894282722

From kdnilsen at openjdk.org  Fri Dec 20 19:50:35 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 20 Dec 2024 19:50:35 GMT
Subject: RFR: 8346737: GenShen: Generational memory pools should not report
 zero for maximum capacity
In-Reply-To: <FKm-SlM-3p_bCBr-iV7eFeXFdL5ZVehtieTrcbyPvIw=.991ed215-0abb-4054-a9bc-559627558270@github.com>
References: <FKm-SlM-3p_bCBr-iV7eFeXFdL5ZVehtieTrcbyPvIw=.991ed215-0abb-4054-a9bc-559627558270@github.com>
Message-ID: <qtcxwjRdV3mVzJVzzv6jO1X98wi5FeTpLxqODh3T-0E=.c3c8889a-71ef-4c00-b50b-06e5c7a4a6c2@github.com>

On Fri, 20 Dec 2024 18:09:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The following tests fail in generational mode because the old generation reports a _maximum_ capacity of zero when it is empty. It makes sense to treat maximum capacity as a _theoretical_ maximum and let it equal the total size of the heap.
> 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded001/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded003/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded004/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded005/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold001/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold002/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold003/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold004/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold005/TestDescription.java

Marked as reviewed by kdnilsen (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/22851#pullrequestreview-2518250428

From ysr at openjdk.org  Fri Dec 20 23:23:43 2024
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 20 Dec 2024 23:23:43 GMT
Subject: RFR: 8346737: GenShen: Generational memory pools should not report
 zero for maximum capacity
In-Reply-To: <FKm-SlM-3p_bCBr-iV7eFeXFdL5ZVehtieTrcbyPvIw=.991ed215-0abb-4054-a9bc-559627558270@github.com>
References: <FKm-SlM-3p_bCBr-iV7eFeXFdL5ZVehtieTrcbyPvIw=.991ed215-0abb-4054-a9bc-559627558270@github.com>
Message-ID: <Kfzoju20ZamjE95GyL1wTkTxpLzxkEl3z_QUHuyy3eg=.bb457a03-8d8d-480e-a23f-e1ab3c1772cb@github.com>

On Fri, 20 Dec 2024 18:09:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The following tests fail in generational mode because the old generation reports a _maximum_ capacity of zero when it is empty. It makes sense to treat maximum capacity as a _theoretical_ maximum and let it equal the total size of the heap.
> 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded001/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded003/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded004/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded005/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold001/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold002/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold003/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold004/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold005/TestDescription.java

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22851#pullrequestreview-2518497177

From wkemper at openjdk.org  Fri Dec 20 23:54:39 2024
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 20 Dec 2024 23:54:39 GMT
Subject: Integrated: 8346737: GenShen: Generational memory pools should not
 report zero for maximum capacity
In-Reply-To: <FKm-SlM-3p_bCBr-iV7eFeXFdL5ZVehtieTrcbyPvIw=.991ed215-0abb-4054-a9bc-559627558270@github.com>
References: <FKm-SlM-3p_bCBr-iV7eFeXFdL5ZVehtieTrcbyPvIw=.991ed215-0abb-4054-a9bc-559627558270@github.com>
Message-ID: <-hw9gqEe4rSQ5n5Ga7Uo5CN-gbW2WsrYQDDTgQez8Js=.515c62d2-0bfd-4d01-8d61-a61ff63b7ea2@github.com>

On Fri, 20 Dec 2024 18:09:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The following tests fail in generational mode because the old generation reports a _maximum_ capacity of zero when it is empty. It makes sense to treat maximum capacity as a _theoretical_ maximum and let it equal the total size of the heap.
> 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded001/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded002/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded003/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded004/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/isCollectionUsageThresholdExceeded/isexceeded005/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold001/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold002/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold003/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold004/TestDescription.java 
> - vmTestbase/nsk/monitoring/MemoryPoolMBean/setCollectionUsageThreshold/setthreshold005/TestDescription.java

This pull request has now been integrated.

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

8346737: GenShen: Generational memory pools should not report zero for maximum capacity

Reviewed-by: kdnilsen, ysr

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

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

From xpeng at openjdk.org  Fri Dec 20 23:55:36 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 20 Dec 2024 23:55:36 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
In-Reply-To: <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
Message-ID: <dM5MCVZSF9knRaGdmymF34oknNNnnG5BZyFHPtEvNIg=.0244a9d4-e242-45ce-b26a-1bad65f5f34a@github.com>

On Fri, 20 Dec 2024 18:40:18 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
>> 
>> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
>> 
>> GenShen:
>> Before:
>> 
>> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
>> 
>> 
>> After:
>> 
>> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
>> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
>> 
>> 
>> Shenandoah:
>> Before:
>> 
>> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
>> 
>> After:
>> 
>> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
>> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
>> 
>> 
>> Additional changes:
>> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
>> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
>> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
>> * Clean up FullGC code, remove duplicate code.
>> 
>> ...
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1211:
> 
>> 1209:       // Only reset for young generation, bitmap for old generation must be retained,
>> 1210:       // except there is collection(global/old/degen/full) trigged to collect regions in old gen.
>> 1211:       heap->young_generation()->reset_mark_bitmap<false>();
> 
> Shouldn't it be safe to reset young region bitmaps even when old marking is in progress?

Not really, if old marking is in progress, but current cycle is not bootstrap cycle, it means previous old collection has been cancelled to deal with allocation failure, control thread will try to resume old collection agin which will resume old marking again.

> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 66:
> 
>> 64:         // Reset live data and set TAMS optimistically. We would recheck these under the pause
>> 65:         // anyway to capture any updates that happened since now.
>> 66:         _ctx->capture_top_at_mark_start(region);
> 
> Full GC used to do this unconditionally for all affiliated regions. Do we not still need that to happen?

I will double check this, I'm not 100% sure

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894506921
PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894507300

From xpeng at openjdk.org  Sat Dec 21 00:08:35 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Sat, 21 Dec 2024 00:08:35 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
In-Reply-To: <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
Message-ID: <HDxk35UX6mJ7TCN4j8OkVhA0tzxCDg43xl_WShiQJ7g=.05ee587a-c102-4f6e-9707-7a413973433c@github.com>

On Fri, 20 Dec 2024 18:44:45 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
>> 
>> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
>> 
>> GenShen:
>> Before:
>> 
>> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
>> 
>> 
>> After:
>> 
>> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
>> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
>> 
>> 
>> Shenandoah:
>> Before:
>> 
>> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
>> 
>> After:
>> 
>> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
>> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
>> 
>> 
>> Additional changes:
>> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
>> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
>> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
>> * Clean up FullGC code, remove duplicate code.
>> 
>> ...
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 58:
> 
>> 56:     if (PREPARE_FOR_CURRENT_CYCLE) {
>> 57:       if (region->need_bitmap_reset() && _heap->is_bitmap_slice_committed(region)) {
>> 58:         _ctx->clear_bitmap(region);
> 
> Should this also `region->unset_need_bitmap_reset()`?

It is for current cycles, bitmaps will be dirty anyway, for next cycle reset will be needed, so the flag can't be unset here

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894511194

From wkemper at openjdk.org  Sat Dec 21 00:21:14 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 21 Dec 2024 00:21:14 GMT
Subject: RFR: 8346737: GenShen: Generational memory pools should not report
 zero for maximum capacity
Message-ID: <AomKqVtaZyIPew-8KmxeQ8pk5lu-kZI06ZmHHFZX53Q=.3df58676-4df7-4dfb-9c17-a1bf5eeca0a0@github.com>

Clean backport.

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

Commit messages:
 - Backport 249f141211c94afcce70d9d536d84e108e07b4e5

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

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

From wkemper at openjdk.org  Sat Dec 21 00:25:01 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 21 Dec 2024 00:25:01 GMT
Subject: Integrated: 8346737: GenShen: Generational memory pools should not
 report zero for maximum capacity
In-Reply-To: <AomKqVtaZyIPew-8KmxeQ8pk5lu-kZI06ZmHHFZX53Q=.3df58676-4df7-4dfb-9c17-a1bf5eeca0a0@github.com>
References: <AomKqVtaZyIPew-8KmxeQ8pk5lu-kZI06ZmHHFZX53Q=.3df58676-4df7-4dfb-9c17-a1bf5eeca0a0@github.com>
Message-ID: <5uGVmo-KlqSwVcndSlBjBFuLHMrOuc4xC4ORKuwFyc8=.1df753da-a1b4-43aa-aa12-1f83bfbc57dc@github.com>

On Sat, 21 Dec 2024 00:16:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 3c538ce3
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/3c538ce3ccd1fb49b4e632b6ce652874ef045d21
Stats:     6 lines in 2 files changed: 0 ins; 6 del; 0 mod

8346737: GenShen: Generational memory pools should not report zero for maximum capacity

Backport-of: 249f141211c94afcce70d9d536d84e108e07b4e5

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

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

From wkemper at openjdk.org  Sat Dec 21 00:30:35 2024
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 21 Dec 2024 00:30:35 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
In-Reply-To: <dM5MCVZSF9knRaGdmymF34oknNNnnG5BZyFHPtEvNIg=.0244a9d4-e242-45ce-b26a-1bad65f5f34a@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
 <dM5MCVZSF9knRaGdmymF34oknNNnnG5BZyFHPtEvNIg=.0244a9d4-e242-45ce-b26a-1bad65f5f34a@github.com>
Message-ID: <c7jTu7X5Lo8EpAlp1rywuDMhok7RnaQalgphByITXy4=.78d476a9-1ec3-49f7-ab79-3b5b01e79ea3@github.com>

On Fri, 20 Dec 2024 23:51:58 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp line 1211:
>> 
>>> 1209:       // Only reset for young generation, bitmap for old generation must be retained,
>>> 1210:       // except there is collection(global/old/degen/full) trigged to collect regions in old gen.
>>> 1211:       heap->young_generation()->reset_mark_bitmap<false>();
>> 
>> Shouldn't it be safe to reset young region bitmaps even when old marking is in progress?
>
> Not really, if old marking is in progress, but current cycle is not bootstrap cycle, it means previous old collection has been cancelled to deal with allocation failure, control thread will try to resume old collection agin which will resume old marking again.

The old cycle may be preempted by young collections, but it is only really _cancelled_ by global cycles or full GCs. Control thread will resume old marking, but this operates independently from young bitmap regions. I think we can reset young region bitmaps even when concurrent old marking is on going.

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 58:
>> 
>>> 56:     if (PREPARE_FOR_CURRENT_CYCLE) {
>>> 57:       if (region->need_bitmap_reset() && _heap->is_bitmap_slice_committed(region)) {
>>> 58:         _ctx->clear_bitmap(region);
>> 
>> Should this also `region->unset_need_bitmap_reset()`?
>
> It is for current cycle, bitmaps will be dirty anyway, for next cycle reset will be needed, so the flag can't be unset here

Got it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894516552
PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894516866

From xpeng at openjdk.org  Sat Dec 21 01:29:42 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Sat, 21 Dec 2024 01:29:42 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
In-Reply-To: <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
Message-ID: <CjpMtluFeq7hHXe6mp5dBldPIy8jvP2_ADJWa2_wkzk=.9bf31b03-0af2-4cce-8208-980d50167920@github.com>

On Fri, 20 Dec 2024 18:55:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
>> 
>> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
>> 
>> GenShen:
>> Before:
>> 
>> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
>> 
>> 
>> After:
>> 
>> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
>> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
>> 
>> 
>> Shenandoah:
>> Before:
>> 
>> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
>> 
>> After:
>> 
>> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
>> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
>> 
>> 
>> Additional changes:
>> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
>> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
>> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
>> * Clean up FullGC code, remove duplicate code.
>> 
>> ...
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp line 161:
> 
>> 159:   }
>> 160: 
>> 161:   entry_reset_after_collect();
> 
> Not sure we want to reset old region bitmaps after old marking is compete. Shenandoah opportunistically uses the bitmap for old regions during remembered set scan (it's faster than walking the heap).

The 'reset-after' won't reset bitmaps for old gen, it only reset for young gen, which is skipped in bootstrap cycle

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894528758

From xpeng at openjdk.org  Sat Dec 21 01:50:42 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Sat, 21 Dec 2024 01:50:42 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
In-Reply-To: <c7jTu7X5Lo8EpAlp1rywuDMhok7RnaQalgphByITXy4=.78d476a9-1ec3-49f7-ab79-3b5b01e79ea3@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
 <dM5MCVZSF9knRaGdmymF34oknNNnnG5BZyFHPtEvNIg=.0244a9d4-e242-45ce-b26a-1bad65f5f34a@github.com>
 <c7jTu7X5Lo8EpAlp1rywuDMhok7RnaQalgphByITXy4=.78d476a9-1ec3-49f7-ab79-3b5b01e79ea3@github.com>
Message-ID: <ir7v8yCpyQhZC2CAz6q7JjQgjnYEHLwCM3oLPQN740w=.9e88f4ed-a264-40d7-85f2-1e80b3683b91@github.com>

On Sat, 21 Dec 2024 00:26:40 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Not really, if old marking is in progress, but current cycle is not bootstrap cycle, it means previous old collection has been cancelled to deal with allocation failure, control thread will try to resume old collection agin which will resume old marking again.
>
> The old cycle may be preempted by young collections, but it is only really _cancelled_ by global cycles or full GCs. Control thread will resume old marking, but this operates independently from young bitmap regions. I think we can reset young region bitmaps even when concurrent old marking is on going.

I think we are taking about the same thing, old gen could be preempted by young gc and resumed after the cycle. I have seem crash from caused by this, an old gc was bootstrapped but it was preempted/canceled multiple times right after the old gc started, eventually caused a crash from verifier because it expected the object in young is marked. I will share the gc log on slack later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1894532058

From xpeng at openjdk.org  Wed Dec 25 08:11:20 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 25 Dec 2024 08:11:20 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v2]
In-Reply-To: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
Message-ID: <MKeDQ5ma0ljs95ZYmMJHfy78-LV_6Wwf6Y-nc16bgQo=.e281065c-dece-4210-8b4c-cc139cc1153e@github.com>

> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
> 
> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
> 
> GenShen:
> Before:
> 
> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
> 
> 
> After:
> 
> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
> 
> 
> Shenandoah:
> Before:
> 
> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
> 
> After:
> 
> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
> 
> 
> Additional changes:
> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
> * Clean up FullGC code, remove duplicate code.
> 
> Additional tests:
> - [x] CONF=macosx-aarch64-server-fastdebug make test T...

Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22778/files
  - new: https://git.openjdk.org/jdk/pull/22778/files/2b9f28a1..36f14832

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

  Stats: 22 lines in 5 files changed: 2 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/22778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22778/head:pull/22778

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

From xpeng at openjdk.org  Thu Dec 26 17:07:39 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 26 Dec 2024 17:07:39 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v2]
In-Reply-To: <dM5MCVZSF9knRaGdmymF34oknNNnnG5BZyFHPtEvNIg=.0244a9d4-e242-45ce-b26a-1bad65f5f34a@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
 <dM5MCVZSF9knRaGdmymF34oknNNnnG5BZyFHPtEvNIg=.0244a9d4-e242-45ce-b26a-1bad65f5f34a@github.com>
Message-ID: <S_rrFANm5x4jikWffgS6xI4IRLN4PRyg8PcZwrPRL20=.f6c47268-9af8-4bfd-82dd-11e83f6c00d0@github.com>

On Fri, 20 Dec 2024 23:53:09 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 66:
>> 
>>> 64:         // Reset live data and set TAMS optimistically. We would recheck these under the pause
>>> 65:         // anyway to capture any updates that happened since now.
>>> 66:         _ctx->capture_top_at_mark_start(region);
>> 
>> Full GC used to do this unconditionally for all affiliated regions. Do we not still need that to happen?
>
> I will double check this, I'm not 100% sure

I have update code to handle old GC differently, now the behavior should be same as before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1898022673

From xpeng at openjdk.org  Thu Dec 26 17:07:40 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 26 Dec 2024 17:07:40 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v2]
In-Reply-To: <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
 <__kORuPC0guQED9-jn2Xg9CFIJ15wVRojwZoy_VqcPs=.0e5c812f-9e4e-4396-8acd-1e84a5e598c5@github.com>
Message-ID: <9QFHoPnlL-dJ8seRqDpmPghTPu5WfE6h0T_8KXZeSaE=.60ec6946-dc55-4ea1-ab0a-c76178e8c24b@github.com>

On Fri, 20 Dec 2024 18:56:38 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.hpp line 269:
> 
>> 267:   ShenandoahSharedFlag _recycling; // Used to indicate that the region is being recycled; see try_recycle*().
>> 268: 
>> 269:   bool _need_bitmap_reset;
> 
> Nit pick, but I think this would read better as `_needs_bitmap_reset`.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22778#discussion_r1898022147

From xpeng at openjdk.org  Mon Dec 30 22:54:27 2024
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Mon, 30 Dec 2024 22:54:27 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
 [v3]
In-Reply-To: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
References: <6duTgo8vKHyCUnasOsrHp341B2krxcK8jNogKjX09gs=.af63669e-9c8d-4f17-b055-bf3a03a9618e@github.com>
Message-ID: <OfmB9ehsC_CJI5Pv7JfEsyieZndfEPUa7wiDIz3PDpw=.5bfc80b3-11de-4af4-a095-55958b17da3d@github.com>

> Reset marking bitmaps after collection cycle; for GenShen only do this for young generation, also choose not do this for Degen and full GC since both are running at safepoint, we should leave safepoint as ASAP.
> 
> I have run same workload for 30s with Shenandoah in generational mode and classic mode, average average time of concurrent reset dropped significantly since in most case bitmap for young gen should have been reset after pervious concurrent cycle finishes if there is no need to preserve bitmap states.
> 
> GenShen:
> Before:
> 
> [33.342s][info][gc,stats    ] Concurrent Reset               =    0.023 s (a =     1921 us) (n =    12) (lvls, us =      133,      385,     1191,     1836,     8878)
> 
> 
> After:
> 
> [33.597s][info][gc,stats    ] Concurrent Reset               =    0.004 s (a =      317 us) (n =    13) (lvls, us =       58,      119,      217,      410,      670)
> [33.597s][info][gc,stats    ] Concurrent Reset After Collect =    0.018 s (a =     1365 us) (n =    13) (lvls, us =       91,      186,      818,     1836,     3872)
> 
> 
> Shenandoah:
> Before:
> 
> [33.144s][info][gc,stats    ] Concurrent Reset               =    0.014 s (a =     1067 us) (n =    13) (lvls, us =      139,      277,      898,     1328,     2118)
> 
> After:
> 
> [33.128s][info][gc,stats    ] Concurrent Reset               =    0.003 s (a =      225 us) (n =    13) (lvls, us =       32,       92,      137,      295,      542)
> [33.128s][info][gc,stats    ] Concurrent Reset After Collect =    0.009 s (a =      661 us) (n =    13) (lvls, us =       92,      160,      594,      896,     1661)
> 
> 
> Additional changes:
> * Remove `ShenandoahResetBitmapClosure` and  `ShenandoahPrepareForMarkClosure`, merge the code with `ShenandoahResetBitmapClosure`, saving one iteration over all the regions. 
> * Use API `ShenandoahGeneration::parallel_heap_region_iterate_free` to iterate the regions, two benefits from this:
>   -  Underneath it calls `ShenandoahHeap::parallel_heap_region_iterate`, which is faster for very light tasks, see https://bugs.openjdk.org/browse/JDK-8337154
>   -  `ShenandoahGeneration::parallel_heap_region_iterate_free` decorate the closure with `ShenandoahExcludeRegionClosure`, which simplifies the code in closure.
> * When `_do_old_gc_bootstrap is true`, instead of reset mark bitmap for old gen separately, simply reset the global generations, so we don't need walk the all regions twice. 
> * Clean up FullGC code, remove duplicate code.
> 
> Additional tests:
> - [x] CONF=macosx-aarch64-server-fastdebug make test T...

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

 - Merge branch 'openjdk:master' into reset-bitmap
 - Address review comments
 - Merge branch 'openjdk:master' into reset-bitmap
 - Remove ShenandoahResetUpdateRegionStateClosure
 - Always set_mark_incomplete when reset mark bitmap
 - Fix
 - Add comments
 - fix
 - Not reset_mark_bitmap after cycle when  is_concurrent_old_mark_in_progress or is_prepare_for_old_mark_in_progress
 - Not invoke set_mark_incomplete when reset bitmap after cycle
 - ... and 7 more: https://git.openjdk.org/jdk/compare/673b06be...f82fdfaa

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22778/files
  - new: https://git.openjdk.org/jdk/pull/22778/files/36f14832..f82fdfaa

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

  Stats: 4760 lines in 68 files changed: 4271 ins; 269 del; 220 mod
  Patch: https://git.openjdk.org/jdk/pull/22778.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22778/head:pull/22778

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