From azafari at openjdk.org  Tue Apr  1 08:30:36 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 1 Apr 2025 08:30:36 GMT
Subject: Integrated: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag
In-Reply-To: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
Message-ID: <F_2UK8AkrPOH--FPQwKkMFf1eRPQdCnRJ6PDsm4S6ew=.9578efb3-9004-4f9e-9c93-c0e0186f931c@github.com>

On Tue, 25 Feb 2025 09:49:41 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
> Tests:
> linux-x64-debug, gtest:NMT* and runtime/NMT*

This pull request has now been integrated.

Changeset: aff5aa72
Author:    Afshin Zafari <azafari at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aff5aa72bbf4ecea614339483581093a67efa265
Stats:     27 lines in 14 files changed: 6 ins; 1 del; 20 mod

8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag

Reviewed-by: jsjolen, gziemski

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

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

From azafari at openjdk.org  Tue Apr  1 08:30:36 2025
From: azafari at openjdk.org (Afshin Zafari)
Date: Tue, 1 Apr 2025 08:30:36 GMT
Subject: RFR: 8350566: NMT: add size parameter to
 MemTracker::record_virtual_memory_tag [v5]
In-Reply-To: <0SlK7ixxGv5N7-LQnC7SwgpcK4Oz_9_H24qnrGPrTpc=.9bfd6434-6a48-4563-9dd6-66cff70dafe7@github.com>
References: <LnJ-TGOGBbi8qHrNCBXJQvjCTVBJVhZbsWPCqQvfZj8=.33dc5218-4df8-4255-b35b-b5862759f184@github.com>
 <0SlK7ixxGv5N7-LQnC7SwgpcK4Oz_9_H24qnrGPrTpc=.9bfd6434-6a48-4563-9dd6-66cff70dafe7@github.com>
Message-ID: <B846uKANBkpRiy-yQnUvgMISASNXUN71a9j0Dm1XG24=.4d28ac65-bdcf-4716-b20d-ea4a83d08e40@github.com>

On Fri, 7 Mar 2025 16:06:32 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> With the `size` parameter there will be no need to traverse/go through the nodes between the base and end of the region.
>> Tests:
>> linux-x64-debug, gtest:NMT* and runtime/NMT*
>
> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge remote-tracking branch 'origin/master' into _8350566_size_par_set_tag
>  - new fix.
>  - fixed build problem.
>  - ReservedSpace is accepted as param.
>  - applied also to VMT.
>  - 8350566: NMT: add size parameter to MemTracker::record_virtual_memory_tag

GHA failures are not relevant.
Thanks for reviews @jdksjolen and @gerard-ziemski.

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

PR Comment: https://git.openjdk.org/jdk/pull/23770#issuecomment-2768577688

From stefank at openjdk.org  Tue Apr  1 15:27:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 1 Apr 2025 15:27:20 GMT
Subject: RFR: 8344883: Do not use mtNone if we know the tag type [v2]
In-Reply-To: <PN-WLTKjrVKml2F8i8D14lEw97E_vwsGlmG5p4rCeJA=.69d931c4-1045-4985-a851-60f2d2107a5a@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <uYMlzzYw1wove17ssLu3qEmgW0yRZJrmE9hytBi5OZ4=.3dd36732-69cf-45cd-9ebb-7ea80f6c8d79@github.com>
 <lPQKypF6fyHVJkzgY8QBvUpcazSVFwsGF-e85y5z8P8=.7060164b-1931-4299-ae6b-50e8761153c6@github.com>
 <PN-WLTKjrVKml2F8i8D14lEw97E_vwsGlmG5p4rCeJA=.69d931c4-1045-4985-a851-60f2d2107a5a@github.com>
Message-ID: <bIpQ1q5mQxcHHD8rHmn5ZwerfJz5D44kMtAlrryDZ8w=.42bbca7b-3c93-4d1c-ae4f-016bc2296e5c@github.com>

On Mon, 31 Mar 2025 21:10:01 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> src/hotspot/share/runtime/safepointMechanism.cpp line 60:
>> 
>>> 58:     const size_t page_size = os::vm_page_size();
>>> 59:     const size_t allocation_size = 2 * page_size;
>>> 60:     char* polling_page = os::reserve_memory(allocation_size, mtSafepoint, !ExecMem);
>> 
>> Suggestion:
>> 
>>     char* polling_page = os::reserve_memory(allocation_size, mtSafepoint);
>
> I think here we need to keep `!ExecMem` since it is a parameter.

I don't understand what you mean with that. `ExecMem` is a constant and os::reserve_memory has an optional parameter `executable`.

>> src/hotspot/share/utilities/debug.cpp line 715:
>> 
>>> 713: #ifdef CAN_SHOW_REGISTERS_ON_ASSERT
>>> 714: void initialize_assert_poison() {
>>> 715:   char* page = os::reserve_memory(os::vm_page_size(), mtInternal, !ExecMem);
>> 
>> Suggestion:
>> 
>>   char* page = os::reserve_memory(os::vm_page_size(), mtInternal);
>
> Again, `ExecMem` is a parameter.

Same comment as above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2023089682
PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2023090093

From gziemski at openjdk.org  Tue Apr  1 16:40:36 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 1 Apr 2025 16:40:36 GMT
Subject: RFR: 8344883: Do not use mtNone if we know the tag type [v2]
In-Reply-To: <lPQKypF6fyHVJkzgY8QBvUpcazSVFwsGF-e85y5z8P8=.7060164b-1931-4299-ae6b-50e8761153c6@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <uYMlzzYw1wove17ssLu3qEmgW0yRZJrmE9hytBi5OZ4=.3dd36732-69cf-45cd-9ebb-7ea80f6c8d79@github.com>
 <lPQKypF6fyHVJkzgY8QBvUpcazSVFwsGF-e85y5z8P8=.7060164b-1931-4299-ae6b-50e8761153c6@github.com>
Message-ID: <wIFIy5NRbVMTw-LuSaONw2ZiDc5gtUwIghMzIuskFqo=.d28349fe-623b-4fb2-b9c5-032e106cda00@github.com>

On Fri, 28 Mar 2025 08:03:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   work
>
> test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 94:
> 
>> 92:     const size_t page_sz = os::vm_page_size();
>> 93:     const size_t size = num_pages * page_sz;
>> 94:     char* base = os::reserve_memory(size, mtThreadStack, !ExecMem);
> 
> Suggestion:
> 
>     char* base = os::reserve_memory(size, mtThreadStack);

ExecMem is a parameter, which could be false, so that would make it `true` for `reserve_memory`, so need to keep it?

> test/hotspot/gtest/runtime/test_committed_virtualmemory.cpp line 162:
> 
>> 160:     const size_t num_pages = 4;
>> 161:     const size_t size = num_pages * page_sz;
>> 162:     char* base = os::reserve_memory(size, mtTest, !ExecMem);
> 
> Suggestion:
> 
>     char* base = os::reserve_memory(size, mtTest);

ExecMem is a parameter, that could be false.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2023206394
PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2023207421

From gziemski at openjdk.org  Tue Apr  1 16:47:35 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 1 Apr 2025 16:47:35 GMT
Subject: RFR: 8344883: Do not use mtNone if we know the tag type [v2]
In-Reply-To: <lPQKypF6fyHVJkzgY8QBvUpcazSVFwsGF-e85y5z8P8=.7060164b-1931-4299-ae6b-50e8761153c6@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <uYMlzzYw1wove17ssLu3qEmgW0yRZJrmE9hytBi5OZ4=.3dd36732-69cf-45cd-9ebb-7ea80f6c8d79@github.com>
 <lPQKypF6fyHVJkzgY8QBvUpcazSVFwsGF-e85y5z8P8=.7060164b-1931-4299-ae6b-50e8761153c6@github.com>
Message-ID: <4FA724K9XEmS9Fyw89-NEkkYHyxGl03Ln-401PP_eOs=.4c782592-ee41-4758-94a1-4b79b8e81481@github.com>

On Fri, 28 Mar 2025 08:18:12 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   work
>
> src/hotspot/share/memory/allocation.inline.hpp line 61:
> 
>> 59:   size_t size = size_for(length);
>> 60: 
>> 61:   char* addr = os::reserve_memory(size, mem_tag, !ExecMem);
> 
> Suggestion:
> 
>   char* addr = os::reserve_memory(size, mem_tag);

ExecMem can be false?

> src/hotspot/share/memory/allocation.inline.hpp line 78:
> 
>> 76:   size_t size = size_for(length);
>> 77: 
>> 78:   char* addr = os::reserve_memory(size, mem_tag, !ExecMem);
> 
> Suggestion:
> 
>   char* addr = os::reserve_memory(size, mem_tag);

ExecMem can be false?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2023215520
PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2023217448

From gziemski at openjdk.org  Tue Apr  1 16:50:24 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 1 Apr 2025 16:50:24 GMT
Subject: RFR: 8344883: Do not use mtNone if we know the tag type [v2]
In-Reply-To: <KtVdJt4o0O65-L2uDUjLQ8SfmpDywhTHPA21w5KElOQ=.31cf9e68-92bb-45e5-bd5a-c9d98a87a53e@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <uYMlzzYw1wove17ssLu3qEmgW0yRZJrmE9hytBi5OZ4=.3dd36732-69cf-45cd-9ebb-7ea80f6c8d79@github.com>
 <lPQKypF6fyHVJkzgY8QBvUpcazSVFwsGF-e85y5z8P8=.7060164b-1931-4299-ae6b-50e8761153c6@github.com>
 <fekK09wkt5VqUd3LQ9PQIt8W9_pDXS1T0T17fhX6hL4=.4512ff51-24c1-49c6-8b32-2b6d216d2363@github.com>
 <KtVdJt4o0O65-L2uDUjLQ8SfmpDywhTHPA21w5KElOQ=.31cf9e68-92bb-45e5-bd5a-c9d98a87a53e@github.com>
Message-ID: <uUXz8bC7vlGgT5-zp6qEnPsYAZFXzPcKLT6UiiNIWRk=.f0192ecc-5843-44af-80ef-73d9a3c12546@github.com>

On Mon, 31 Mar 2025 19:24:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I wasn't sure what that is here, we can do this in a follow up?
>
> My suggestion was to change `attempt_reserve_memory_between` to take MemTag as an argument. It's OK to do that as a follow-up PR.

I decided to do this now, since I had to go through many files anyhow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2023222075

From wkemper at openjdk.org  Tue Apr  1 17:43:08 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Apr 2025 17:43:08 GMT
Subject: Integrated: 8347617: Shenandoah: Use consistent name for update
 references phase
In-Reply-To: <kFEju-qrtsJJWDY3cbCsGxjXiIlKptPyo5TOeNLNhSg=.a829637c-335c-4881-8438-f61e12efb6a1@github.com>
References: <kFEju-qrtsJJWDY3cbCsGxjXiIlKptPyo5TOeNLNhSg=.a829637c-335c-4881-8438-f61e12efb6a1@github.com>
Message-ID: <Bp4iKxbuSV_pfrImgvOcIh7vBR4Hb0iSS1C7UYXRcow=.4d8bc7b9-55fc-433b-bff6-0d29cd628896@github.com>

On Fri, 28 Mar 2025 21:06:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Trivial merge conflict.

This pull request has now been integrated.

Changeset: 9da18aa6
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/9da18aa6cd98f37e7c528022d8870b6b9a52567c
Stats:     64 lines in 18 files changed: 0 ins; 0 del; 64 mod

8347617: Shenandoah: Use consistent name for update references phase

Reviewed-by: kdnilsen
Backport-of: 0330ca4221ba7bacb0eaeed1a8cdc3d5c3653a83

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

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

From gziemski at openjdk.org  Tue Apr  1 18:02:03 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 1 Apr 2025 18:02:03 GMT
Subject: RFR: 8344883: Do not use mtNone if we know the tag type [v5]
In-Reply-To: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
Message-ID: <DgXSIac2BUiksYWrv80uCZ6-MMTs1vgC8xxwko1rm68=.72213aa4-4667-4c82-bf6e-418a3e9f3c39@github.com>

> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  Stefan's feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24282/files
  - new: https://git.openjdk.org/jdk/pull/24282/files/40cb4384..f0ccc7f7

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

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

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

From wkemper at openjdk.org  Tue Apr  1 18:21:12 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Apr 2025 18:21:12 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>

On Mon, 31 Mar 2025 03:17:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

Changes requested by wkemper (Reviewer).

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

> 76:   _live_data(0),
> 77:   _critical_pins(0),
> 78:   _mixed_candidate_garbage_words(0),

Do we need a new field to track this? During `final_mark`, we call `increase_live_data_alloc_words` to add `TAMS + top` to `_live_data` to account for objects allocated during mark. Could we "fix" `get_live_data` so that it always returned marked objects (counted by `increase_live_data_gc_words`) _plus_ `top - TAMS`. This way, the live data would not become stale after `final_mark` and we wouldn't have another field to manage. What do you think?

src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 159:

> 157: 
> 158: inline size_t ShenandoahHeapRegion::get_mixed_candidate_live_data_bytes() const {
> 159:   assert(SafepointSynchronize::is_at_safepoint(), "Should be at Shenandoah safepoint");

Could we use `shenandoah_assert_safepoint` here (and other places) instead?

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

PR Review: https://git.openjdk.org/jdk/pull/24319#pullrequestreview-2733584314
PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2023461623
PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2023396124

From wkemper at openjdk.org  Tue Apr  1 18:50:12 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Apr 2025 18:50:12 GMT
Subject: RFR: 8348610: GenShen: TestShenandoahEvacuationInformationEvent failed
 with setRegions >= regionsFreed: expected 1 >= 57
Message-ID: <hGdz_BBNr0T6byQ9ahlu4W791Q1yXLoGI1epbZXs7zE=.626a024f-d5a8-46bd-8b32-545258939703@github.com>

Clean, but contains follow up fix.

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

Commit messages:
 - 8349639: jfr/event/gc/detailed/TestShenandoahEvacuationInformationEvent.java fails to compile after JDK-8348610
 - 8348610: GenShen: TestShenandoahEvacuationInformationEvent failed with setRegions >= regionsFreed: expected 1 >= 57

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

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

From wkemper at openjdk.org  Tue Apr  1 19:06:58 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Apr 2025 19:06:58 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when not
 the fault of triggering heuristic
Message-ID: <7JxoAe6FagKRFE7pmYXcudYVDKDMIv-ncUNt5b-LYuE=.78c2a17b-9fb3-4764-8b8c-c12cd3275f82@github.com>

Trivial conflict. Has follow on issue.

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

Commit messages:
 - 8350889: GenShen: Break out of infinite loop of old GC cycles
 - 8348594: Shenandoah: Do not penalize for degeneration when not the fault of triggering heuristic

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

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

From gziemski at openjdk.org  Tue Apr  1 20:36:21 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 1 Apr 2025 20:36:21 GMT
Subject: RFR: 8344883: Do not use mtNone if we know the tag type [v2]
In-Reply-To: <lPQKypF6fyHVJkzgY8QBvUpcazSVFwsGF-e85y5z8P8=.7060164b-1931-4299-ae6b-50e8761153c6@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <uYMlzzYw1wove17ssLu3qEmgW0yRZJrmE9hytBi5OZ4=.3dd36732-69cf-45cd-9ebb-7ea80f6c8d79@github.com>
 <lPQKypF6fyHVJkzgY8QBvUpcazSVFwsGF-e85y5z8P8=.7060164b-1931-4299-ae6b-50e8761153c6@github.com>
Message-ID: <k-Ay_gyI-rvOHyQt92bjHWKqzatLmWhaAW33WbvAkok=.a99ebb84-0ca4-49c2-b3d2-6004fc1d3505@github.com>

On Fri, 28 Mar 2025 08:25:08 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   work
>
> I went over the patch and added suggestions for places where I think you're using the wrong tag, or where I think it is obvious that there's a better tag than mtNone. I've also suggested removal of the now redundant 'executable' argument, which I want to see as little of as possible given that it is a wart on the memory reservation APIs (IMHO).

@stefank After changing various `mtNone` tags to `mtTest` we know are seeing build failures:


#  Internal Error (/Users/runner/work/jdk/jdk/src/hotspot/share/nmt/virtualMemoryTracker.cpp:427), pid=79835, tid=8707
#  assert(reserved_rgn->mem_tag() == mtNone) failed: Overwrite memory tag (should be mtNone, is: "Test")


I would like to revert to the last passing commit [40cb438](https://github.com/openjdk/jdk/pull/24282/commits/40cb4384f17ad63c1374ea785f76e415a44eb426) and re-do this step in a follow-up.

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2770608945

From gziemski at openjdk.org  Tue Apr  1 20:40:36 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 1 Apr 2025 20:40:36 GMT
Subject: RFR: 8344883: Do not use mtNone if we know the tag type [v6]
In-Reply-To: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
Message-ID: <Nz1MQa33wD8ikQf3wpD_mM0GhJfpytfgZPQxHadHK5s=.0bad993f-2175-4c1f-b7dc-5a0ad31a94c2@github.com>

> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Stefan's feedback"
  
  This reverts commit f0ccc7f79e5a821cf632d1e0e898dad3254a2f0b.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24282/files
  - new: https://git.openjdk.org/jdk/pull/24282/files/f0ccc7f7..c0181d35

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

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

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

From gziemski at openjdk.org  Tue Apr  1 20:53:06 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 1 Apr 2025 20:53:06 GMT
Subject: RFR: 8344883: Do not use mtNone if we know the tag type [v7]
In-Reply-To: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
Message-ID: <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>

> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  remove default value parameter if it's false from os::reserve_memory

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24282/files
  - new: https://git.openjdk.org/jdk/pull/24282/files/c0181d35..5de1d560

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

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

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

From gziemski at openjdk.org  Tue Apr  1 21:02:01 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 1 Apr 2025 21:02:01 GMT
Subject: RFR: 8344883: Do not use mtNone if we know the tag type [v7]
In-Reply-To: <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
Message-ID: <XBq0ITCYIe2B-NpjcH6AiExtycc9JXEHLCHndLVJPdw=.a8a77d8e-352e-4198-974e-d124f828de4b@github.com>

On Tue, 1 Apr 2025 20:53:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove default value parameter if it's false from os::reserve_memory

Filed  [Skip default value parameter if it's false from os::reserve_memory_special and os::attempt_reserve_memory_at()](https://bugs.openjdk.org/browse/JDK-8353477) to address the other APIs using false for the exec parameter with default value.

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2770670565

From gziemski at openjdk.org  Tue Apr  1 21:11:16 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 1 Apr 2025 21:11:16 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v7]
In-Reply-To: <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
Message-ID: <RWZa7xTB0dhaw8_lF7euSKgeCkAu5y485_jj4Zh7Pgw=.a3c3ce04-00ff-4e94-aaab-109c60932373@github.com>

On Tue, 1 Apr 2025 20:53:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove default value parameter if it's false from os::reserve_memory

Filed [Replace mtNone with actual values, when known.](https://bugs.openjdk.org/browse/JDK-8353480) to provide real values, but we will need to proceed with caution. It is not as simple as changing all mtNone to mtTest for example (even in gtests)

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2770691388

From wkemper at openjdk.org  Tue Apr  1 22:27:07 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Apr 2025 22:27:07 GMT
Subject: RFR: 8351892: GenShen: Remove enforcement of generation sizes [v2]
In-Reply-To: <qWgs9OTfISsQ98vhfnlTaKF8f1XliQ3DSrbzMAVt2Gk=.4e801c17-599c-4c75-81c2-ee767e9bb4a4@github.com>
References: <F8xmi9sPA_VnQzddkxNa6paM_CVl8KYdybOWqmmqbZ0=.9b35ecc8-b0f7-48d5-a951-86c4f56a1c9c@github.com>
 <-BEi4FpPLjKx07-J7ix9fHkKVhkcYylA0ojI-a1zrJs=.a3c073d3-7e52-46fd-8e2a-1ea601bd2074@github.com>
 <qWgs9OTfISsQ98vhfnlTaKF8f1XliQ3DSrbzMAVt2Gk=.4e801c17-599c-4c75-81c2-ee767e9bb4a4@github.com>
Message-ID: <Mz97u2ny4Su0xQsreJIua-cBGhDZr73ScI-9pwJ6UTE=.e7009739-e22b-4ccd-8c79-f5bd1037db7a@github.com>

On Sat, 29 Mar 2025 00:08:06 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't let old have the entire heap
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalFullGC.cpp line 120:
> 
>> 118:   if (old_capacity > old_usage) {
>> 119:     size_t excess_old_regions = (old_capacity - old_usage) / ShenandoahHeapRegion::region_size_bytes();
>> 120:     gen_heap->transfer_to_young(excess_old_regions);
> 
> should we assert result is successful?  Or replace with force_transfer?  (just seems bad practice to ignore a status result)

Yes, will try an assert here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24268#discussion_r2023754542

From wkemper at openjdk.org  Tue Apr  1 22:44:35 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Apr 2025 22:44:35 GMT
Subject: RFR: 8351892: GenShen: Remove enforcement of generation sizes [v3]
In-Reply-To: <F8xmi9sPA_VnQzddkxNa6paM_CVl8KYdybOWqmmqbZ0=.9b35ecc8-b0f7-48d5-a951-86c4f56a1c9c@github.com>
References: <F8xmi9sPA_VnQzddkxNa6paM_CVl8KYdybOWqmmqbZ0=.9b35ecc8-b0f7-48d5-a951-86c4f56a1c9c@github.com>
Message-ID: <m36lGEpGTlMVGE5sohwSdpvBoGGtRiTVB8QZ8grK_Es=.56074fe4-6f96-4849-9975-6be9b822d543@github.com>

> * The option to configure minimum and maximum sizes for the young generation have been combined into `ShenandoahInitYoungPercentage`.
> * The remaining functionality in `shGenerationSizer` wasn't enough to warrant being its own class, so the functionality was rolled into `shGenerationalHeap`.

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

 - Simplify confusing (and confused) comment
 - Assert that region transfers succeed when expected
 - Merge remote-tracking branch 'jdk/master' into stop-enforcing-gen-size-limits
 - Don't let old have the entire heap
 - Stop enforcing young/old generation sizes.
   
   Move what's left of generation sizing logic into shGenerationalHeap.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24268/files
  - new: https://git.openjdk.org/jdk/pull/24268/files/bc171089..33a2f19d

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

  Stats: 18299 lines in 378 files changed: 10486 ins; 6499 del; 1314 mod
  Patch: https://git.openjdk.org/jdk/pull/24268.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24268/head:pull/24268

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

From wkemper at openjdk.org  Tue Apr  1 22:44:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 1 Apr 2025 22:44:36 GMT
Subject: RFR: 8351892: GenShen: Remove enforcement of generation sizes [v2]
In-Reply-To: <qWgs9OTfISsQ98vhfnlTaKF8f1XliQ3DSrbzMAVt2Gk=.4e801c17-599c-4c75-81c2-ee767e9bb4a4@github.com>
References: <F8xmi9sPA_VnQzddkxNa6paM_CVl8KYdybOWqmmqbZ0=.9b35ecc8-b0f7-48d5-a951-86c4f56a1c9c@github.com>
 <-BEi4FpPLjKx07-J7ix9fHkKVhkcYylA0ojI-a1zrJs=.a3c073d3-7e52-46fd-8e2a-1ea601bd2074@github.com>
 <qWgs9OTfISsQ98vhfnlTaKF8f1XliQ3DSrbzMAVt2Gk=.4e801c17-599c-4c75-81c2-ee767e9bb4a4@github.com>
Message-ID: <XzRNn7p4_w_QVFAjivssZG9YtRbUEt3ajVaOqda5fao=.64e9c455-d78a-42fc-b420-951df04d565f@github.com>

On Sat, 29 Mar 2025 00:10:28 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't let old have the entire heap
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationalHeap.cpp line 134:
> 
>> 132:   ShenandoahHeap::initialize_heuristics();
>> 133: 
>> 134:   // Max capacity is the maximum _allowed_ capacity. This means the sum of the maximum
> 
> I don't understand the relevance of this comment.  Is there still a mximum allowed for old and a maximum allowed for young?

This comment stemmed from own confusion over fields and variables called _max_ `capacity` . I would like to rename the `_max_capacity` field to just `_capacity`. In my mind, the _max_ should be immutable, but that isn't how Shenandoah uses this field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24268#discussion_r2023766431

From stefank at openjdk.org  Wed Apr  2 07:39:23 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 2 Apr 2025 07:39:23 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v7]
In-Reply-To: <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
Message-ID: <hGSJrpRRefq6fMiNfcKVP5YdwZKXH7GR5yNlf8G8HmU=.60e43fea-ec31-48ce-8ecc-c34ce811df95@github.com>

On Tue, 1 Apr 2025 20:53:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove default value parameter if it's false from os::reserve_memory

You keep leaving comments that ExecMem is a parameter. That doesn't make sense. ExecMem is a constant.

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

PR Review: https://git.openjdk.org/jdk/pull/24282#pullrequestreview-2734939840

From stefank at openjdk.org  Wed Apr  2 07:53:22 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 2 Apr 2025 07:53:22 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v7]
In-Reply-To: <hGSJrpRRefq6fMiNfcKVP5YdwZKXH7GR5yNlf8G8HmU=.60e43fea-ec31-48ce-8ecc-c34ce811df95@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
 <hGSJrpRRefq6fMiNfcKVP5YdwZKXH7GR5yNlf8G8HmU=.60e43fea-ec31-48ce-8ecc-c34ce811df95@github.com>
Message-ID: <HXkHEJCkPZzLM7j1xDBPXnLY6nDSkwK2SoY6oPWANAY=.a9caded2-aad4-415c-9a15-a0cf0f77bec2@github.com>

On Wed, 2 Apr 2025 07:36:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove default value parameter if it's false from os::reserve_memory
>
> You keep leaving comments that ExecMem is a parameter. That doesn't make sense. ExecMem is a constant.

> @stefank After changing various `mtNone` tags to `mtTest` we now are seeing build failures:
> 
> ```
> #  Internal Error (/Users/runner/work/jdk/jdk/src/hotspot/share/nmt/virtualMemoryTracker.cpp:427), pid=79835, tid=8707
> #  assert(reserved_rgn->mem_tag() == mtNone) failed: Overwrite memory tag (should be mtNone, is: "Test")
> ```
> 
> I reverted to the last passing commit [40cb438](https://github.com/openjdk/jdk/pull/24282/commits/40cb4384f17ad63c1374ea785f76e415a44eb426) and re-do this step in a follow-up.

The problem was that you didn't do what I suggested. I suggested that you changed one occurrence to be mtMetaspace:
https://github.com/openjdk/jdk/pull/24282#discussion_r2018124074

But you changed it to be mtTest:
https://github.com/openjdk/jdk/pull/24282/commits/f0ccc7f79e5a821cf632d1e0e898dad3254a2f0b

and this causes the crash above.

Do you know that you can just accept the proposed changes in the GitHub UI? I think that would prevent bugs like this.

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2771625260

From stefank at openjdk.org  Wed Apr  2 08:48:27 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 2 Apr 2025 08:48:27 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v7]
In-Reply-To: <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
Message-ID: <kDuJ6qfeoJ3Dq3gVf9vhtv_htKrKoBXq6jAStsLPZu0=.4bf30094-4161-4edf-9f52-cd19d6347456@github.com>

On Tue, 1 Apr 2025 20:53:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove default value parameter if it's false from os::reserve_memory

So, there were two problems:
1) Is the one I explained above. The failure mode is the build fails on some platforms.
2) The assert you listed above. That one is caused by the test first reserving with mtTest and then committing with mtGC. I simply also changed mtGC to mtTest and then the test passes.

Given the earlier issues with incorporating my feedback I'll provide my updated feedback as a branch instead. This is the diff:
https://github.com/openjdk/jdk/compare/pr/24282...stefank:jdk:pull_24282_stefank_feedback

And this is the branch:
https://github.com/stefank/jdk/tree/pull_24282_stefank_feedback

The you can fetch my branch to your local machine by running the following command:

git fetch https://github.com/stefank/jdk pull_24282_stefank_feedback:pull_24282_stefank_feedback


And then you can test my branch if you want. When you are satisfied that it doesn't have any problems, then you can bring my changes over to your own review branch by calling the following command (while having your review branch as the active branch):

git merge --ff pull_24282_stefank_feedback


And then you can add more changes if there are more tweaks that needs to be done.

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2771851832

From gziemski at openjdk.org  Wed Apr  2 14:44:07 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 2 Apr 2025 14:44:07 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v7]
In-Reply-To: <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
Message-ID: <7SqvyOWZc12cMJQfIoCAHBSXjYZzJS6Jsq_hgr9pxoY=.0da488e5-c319-40af-a28d-6d9fc0a37ebd@github.com>

On Tue, 1 Apr 2025 20:53:06 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove default value parameter if it's false from os::reserve_memory

> So, there were two problems:
> 
> 1. Is the one I explained above. The failure mode is the build fails on some platforms.
> 2. The assert you listed above. That one is caused by the test first reserving with mtTest and then committing with mtGC. I simply also changed mtGC to mtTest and then the test passes.
> 
> Given the earlier issues with incorporating my feedback I'll provide my updated feedback as a branch instead. This is the diff: [pr/24282...stefank:jdk:pull_24282_stefank_feedback](https://github.com/openjdk/jdk/compare/pr/24282...stefank:jdk:pull_24282_stefank_feedback)
> 
> And this is the branch: https://github.com/stefank/jdk/tree/pull_24282_stefank_feedback
> 
> The you can fetch my branch to your local machine by running the following command:
> 
> ```
> git fetch https://github.com/stefank/jdk pull_24282_stefank_feedback:pull_24282_stefank_feedback
> ```
> 
> And then you can test my branch if you want. When you are satisfied that it doesn't have any problems, then you can bring my changes over to your own review branch by calling the following command (while having your review branch as the active branch):
> 
> ```
> git merge --ff pull_24282_stefank_feedback
> ```
> 
> And then you can add more changes if there are more tweaks that needs to be done.

This makes incorporating your feedback super easy, thank you!

Following and implementing each feedback one at a time was tedious, sorry I missed some changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2772787797

From kdnilsen at openjdk.org  Wed Apr  2 17:48:18 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Apr 2025 17:48:18 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when
 not the fault of triggering heuristic
In-Reply-To: <7JxoAe6FagKRFE7pmYXcudYVDKDMIv-ncUNt5b-LYuE=.78c2a17b-9fb3-4764-8b8c-c12cd3275f82@github.com>
References: <7JxoAe6FagKRFE7pmYXcudYVDKDMIv-ncUNt5b-LYuE=.78c2a17b-9fb3-4764-8b8c-c12cd3275f82@github.com>
Message-ID: <E_DuW9MQzlrymTw_AeBUkfzKqO0l-HNiiPRsnmwZsAw=.a606ba62-39ef-4758-a09a-039dda49fb8f@github.com>

On Tue, 1 Apr 2025 19:00:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Trivial conflict. Has follow on issue.

Thanks for bringing this backport in.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/165#pullrequestreview-2737090423

From kdnilsen at openjdk.org  Wed Apr  2 17:49:19 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Apr 2025 17:49:19 GMT
Subject: RFR: 8348610: GenShen: TestShenandoahEvacuationInformationEvent
 failed with setRegions >= regionsFreed: expected 1 >= 57
In-Reply-To: <hGdz_BBNr0T6byQ9ahlu4W791Q1yXLoGI1epbZXs7zE=.626a024f-d5a8-46bd-8b32-545258939703@github.com>
References: <hGdz_BBNr0T6byQ9ahlu4W791Q1yXLoGI1epbZXs7zE=.626a024f-d5a8-46bd-8b32-545258939703@github.com>
Message-ID: <xjg4PnGV9uYVOnwUCY-AlDhb7r24tyH_PKaDj5C15Fo=.12f16c1b-2138-459f-b348-154e1510deee@github.com>

On Tue, 1 Apr 2025 18:43:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean, but contains follow up fix.

Thanks.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/164#pullrequestreview-2737093232

From kdnilsen at openjdk.org  Wed Apr  2 17:49:49 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Apr 2025 17:49:49 GMT
Subject: RFR: 8352181: Shenandoah: Evacuate thread roots after early
 cleanup
In-Reply-To: <99wc8_4LoODnc8E0fwS3VV3NTfdPJ3soau-_jaiLrGU=.ef48e18a-03f2-4863-b610-513b52e539a5@github.com>
References: <99wc8_4LoODnc8E0fwS3VV3NTfdPJ3soau-_jaiLrGU=.ef48e18a-03f2-4863-b610-513b52e539a5@github.com>
Message-ID: <UqXibOHHdzUgg3zEJRJxmUQLDizVAwsanefLS2czwj4=.3ecc114f-acf0-4cd8-a3c1-9d78749acb10@github.com>

On Mon, 17 Mar 2025 21:37:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Moving the evacuation of thread roots after early cleanup allows Shenandoah to recycle immediate garbage a bit sooner in the cycle.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/24090#pullrequestreview-2737095478

From kdnilsen at openjdk.org  Wed Apr  2 17:55:48 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 2 Apr 2025 17:55:48 GMT
Subject: RFR: 8352181: Shenandoah: Evacuate thread roots after early
 cleanup
In-Reply-To: <99wc8_4LoODnc8E0fwS3VV3NTfdPJ3soau-_jaiLrGU=.ef48e18a-03f2-4863-b610-513b52e539a5@github.com>
References: <99wc8_4LoODnc8E0fwS3VV3NTfdPJ3soau-_jaiLrGU=.ef48e18a-03f2-4863-b610-513b52e539a5@github.com>
Message-ID: <zYrqIMmS1Y7bT2SZQdgvXVlvDYH_UVJibI3gAt30yGE=.8d629d95-c10a-43df-8938-3f762dcd663c@github.com>

On Mon, 17 Mar 2025 21:37:14 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Moving the evacuation of thread roots after early cleanup allows Shenandoah to recycle immediate garbage a bit sooner in the cycle.

Maybe the "best" tradeoff is "adaptive behavior".  If allocatable memory is in "short supply", we should evacuate thread roots early.  Otherwise, we should preserve existing behavior.  Defining "short supply" might be a bit tricky.

There's a related PR that is still in development, to surge GC worker threads when we are at risk of experiencing allocation failures.  A lot of heuristic predictions feed into the decision of when and whether to surge.  We could use that same feedback mechanism here.  If we are under "worker surge" conditions, that suggests memory is in short supply, an this is the ideal time to shift some of the GC work onto the mutators, so this is when we should evacuate thread roots early.

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

PR Comment: https://git.openjdk.org/jdk/pull/24090#issuecomment-2773302505

From jsikstro at openjdk.org  Wed Apr  2 18:20:00 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 2 Apr 2025 18:20:00 GMT
Subject: RFR: 8353559: Restructure CollectedHeap error printing
Message-ID: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>

Calling Universe::heap()->print_on_error() gets dispatched to the most specific implementation, which for some GCs is their own implementation instead of the default in CollectedHeap. Each GC-specific implementation calls back to CollectedHeap::print_on_error(), which then dispatches back into the specific implementation of print_on(). This is kind of awkward and creates a call-chain that's not straightforward to wrap your head around, jumping back and forth via CollectedHeap and the specific implementation.

To make the call-chain cleaner, I have made print_on_error() a pure virtual method in CollectedHeap, and implemented print_on_error() in each GC's implementation of CollectedHeap. In addition, I have removed print_extended_on() from CollectedHeap and implemented that for the GCs that actually need/use it.

Removing the usage of the common print_on_error() also means that GCs that do not print anything interesting for their barrier set can omit this. So, I've removed it from ZGC and Shenandoah.

To make print_on_error() consistent with print_on(), I have moved the printing of "Heap:" to the caller(s) of print_on_error() (only inside vmError.cpp). This is a trivial change for all GCs except ZGC, which requires some restructuring in its error printing.

The old and new printing orders are shown below for ZGC:

# Old
<precious log>
<zgc globals>
<heap>
<zgc page table>
<barrier set>
<polling page>



# New
<precious log>
<heap>
<zgc globals>
<zgc page table>
<polling page>


Testing:
* GHA
* Tiers 1 & 2
* Manually verified that printing still works and outputs the intended information via running the following commands and comparing the output.

../fastdebug-old/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_old.txt
../fastdebug-new/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_new.txt

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

Commit messages:
 - Copyright years
 - 8353559: Restructure CollectedHeap error printing

Changes: https://git.openjdk.org/jdk/pull/24387/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24387&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353559
  Stats: 141 lines in 16 files changed: 75 ins; 52 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24387.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24387/head:pull/24387

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

From gziemski at openjdk.org  Wed Apr  2 18:37:36 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 2 Apr 2025 18:37:36 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v8]
In-Reply-To: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
Message-ID: <5b6QutsBRX4KGZY50opOtRztczGFdilIy3CwlisJ4s4=.7b8a3f1a-4f6f-469f-829b-1d693ad1355d@github.com>

> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  The real feedback from StefanK

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24282/files
  - new: https://git.openjdk.org/jdk/pull/24282/files/5de1d560..3bd03cbe

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

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

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

From gziemski at openjdk.org  Wed Apr  2 18:37:36 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 2 Apr 2025 18:37:36 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v7]
In-Reply-To: <kDuJ6qfeoJ3Dq3gVf9vhtv_htKrKoBXq6jAStsLPZu0=.4bf30094-4161-4edf-9f52-cd19d6347456@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <V1r7kWFFhUy-u4IpkWpd2J3ZfiRcVuxcuQz7IbdwLfI=.af9ec7b2-8501-4c80-8ccc-5b06b669e9e8@github.com>
 <kDuJ6qfeoJ3Dq3gVf9vhtv_htKrKoBXq6jAStsLPZu0=.4bf30094-4161-4edf-9f52-cd19d6347456@github.com>
Message-ID: <1uwNGuYl7MdwLmyxHc75pHVxuIlypTlUUbiuj4on738=.1503e429-dcac-46ac-9bfc-f6e0039762e8@github.com>

On Wed, 2 Apr 2025 08:45:44 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   remove default value parameter if it's false from os::reserve_memory
>
> So, there were two problems:
> 1) Is the one I explained above. The failure mode is the build fails on some platforms.
> 2) The assert you listed above. That one is caused by the test first reserving with mtTest and then committing with mtGC. I simply also changed mtGC to mtTest and then the test passes.
> 
> Given the earlier issues with incorporating my feedback I'll provide my updated feedback as a branch instead. This is the diff:
> https://github.com/openjdk/jdk/compare/pr/24282...stefank:jdk:pull_24282_stefank_feedback
> 
> And this is the branch:
> https://github.com/stefank/jdk/tree/pull_24282_stefank_feedback
> 
> The you can fetch my branch to your local machine by running the following command:
> 
> git fetch https://github.com/stefank/jdk pull_24282_stefank_feedback:pull_24282_stefank_feedback
> 
> 
> And then you can test my branch if you want. When you are satisfied that it doesn't have any problems, then you can bring my changes over to your own review branch by calling the following command (while having your review branch as the active branch):
> 
> git merge --ff pull_24282_stefank_feedback
> 
> 
> And then you can add more changes if there are more tweaks that needs to be done.

@stefank I pushed your feedback, thank you for your branch and making it so easy to incorporate your contribution!

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2773390856

From stefank at openjdk.org  Wed Apr  2 20:53:48 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 2 Apr 2025 20:53:48 GMT
Subject: RFR: 8353559: Restructure CollectedHeap error printing
In-Reply-To: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
References: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
Message-ID: <nmCZUN_1Q1qgO9fECLnKEfraSryrDsiTHSArAMH6rXw=.ccdb81a0-ef8c-4993-882f-00c9b86e7b83@github.com>

On Wed, 2 Apr 2025 18:09:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Calling Universe::heap()->print_on_error() gets dispatched to the most specific implementation, which for some GCs is their own implementation instead of the default in CollectedHeap. Each GC-specific implementation calls back to CollectedHeap::print_on_error(), which then dispatches back into the specific implementation of print_on(). This is kind of awkward and creates a call-chain that's not straightforward to wrap your head around, jumping back and forth via CollectedHeap and the specific implementation.
> 
> To make the call-chain cleaner, I have made print_on_error() a pure virtual method in CollectedHeap, and implemented print_on_error() in each GC's implementation of CollectedHeap. In addition, I have removed print_extended_on() from CollectedHeap and implemented that for the GCs that actually need/use it.
> 
> Removing the usage of the common print_on_error() also means that GCs that do not print anything interesting for their barrier set can omit this. So, I've removed it from ZGC and Shenandoah.
> 
> To make print_on_error() consistent with print_on(), I have moved the printing of "Heap:" to the caller(s) of print_on_error() (only inside vmError.cpp). This is a trivial change for all GCs except ZGC, which requires some restructuring in its error printing.
> 
> The old and new printing orders are shown below for ZGC:
> 
> # Old
> <precious log>
> <zgc globals>
> <heap>
> <zgc page table>
> <barrier set>
> <polling page>
> 
> 
> 
> # New
> <precious log>
> <heap>
> <zgc globals>
> <zgc page table>
> <polling page>
> 
> 
> Testing:
> * GHA
> * Tiers 1 & 2
> * Manually verified that printing still works and outputs the intended information via running the following commands and comparing the output.
> 
> ../fastdebug-old/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_old.txt
> ../fastdebug-new/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_new.txt

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24387#pullrequestreview-2737551377

From gziemski at openjdk.org  Wed Apr  2 22:16:51 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 2 Apr 2025 22:16:51 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v8]
In-Reply-To: <5b6QutsBRX4KGZY50opOtRztczGFdilIy3CwlisJ4s4=.7b8a3f1a-4f6f-469f-829b-1d693ad1355d@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <5b6QutsBRX4KGZY50opOtRztczGFdilIy3CwlisJ4s4=.7b8a3f1a-4f6f-469f-829b-1d693ad1355d@github.com>
Message-ID: <aJHPxqIK_ZujfcyDUHG4RvGJbvHLuRxN8va-BWveIic=.10f55ab8-edb8-42e9-ad56-b05bb3a03e6f@github.com>

On Wed, 2 Apr 2025 18:37:36 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The real feedback from StefanK

I just ran MAch5 tier1-5 and from what I can see I think it passes (see the issue for more on that).

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2773850553

From eosterlund at openjdk.org  Thu Apr  3 09:53:53 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 3 Apr 2025 09:53:53 GMT
Subject: RFR: 8353559: Restructure CollectedHeap error printing
In-Reply-To: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
References: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
Message-ID: <nS1TdW22ecfShhM5YQBRMg1XiWjzcRXNb3VOQ0Dtnqo=.76d1835c-e975-447d-b41a-375ce11056f4@github.com>

On Wed, 2 Apr 2025 18:09:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Calling Universe::heap()->print_on_error() gets dispatched to the most specific implementation, which for some GCs is their own implementation instead of the default in CollectedHeap. Each GC-specific implementation calls back to CollectedHeap::print_on_error(), which then dispatches back into the specific implementation of print_on(). This is kind of awkward and creates a call-chain that's not straightforward to wrap your head around, jumping back and forth via CollectedHeap and the specific implementation.
> 
> To make the call-chain cleaner, I have made print_on_error() a pure virtual method in CollectedHeap, and implemented print_on_error() in each GC's implementation of CollectedHeap. In addition, I have removed print_extended_on() from CollectedHeap and implemented that for the GCs that actually need/use it.
> 
> Removing the usage of the common print_on_error() also means that GCs that do not print anything interesting for their barrier set can omit this. So, I've removed it from ZGC and Shenandoah.
> 
> To make print_on_error() consistent with print_on(), I have moved the printing of "Heap:" to the caller(s) of print_on_error() (only inside vmError.cpp). This is a trivial change for all GCs except ZGC, which requires some restructuring in its error printing.
> 
> The old and new printing orders are shown below for ZGC:
> 
> # Old
> <precious log>
> <zgc globals>
> <heap>
> <zgc page table>
> <barrier set>
> <polling page>
> 
> 
> 
> # New
> <precious log>
> <heap>
> <zgc globals>
> <zgc page table>
> <polling page>
> 
> 
> Testing:
> * GHA
> * Tiers 1 & 2
> * Manually verified that printing still works and outputs the intended information via running the following commands and comparing the output.
> 
> ../fastdebug-old/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_old.txt
> ../fastdebug-new/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_new.txt

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24387#pullrequestreview-2739190388

From stefank at openjdk.org  Thu Apr  3 11:22:12 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 3 Apr 2025 11:22:12 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v8]
In-Reply-To: <5b6QutsBRX4KGZY50opOtRztczGFdilIy3CwlisJ4s4=.7b8a3f1a-4f6f-469f-829b-1d693ad1355d@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <5b6QutsBRX4KGZY50opOtRztczGFdilIy3CwlisJ4s4=.7b8a3f1a-4f6f-469f-829b-1d693ad1355d@github.com>
Message-ID: <vnB9DaXVrJBc1nHQZC0uxCPay8k-sP4lzWIaPVEJ18g=.bca8d46f-c781-4ab3-87e9-2ee26f00f9b5@github.com>

On Wed, 2 Apr 2025 18:37:36 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The real feedback from StefanK

Looks mostly good, there are a few things that I'd like to get cleaned up, but we can take care of that in separate RFEs.

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

> 525: 
> 526:   static char*  map_memory(int fd, const char* file_name, size_t file_offset,
> 527:                            char *addr, size_t bytes, MemTag mem_tag, bool read_only = false,

AFAICT, there's no need to have a default value for read_only. I think we should remove this default value and move the MemTag parameter so that it comes after read_only and before allow_exec. This would make the parameter order more consistent with the other functions that accept a mem_tag and an executable.

Given that you have tested the current patch, I'm fine with doing this as a small follow-up patch.

test/hotspot/gtest/gc/z/test_zForwarding.cpp line 58:

> 56: 
> 57:     for (uintptr_t start = 0; start + ZGranuleSize <= ZAddressOffsetMax; start += increment) {
> 58:       char* const reserved = os::attempt_reserve_memory_at((char*)ZAddressHeapBase + start, ZGranuleSize, mtNone);

Suggestion:

      char* const reserved = os::attempt_reserve_memory_at((char*)ZAddressHeapBase + start, ZGranuleSize, mtTest);


This snuck in with one of your latest changes.

test/hotspot/gtest/runtime/test_os.cpp line 733:

> 731:   // Reserve a small range and fill it with a marker string, should show up
> 732:   // on implementations displaying range snippets
> 733:   char* p = os::reserve_memory(1 * M, mtInternal);

Suggestion:

  char* p = os::reserve_memory(1 * M, mtTest);

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24282#pullrequestreview-2739478381
PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2026779415
PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2026781507
PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2026782706

From ayang at openjdk.org  Thu Apr  3 11:32:55 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 3 Apr 2025 11:32:55 GMT
Subject: RFR: 8353559: Restructure CollectedHeap error printing
In-Reply-To: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
References: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
Message-ID: <Rl7LoM52lduw2rOHtJI6q8mJKNjkDrHdI6CB33dgihI=.c9865915-0c08-4c3b-b5aa-4e52b6aa46b7@github.com>

On Wed, 2 Apr 2025 18:09:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Calling Universe::heap()->print_on_error() gets dispatched to the most specific implementation, which for some GCs is their own implementation instead of the default in CollectedHeap. Each GC-specific implementation calls back to CollectedHeap::print_on_error(), which then dispatches back into the specific implementation of print_on(). This is kind of awkward and creates a call-chain that's not straightforward to wrap your head around, jumping back and forth via CollectedHeap and the specific implementation.
> 
> To make the call-chain cleaner, I have made print_on_error() a pure virtual method in CollectedHeap, and implemented print_on_error() in each GC's implementation of CollectedHeap. In addition, I have removed print_extended_on() from CollectedHeap and implemented that for the GCs that actually need/use it.
> 
> Removing the usage of the common print_on_error() also means that GCs that do not print anything interesting for their barrier set can omit this. So, I've removed it from ZGC and Shenandoah.
> 
> To make print_on_error() consistent with print_on(), I have moved the printing of "Heap:" to the caller(s) of print_on_error() (only inside vmError.cpp). This is a trivial change for all GCs except ZGC, which requires some restructuring in its error printing.
> 
> The old and new printing orders are shown below for ZGC:
> 
> # Old
> <precious log>
> <zgc globals>
> <heap>
> <zgc page table>
> <barrier set>
> <polling page>
> 
> 
> 
> # New
> <precious log>
> <heap>
> <zgc globals>
> <zgc page table>
> <polling page>
> 
> 
> Testing:
> * GHA
> * Tiers 1 & 2
> * Manually verified that printing still works and outputs the intended information via running the following commands and comparing the output.
> 
> ../fastdebug-old/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_old.txt
> ../fastdebug-new/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_new.txt

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24387#pullrequestreview-2739525769

From wkemper at openjdk.org  Thu Apr  3 16:54:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 3 Apr 2025 16:54:18 GMT
Subject: Integrated: 8348610: GenShen: TestShenandoahEvacuationInformationEvent
 failed with setRegions >= regionsFreed: expected 1 >= 57
In-Reply-To: <hGdz_BBNr0T6byQ9ahlu4W791Q1yXLoGI1epbZXs7zE=.626a024f-d5a8-46bd-8b32-545258939703@github.com>
References: <hGdz_BBNr0T6byQ9ahlu4W791Q1yXLoGI1epbZXs7zE=.626a024f-d5a8-46bd-8b32-545258939703@github.com>
Message-ID: <Kn2sr9LVyY8JGAV0sSYp0oioEHWvwYyl14oJFKc0g9w=.5431952e-42d8-437d-bf92-37c1348c5473@github.com>

On Tue, 1 Apr 2025 18:43:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean, but contains follow up fix.

This pull request has now been integrated.

Changeset: 8c3745d5
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/8c3745d5aca23b8f86d64a3a774e69d42a143eca
Stats:     17 lines in 5 files changed: 2 ins; 1 del; 14 mod

8348610: GenShen: TestShenandoahEvacuationInformationEvent failed with setRegions >= regionsFreed: expected 1 >= 57
8349639: jfr/event/gc/detailed/TestShenandoahEvacuationInformationEvent.java fails to compile after JDK-8348610

Reviewed-by: kdnilsen
Backport-of: bad39b6d8892ba9b86bc81bf01108a1df617defb

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

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

From wkemper at openjdk.org  Thu Apr  3 16:54:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 3 Apr 2025 16:54:21 GMT
Subject: RFR: 8348594: Shenandoah: Do not penalize for degeneration when
 not the fault of triggering heuristic
In-Reply-To: <7JxoAe6FagKRFE7pmYXcudYVDKDMIv-ncUNt5b-LYuE=.78c2a17b-9fb3-4764-8b8c-c12cd3275f82@github.com>
References: <7JxoAe6FagKRFE7pmYXcudYVDKDMIv-ncUNt5b-LYuE=.78c2a17b-9fb3-4764-8b8c-c12cd3275f82@github.com>
Message-ID: <oTnUkHQOZRp9vkeN11O1xTkCJVEYqmEhcWu-SO9qU3E=.30a76b7f-d5f9-4e82-80be-b45f653f7b5f@github.com>

On Tue, 1 Apr 2025 19:00:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Trivial conflict. Has follow on issue.

Test failure looks unrelated.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/165#issuecomment-2776402216

From wkemper at openjdk.org  Thu Apr  3 16:54:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 3 Apr 2025 16:54:21 GMT
Subject: Integrated: 8348594: Shenandoah: Do not penalize for degeneration when
 not the fault of triggering heuristic
In-Reply-To: <7JxoAe6FagKRFE7pmYXcudYVDKDMIv-ncUNt5b-LYuE=.78c2a17b-9fb3-4764-8b8c-c12cd3275f82@github.com>
References: <7JxoAe6FagKRFE7pmYXcudYVDKDMIv-ncUNt5b-LYuE=.78c2a17b-9fb3-4764-8b8c-c12cd3275f82@github.com>
Message-ID: <sfcowsC-qGBVI6lwPj1RHIuBzCamP5Zu06RFZa8617Y=.c30d9d50-bc0c-463f-b718-edaa2254b07d@github.com>

On Tue, 1 Apr 2025 19:00:44 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Trivial conflict. Has follow on issue.

This pull request has now been integrated.

Changeset: 520667a3
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/520667a3ec9e7480f0987372c0250649cc4e385a
Stats:     84 lines in 12 files changed: 80 ins; 0 del; 4 mod

8348594: Shenandoah: Do not penalize for degeneration when not the fault of triggering heuristic
8350889: GenShen: Break out of infinite loop of old GC cycles

Reviewed-by: kdnilsen
Backport-of: 38322407cd1664115e975c7fd9cb61e40d9557b5

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

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

From ysr at openjdk.org  Thu Apr  3 21:45:52 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 3 Apr 2025 21:45:52 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v7]
In-Reply-To: <5Yxk8oBN69i5Ty_jRCtXoLeNjyet6DEySoFqnzxrblk=.9a1ad401-9da2-4d06-8e22-c51d810dd2f8@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <5Yxk8oBN69i5Ty_jRCtXoLeNjyet6DEySoFqnzxrblk=.9a1ad401-9da2-4d06-8e22-c51d810dd2f8@github.com>
Message-ID: <6sjBSQODcXKXzjvshAJiHq96N4Ler-TEBaSuN4nNr6w=.a6ee8ec7-9a3e-49ae-9718-8d1a027e6420@github.com>

On Mon, 31 Mar 2025 23:09:53 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed.
>> 
>> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] Tier 1
>> - [x]  Tier 2
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Can't verify marked object with complete marking after full GC

I looked at the files that changed since the last review only, but can look over all of it once again if necessary (just let me know).

This looks good; just a few small comments, and in particular a somewhat formalistic and pedantic distinction between the use of `gc_generation()` and `active_generation()` to fetch the marking context (and the use of `global_generation()`).

Otherwise looks good to me.

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 352:

> 350:     assert(_from_region != nullptr, "must set before work");
> 351:     assert(_heap->active_generation()->complete_marking_context()->is_marked(p), "must be marked");
> 352:     assert(!_heap->active_generation()->complete_marking_context()->allocated_after_mark_start(p), "must be truly marked");

I am probably being a bit pedantic here...

I would use `gc_generation()` in all code that is executed strictly by GC threads, and `active_generation()` in all code that may possibly be executed by a mutator thread. It seems as if today this code is only executed by GC threads.

In general, there is no real distinction between these field at times like these (STW pauses) when heap verification is taking place, but from a syntactic hygiene perspective.

We can otherwise file a ticket to separately clean up any confusion in the use of these fields (and add a dynamic check to prevent creeping confusion). The names aren't super well-chosen, but generally think of `_gc_generation` as the generation that is being GC'd, `_active_generation` as one that mutator threads are aware is being the subject of GC. Any assertions by mutator threads should use the latter and by GC threads the former. The fields are reconciled at STW pauses.

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 778:

> 776:   ShenandoahAdjustPointersClosure() :
> 777:     _heap(ShenandoahHeap::heap()),
> 778:     _ctx(ShenandoahHeap::heap()->global_generation()->complete_marking_context()) {}

I liked the changes in this file that everywhere use the heap's `_gc_generation` (see comment about the distinction between `gc_generation()` and `active_generation()` above) field to fetch the marking context. While I understand that it might be the case that whenever we are here, the `_gc_generation` must necessarily be the `global_generation()`, I am wondering about:

1. using `_gc_generation` here as well to fetch the context, and
2. secondly, asserting also that the `_gc_generation` is in fact the `global_generation()`.

I assume (2) must be the case here? If not, it would be good to see if this can be fixed.

src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 1094:

> 1092:     ShenandoahHeapRegion* region = _regions.next();
> 1093:     ShenandoahHeap* heap = ShenandoahHeap::heap();
> 1094:     ShenandoahMarkingContext* const ctx = heap->global_generation()->complete_marking_context();

Same comment as at line 778.

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 1191:

> 1189:           _verify_remembered_after_full_gc,  // verify read-write remembered set
> 1190:           _verify_forwarded_none,      // all objects are non-forwarded
> 1191:           _verify_marked_incomplete,   // all objects are marked in incomplete bitmap

Is the marking bitmap updated as objects are moved to their new locations? Is that done just to satisfy the verifier?

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

PR Review: https://git.openjdk.org/jdk/pull/23886#pullrequestreview-2741111545
PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2027772698
PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2027710108
PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2027713065
PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2027777968

From ysr at openjdk.org  Thu Apr  3 21:55:07 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 3 Apr 2025 21:55:07 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v7]
In-Reply-To: <FvejQIyE__RellnXcgcIVszpv4R_ksMGdg0lwoIgMB4=.c5ad3798-5229-4795-a72e-7e5809be46f5@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <DR-daR1gtZywrX83rvyf4Z--qOuw4m1dNxNQC-QFmwc=.986e9f20-5b7c-4038-9592-96e2e9f64205@github.com>
 <kSAu2bVrO8JXDTJk-7lnK1keBKHMNIBJLCM45KEFqxg=.d0155d18-2af0-4905-b7c8-575c885b1c33@github.com>
 <7yfWKXewUM1XqWtlnyuPV3nu9bGr5VNJXuXi1aNQGvQ=.4c53d85b-13f3-4bfc-87c3-634d547bb440@github.com>
 <FvejQIyE__RellnXcgcIVszpv4R_ksMGdg0lwoIgMB4=.c5ad3798-5229-4795-a72e-7e5809be46f5@github.com>
Message-ID: <gQ4TbZGDKWDbLE9sWlYXeZRMRGSesiplKBKzgPPAkks=.796df588-c614-4a60-89c2-0e00285ed16c@github.com>

On Thu, 6 Mar 2025 23:09:47 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> OK, yes, that makes sense. Why not then use both `ShenandoahHeap::[complete_]marking_context()` as synonyms for `ShehandoahHeap::active_generation()->[complete_]marking_context()`. See other related comments in this review round.
>
> I feel using `henandoahHeap::complete_marking_context()` as synonyms for `ShehandoahHeap::active_generation()->[complete_]marking_context()` may cause more confusion, just read from the name it seems that it indicates the marking is complete for the whole heap, not just the active generation.

ok, that makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2027790148

From ysr at openjdk.org  Thu Apr  3 22:10:50 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 3 Apr 2025 22:10:50 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v7]
In-Reply-To: <hJFbvQ3aw9u9pI1FuXaHC_Z6sUf3E85ZLsIwAZMKyVs=.9f4acc62-a361-4a98-9110-1a25d279d69e@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <DR-daR1gtZywrX83rvyf4Z--qOuw4m1dNxNQC-QFmwc=.986e9f20-5b7c-4038-9592-96e2e9f64205@github.com>
 <B1mhaGcA7KDiDOqp6sm1boVEQi9fjsDgN_ZuhaDYWQ0=.70716fd1-a36f-4c2e-9b98-2453fa9b1468@github.com>
 <M3uVQbMyK1OWkRr_yCeq8IVOpHKmFdgIDRHwKqJE6dk=.577f226d-061f-4b52-8918-72941d5154a0@github.com>
 <8w22oUPhZEx0iEIeNQ-GUUjx8jNkjXrTHjfjN_sX4HE=.2c391dd5-227e-4755-ba4d-528a7dcefca3@github.com>
 <Lt4ZOUJNrJA6S5Pbpk2pzFCH2rxcLqJ8RC-UXkFegrg=.b7d4dac4-6255-46bb-bdab-1bec9379e536@github.com>
 <IBznrVAuBLSSWc3LW8vQrf6o2GOJLJTXsKvD4MS8PSU=.81e162af-7f07-411f-a4c2-a3f22bfaf580@github.com>
 <hJFbvQ3aw9u9pI1FuXaHC_Z6sUf3E85ZLsIwAZMKyVs=.9f4acc62-a361-4a98-9110-1a25d279d69e@github.com>
Message-ID: <iCFoki_jNyR9FZkg6GIzX3xmlcAzlRsjE5gA9OAXJWI=.e93d0934-13d2-4169-9e7f-3cb0bcd3617c@github.com>

On Fri, 7 Mar 2025 19:25:33 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> You proposal will make the impl of the  set_mark_complete/is_mark_complete of ShenandoahGeneration cleaner, but the thing is it will change current design and behavior, we may have to update the code where there methods is called, e.g. when we call `set_mark_complete` of  gc_generation/active_generation, if it is global generation, we  may have to explicitly call the same methods of  ShenandoahYoungGeneration and ShenandoahOldGeneration to fan out the status. 
>> 
>> How about I follow up it in a separate task and update the implementation if necessary? I want to limit the changes involved in this PR, and only fix the bug.
>
> The young and old generations are only instantiated in the generational mode, so using them without checking the mode will result in SEGV in non-generational modes. 
> 
> Global collections have a lot of overlap with old collections. I think what Ramki is saying, is that if we change all the code that makes assertions about the completion status of young/old marking to use the `active_generation` field instead, then we wouldn't need to update the completion status of young/old during a global collection. The difficulty here is that we need assurances that the old generation mark bitmap is valid in collections subsequent to a global collection. So, I don't think we can rely on completion status of `active_generation` when it was global, in following collections where it may now refer to young or old.

I see. Yes, that makes sense to me, thanks William.

It would then be the case for the global generation that if is_mark_complete() then in the generational case that's also the case for both of its constituent generations. May be we can assert that when we fetch that at line 204 (and find it's true)?

May be I am being paranoid, but the assert would make me feel confident that the state maintenance isn't going awry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2027812176

From xpeng at openjdk.org  Thu Apr  3 22:33:56 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 3 Apr 2025 22:33:56 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v7]
In-Reply-To: <6sjBSQODcXKXzjvshAJiHq96N4Ler-TEBaSuN4nNr6w=.a6ee8ec7-9a3e-49ae-9718-8d1a027e6420@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <5Yxk8oBN69i5Ty_jRCtXoLeNjyet6DEySoFqnzxrblk=.9a1ad401-9da2-4d06-8e22-c51d810dd2f8@github.com>
 <6sjBSQODcXKXzjvshAJiHq96N4Ler-TEBaSuN4nNr6w=.a6ee8ec7-9a3e-49ae-9718-8d1a027e6420@github.com>
Message-ID: <qn3QRhiyssn_aQeJHdD37WUjjbETj7N5HOKYiZy9wSA=.b1f5b17d-6bb6-4a4a-aa67-b4c1d0ec9131@github.com>

On Thu, 3 Apr 2025 21:39:33 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:
>> 
>>   Can't verify marked object with complete marking after full GC
>
> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 1191:
> 
>> 1189:           _verify_remembered_after_full_gc,  // verify read-write remembered set
>> 1190:           _verify_forwarded_none,      // all objects are non-forwarded
>> 1191:           _verify_marked_incomplete,   // all objects are marked in incomplete bitmap
> 
> Is the marking bitmap updated as objects are moved to their new locations? Is that done just to satisfy the verifier?

Yes, making bitmaps has been reset after full GC,  except for the for regions with pined objects.
_verify_marked_complete requires complete marking context, it might make more sense to change it to _verify_marked_disable after full GC.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2027835236

From xpeng at openjdk.org  Thu Apr  3 22:37:50 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 3 Apr 2025 22:37:50 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v7]
In-Reply-To: <6sjBSQODcXKXzjvshAJiHq96N4Ler-TEBaSuN4nNr6w=.a6ee8ec7-9a3e-49ae-9718-8d1a027e6420@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <5Yxk8oBN69i5Ty_jRCtXoLeNjyet6DEySoFqnzxrblk=.9a1ad401-9da2-4d06-8e22-c51d810dd2f8@github.com>
 <6sjBSQODcXKXzjvshAJiHq96N4Ler-TEBaSuN4nNr6w=.a6ee8ec7-9a3e-49ae-9718-8d1a027e6420@github.com>
Message-ID: <u62mU7ImLawu2F1hsiO0rQb9iw9EiNEfRozt9zWLHWk=.c2306ec0-1052-4c6f-919e-9215f6c8f991@github.com>

On Thu, 3 Apr 2025 21:34:06 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:
>> 
>>   Can't verify marked object with complete marking after full GC
>
> src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp line 352:
> 
>> 350:     assert(_from_region != nullptr, "must set before work");
>> 351:     assert(_heap->active_generation()->complete_marking_context()->is_marked(p), "must be marked");
>> 352:     assert(!_heap->active_generation()->complete_marking_context()->allocated_after_mark_start(p), "must be truly marked");
> 
> I am probably being a bit pedantic here...
> 
> I would use `gc_generation()` in all code that is executed strictly by GC threads, and `active_generation()` in all code that may possibly be executed by a mutator thread. It seems as if today this code is only executed by GC threads.
> 
> In general, there is no real distinction between these field at times like these (STW pauses) when heap verification is taking place, but from a syntactic hygiene perspective.
> 
> We can otherwise file a ticket to separately clean up any confusion in the use of these fields (and add a dynamic check to prevent creeping confusion). The names aren't super well-chosen, but generally think of `_gc_generation` as the generation that is being GC'd, `_active_generation` as one that mutator threads are aware is being the subject of GC. Any assertions by mutator threads should use the latter and by GC threads the former. The fields are reconciled at STW pauses.

Make sense, I did notice that there is assert `assert(!Thread::current()->is_Java_thread(), "Not allowed");` in `gc_generation()` suggesting that non-Java thread should call  `gc_generation()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2027837825

From wkemper at openjdk.org  Thu Apr  3 22:40:44 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 3 Apr 2025 22:40:44 GMT
Subject: RFR: 8348595: GenShen: Fix generational free-memory no-progress check
Message-ID: <foXASdUVQh9W-85H2emz6Tznyv5Q2RbwWRqkZgCq1Gw=.93130398-8a1d-4a4b-b14a-aee9e8481c70@github.com>

Clean backport

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

Commit messages:
 - 8348595: GenShen: Fix generational free-memory no-progress check

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

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

From wkemper at openjdk.org  Thu Apr  3 22:51:02 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 3 Apr 2025 22:51:02 GMT
Subject: Integrated: 8348595: GenShen: Fix generational free-memory no-progress
 check
In-Reply-To: <foXASdUVQh9W-85H2emz6Tznyv5Q2RbwWRqkZgCq1Gw=.93130398-8a1d-4a4b-b14a-aee9e8481c70@github.com>
References: <foXASdUVQh9W-85H2emz6Tznyv5Q2RbwWRqkZgCq1Gw=.93130398-8a1d-4a4b-b14a-aee9e8481c70@github.com>
Message-ID: <GkxAj4dssv9mnilU3nk5REGOpuqHD-CRvKWCoyr-1Q0=.668d2b85-f946-450b-a573-f6fd27ac2d3a@github.com>

On Thu, 3 Apr 2025 22:35:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: aa952158
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/aa952158063d6e023eede29934bbd2023d8b35d5
Stats:     27 lines in 5 files changed: 21 ins; 0 del; 6 mod

8348595: GenShen: Fix generational free-memory no-progress check

Backport-of: ba6c96599aac1a6c08cb66c611474f83bbc9b260

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

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

From ysr at openjdk.org  Thu Apr  3 22:57:50 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 3 Apr 2025 22:57:50 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v7]
In-Reply-To: <qn3QRhiyssn_aQeJHdD37WUjjbETj7N5HOKYiZy9wSA=.b1f5b17d-6bb6-4a4a-aa67-b4c1d0ec9131@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <5Yxk8oBN69i5Ty_jRCtXoLeNjyet6DEySoFqnzxrblk=.9a1ad401-9da2-4d06-8e22-c51d810dd2f8@github.com>
 <6sjBSQODcXKXzjvshAJiHq96N4Ler-TEBaSuN4nNr6w=.a6ee8ec7-9a3e-49ae-9718-8d1a027e6420@github.com>
 <qn3QRhiyssn_aQeJHdD37WUjjbETj7N5HOKYiZy9wSA=.b1f5b17d-6bb6-4a4a-aa67-b4c1d0ec9131@github.com>
Message-ID: <6dN8IY3rHlVn2aiHJwWdB-OKbbx8GABuvau9-Bdw6vU=.a74101a0-845d-4174-a87a-b41674e90579@github.com>

On Thu, 3 Apr 2025 22:31:27 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 1191:
>> 
>>> 1189:           _verify_remembered_after_full_gc,  // verify read-write remembered set
>>> 1190:           _verify_forwarded_none,      // all objects are non-forwarded
>>> 1191:           _verify_marked_incomplete,   // all objects are marked in incomplete bitmap
>> 
>> Is the marking bitmap updated as objects are moved to their new locations? Is that done just to satisfy the verifier?
>
> Yes, making bitmaps has been reset after full GC,  except for the for regions with pined objects.
> _verify_marked_complete requires complete marking context, it might make more sense to change it to _verify_marked_disable after full GC.

Curious; in that case should it not have failed in your testing because the objects not pinned may not have been marked as the verifier would have insisted they were? Why do we leave the regions with pinned objects marked? I am guessing once we have filled in the dead objects, the marks do not serve any purpose?

May be I am missing some corner case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2027852832

From wkemper at openjdk.org  Thu Apr  3 23:30:44 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 3 Apr 2025 23:30:44 GMT
Subject: RFR: 8350285: Shenandoah: Regression caused by ShenandoahLock under
 extreme contention
Message-ID: <I_Y39HiUgkHYYqV12-alUwHiiAf5viOpQYfjprsz-GM=.0249a3ad-b5e2-46d1-b5b7-b59dd2810c00@github.com>

Clean backport

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

Commit messages:
 - Backport bd8ad309b59bceb3073a8d6411cca74e73508885

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

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

From wkemper at openjdk.org  Thu Apr  3 23:34:15 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 3 Apr 2025 23:34:15 GMT
Subject: Integrated: 8350285: Shenandoah: Regression caused by ShenandoahLock
 under extreme contention
In-Reply-To: <I_Y39HiUgkHYYqV12-alUwHiiAf5viOpQYfjprsz-GM=.0249a3ad-b5e2-46d1-b5b7-b59dd2810c00@github.com>
References: <I_Y39HiUgkHYYqV12-alUwHiiAf5viOpQYfjprsz-GM=.0249a3ad-b5e2-46d1-b5b7-b59dd2810c00@github.com>
Message-ID: <8r5eYLX6cnhVhzL6eNMoTxPWMCF2WpkKZtoexoppaCo=.cd90670c-67e6-4041-a010-c1e082de0776@github.com>

On Thu, 3 Apr 2025 23:26:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: 19cc6266
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/19cc6266643b04dbfffa1a0f667f353f5692113d
Stats:     18 lines in 2 files changed: 15 ins; 0 del; 3 mod

8350285: Shenandoah: Regression caused by ShenandoahLock under extreme contention

Backport-of: bd8ad309b59bceb3073a8d6411cca74e73508885

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

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

From wkemper at openjdk.org  Thu Apr  3 23:37:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 3 Apr 2025 23:37:25 GMT
Subject: RFR: 8350314: Shenandoah: Capture thread state sync times in GC
 timings
Message-ID: <bN9iMi5afRBHw9HKlal-Zu9jYvnhUs8Q1kKUq2SMkWM=.43090ac8-6c5c-4a75-8d27-87590a3d1adb@github.com>

Clean backport

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

Commit messages:
 - Backport 01bd7e417ee3d39067370e616660b7f5c723dc26

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

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

From wkemper at openjdk.org  Fri Apr  4 17:51:12 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 4 Apr 2025 17:51:12 GMT
Subject: Integrated: 8350314: Shenandoah: Capture thread state sync times in GC
 timings
In-Reply-To: <bN9iMi5afRBHw9HKlal-Zu9jYvnhUs8Q1kKUq2SMkWM=.43090ac8-6c5c-4a75-8d27-87590a3d1adb@github.com>
References: <bN9iMi5afRBHw9HKlal-Zu9jYvnhUs8Q1kKUq2SMkWM=.43090ac8-6c5c-4a75-8d27-87590a3d1adb@github.com>
Message-ID: <nZ-VbIswGizAdGhuXhVc737sPYb2aPNy53gOrIunen4=.910ca751-73ed-405a-b546-b6ea329ace05@github.com>

On Thu, 3 Apr 2025 23:33:01 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: 15bdf928
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/15bdf9282c3b393f866d59cc85655ba9d7e1de57
Stats:     47 lines in 6 files changed: 40 ins; 7 del; 0 mod

8350314: Shenandoah: Capture thread state sync times in GC timings

Backport-of: 01bd7e417ee3d39067370e616660b7f5c723dc26

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

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

From xpeng at openjdk.org  Fri Apr  4 18:11:50 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 4 Apr 2025 18:11:50 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v7]
In-Reply-To: <6dN8IY3rHlVn2aiHJwWdB-OKbbx8GABuvau9-Bdw6vU=.a74101a0-845d-4174-a87a-b41674e90579@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <5Yxk8oBN69i5Ty_jRCtXoLeNjyet6DEySoFqnzxrblk=.9a1ad401-9da2-4d06-8e22-c51d810dd2f8@github.com>
 <6sjBSQODcXKXzjvshAJiHq96N4Ler-TEBaSuN4nNr6w=.a6ee8ec7-9a3e-49ae-9718-8d1a027e6420@github.com>
 <qn3QRhiyssn_aQeJHdD37WUjjbETj7N5HOKYiZy9wSA=.b1f5b17d-6bb6-4a4a-aa67-b4c1d0ec9131@github.com>
 <6dN8IY3rHlVn2aiHJwWdB-OKbbx8GABuvau9-Bdw6vU=.a74101a0-845d-4174-a87a-b41674e90579@github.com>
Message-ID: <vIkqQpuOCZVfqNSwDQJy8972svOjS2huDUi95yvF_p8=.dafdedd7-8e7d-4046-b900-7831ebb3dfc0@github.com>

On Thu, 3 Apr 2025 22:55:18 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Yes, making bitmaps has been reset after full GC,  except for the for regions with pined objects.
>> _verify_marked_complete requires complete marking context, it might make more sense to change it to _verify_marked_disable after full GC.
>
> Curious; in that case should it not have failed in your testing because the objects not pinned may not have been marked as the verifier would have insisted they were? Why do we leave the regions with pinned objects marked? I am guessing once we have filled in the dead objects, the marks do not serve any purpose?
> 
> May be I am missing some corner case?

It does, one of the changes https://github.com/openjdk/jdk/pull/24092 is to set the marking completeness flag to false after Full GC because the bitmaps have been reset, `_verify_marked_complete` requires complete marking marking context so there is assert error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2029244689

From xpeng at openjdk.org  Fri Apr  4 18:18:30 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Fri, 4 Apr 2025 18:18:30 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v8]
In-Reply-To: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
Message-ID: <f60runkZ-0vCeBScjCilL3mFGnjHugyg9Oi0KWVAh1Y=.bfd3f127-4969-41ea-87b1-40298d46926b@github.com>

> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed.
> 
> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] Tier 1
> - [x]  Tier 2

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

  Address PR comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23886/files
  - new: https://git.openjdk.org/jdk/pull/23886/files/7c73e121..d4af962a

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

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

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

From wkemper at openjdk.org  Fri Apr  4 19:03:38 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 4 Apr 2025 19:03:38 GMT
Subject: RFR: 8349766: GenShen: Bad progress after degen does not always need
 full gc
Message-ID: <_Tq5x3beVI79gR1U3a3SVkzfh281Bo4OqMa0D1hW29E=.a8e3f513-59a0-4107-bb2f-da08a8630eb8@github.com>

Clean backport

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

Commit messages:
 - Backport 3ae80bfb6085e1a6bcb551c7b0be8f27b6f9fde9

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

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

From wkemper at openjdk.org  Fri Apr  4 19:58:18 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 4 Apr 2025 19:58:18 GMT
Subject: Integrated: 8349766: GenShen: Bad progress after degen does not always
 need full gc
In-Reply-To: <_Tq5x3beVI79gR1U3a3SVkzfh281Bo4OqMa0D1hW29E=.a8e3f513-59a0-4107-bb2f-da08a8630eb8@github.com>
References: <_Tq5x3beVI79gR1U3a3SVkzfh281Bo4OqMa0D1hW29E=.a8e3f513-59a0-4107-bb2f-da08a8630eb8@github.com>
Message-ID: <dm88XMlGZq6RxgNBiogzIYb9JLH_AXkEgZkl-Afmhv8=.b1b645a1-b868-4986-b723-05893e192658@github.com>

On Fri, 4 Apr 2025 18:58:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: fc58c0f4
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/fc58c0f4c09c4a4925057af8065077d8349d82ed
Stats:     20 lines in 2 files changed: 17 ins; 0 del; 3 mod

8349766: GenShen: Bad progress after degen does not always need full gc

Backport-of: 3ae80bfb6085e1a6bcb551c7b0be8f27b6f9fde9

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

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

From wkemper at openjdk.org  Fri Apr  4 20:08:36 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 4 Apr 2025 20:08:36 GMT
Subject: RFR: 8347804: GenShen: Crash with small GCCardSizeInBytes and small
 Java heap
Message-ID: <uonS7aydp73n9wGZXItGFh14fhVN0dzQvC9yom7kmtE=.ca1101c8-0178-43e7-89ac-2620fc2b30b6@github.com>

Not clean, conflicts with SIZE_FORMAT macro removal.

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

Commit messages:
 - Backport 0a4c5a8a483b23ec8c534054187c44f986d137bb

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

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

From kdnilsen at openjdk.org  Sat Apr  5 00:50:10 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 5 Apr 2025 00:50:10 GMT
Subject: RFR: 8347804: GenShen: Crash with small GCCardSizeInBytes and
 small Java heap
In-Reply-To: <uonS7aydp73n9wGZXItGFh14fhVN0dzQvC9yom7kmtE=.ca1101c8-0178-43e7-89ac-2620fc2b30b6@github.com>
References: <uonS7aydp73n9wGZXItGFh14fhVN0dzQvC9yom7kmtE=.ca1101c8-0178-43e7-89ac-2620fc2b30b6@github.com>
Message-ID: <YogoWh5GhM5NUa8bqH4hvwMVmhHdnqSLsm7dY59s100=.80ecad3b-19fe-45c8-9fbb-a9d348b1804e@github.com>

On Fri, 4 Apr 2025 20:03:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, conflicts with SIZE_FORMAT macro removal.

Thanks for doing this backport ...

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/170#pullrequestreview-2744370376

From duke at openjdk.org  Sat Apr  5 14:29:28 2025
From: duke at openjdk.org (Zihao Lin)
Date: Sat, 5 Apr 2025 14:29:28 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v6]
In-Reply-To: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
Message-ID: <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>

> This patch remove slice parameter from LoadNode::make
> 
> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
> 
> Hi team, I am new, I'd appreciate any guidance. Thank a lot!

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

 - Merge branch 'openjdk:master' into 8344116
 - Fix build
 - Fix test failed
 - 8344116: C2: remove slice parameter from LoadNode::make

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24258/files
  - new: https://git.openjdk.org/jdk/pull/24258/files/a1924c35..3efb1c17

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

  Stats: 28443 lines in 792 files changed: 18710 ins; 7734 del; 1999 mod
  Patch: https://git.openjdk.org/jdk/pull/24258.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24258/head:pull/24258

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

From duke at openjdk.org  Sun Apr  6 06:09:05 2025
From: duke at openjdk.org (Zihao Lin)
Date: Sun, 6 Apr 2025 06:09:05 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v6]
In-Reply-To: <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
 <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
Message-ID: <UV5AsCApOF_LUMHmokcDb7FRuhbQaikxcBOXYFRQ0-w=.86d81c61-c14e-4c05-9a0a-6d29c54bfe2d@github.com>

On Sat, 5 Apr 2025 14:29:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> This patch remove slice parameter from LoadNode::make
>> 
>> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
>> 
>> Hi team, I am new, I'd appreciate any guidance. Thank a lot!
>
> Zihao Lin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8344116
>  - Fix build
>  - Fix test failed
>  - 8344116: C2: remove slice parameter from LoadNode::make

Hi @TobiHartmann , Could you please take a look? Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/24258#issuecomment-2781240184

From jsikstro at openjdk.org  Mon Apr  7 11:33:57 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 7 Apr 2025 11:33:57 GMT
Subject: RFR: 8353559: Restructure CollectedHeap error printing
In-Reply-To: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
References: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
Message-ID: <9tbw7_56t4aDDTVE-KI9b84ccG_Iky2LRhsMmL0gXF0=.f03a1ac0-099f-465d-977d-751f7b5cf7ff@github.com>

On Wed, 2 Apr 2025 18:09:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Calling Universe::heap()->print_on_error() gets dispatched to the most specific implementation, which for some GCs is their own implementation instead of the default in CollectedHeap. Each GC-specific implementation calls back to CollectedHeap::print_on_error(), which then dispatches back into the specific implementation of print_on(). This is kind of awkward and creates a call-chain that's not straightforward to wrap your head around, jumping back and forth via CollectedHeap and the specific implementation.
> 
> To make the call-chain cleaner, I have made print_on_error() a pure virtual method in CollectedHeap, and implemented print_on_error() in each GC's implementation of CollectedHeap. In addition, I have removed print_extended_on() from CollectedHeap and implemented that for the GCs that actually need/use it.
> 
> Removing the usage of the common print_on_error() also means that GCs that do not print anything interesting for their barrier set can omit this. So, I've removed it from ZGC and Shenandoah.
> 
> To make print_on_error() consistent with print_on(), I have moved the printing of "Heap:" to the caller(s) of print_on_error() (only inside vmError.cpp). This is a trivial change for all GCs except ZGC, which requires some restructuring in its error printing.
> 
> The old and new printing orders are shown below for ZGC:
> 
> # Old
> <precious log>
> <zgc globals>
> <heap>
> <zgc page table>
> <barrier set>
> <polling page>
> 
> 
> 
> # New
> <precious log>
> <heap>
> <zgc globals>
> <zgc page table>
> <polling page>
> 
> 
> Testing:
> * GHA
> * Tiers 1 & 2
> * Manually verified that printing still works and outputs the intended information via running the following commands and comparing the output.
> 
> ../fastdebug-old/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_old.txt
> ../fastdebug-new/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_new.txt

Since this is a relatively small change, I'm hoping that the Shenandoah devs are on board. I am going to integrate this now so that we can continue working in this area in ZGC. I am happy to follow up on this if there are any more opinions in the future.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24387#issuecomment-2783006637

From jsikstro at openjdk.org  Mon Apr  7 11:33:58 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Mon, 7 Apr 2025 11:33:58 GMT
Subject: Integrated: 8353559: Restructure CollectedHeap error printing
In-Reply-To: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
References: <zlp0KDeXSU_raUjPR4_Am_5ipCFp-YwZDxY2IkEQyoU=.6203f238-7573-4610-a1cb-40d9360b62a3@github.com>
Message-ID: <sOIlRbLevotK3H8KqHch8cV4Fo7NbSmkTlawFMVrfRw=.affe60a3-152a-4029-86d2-af84f7300150@github.com>

On Wed, 2 Apr 2025 18:09:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Calling Universe::heap()->print_on_error() gets dispatched to the most specific implementation, which for some GCs is their own implementation instead of the default in CollectedHeap. Each GC-specific implementation calls back to CollectedHeap::print_on_error(), which then dispatches back into the specific implementation of print_on(). This is kind of awkward and creates a call-chain that's not straightforward to wrap your head around, jumping back and forth via CollectedHeap and the specific implementation.
> 
> To make the call-chain cleaner, I have made print_on_error() a pure virtual method in CollectedHeap, and implemented print_on_error() in each GC's implementation of CollectedHeap. In addition, I have removed print_extended_on() from CollectedHeap and implemented that for the GCs that actually need/use it.
> 
> Removing the usage of the common print_on_error() also means that GCs that do not print anything interesting for their barrier set can omit this. So, I've removed it from ZGC and Shenandoah.
> 
> To make print_on_error() consistent with print_on(), I have moved the printing of "Heap:" to the caller(s) of print_on_error() (only inside vmError.cpp). This is a trivial change for all GCs except ZGC, which requires some restructuring in its error printing.
> 
> The old and new printing orders are shown below for ZGC:
> 
> # Old
> <precious log>
> <zgc globals>
> <heap>
> <zgc page table>
> <barrier set>
> <polling page>
> 
> 
> 
> # New
> <precious log>
> <heap>
> <zgc globals>
> <zgc page table>
> <polling page>
> 
> 
> Testing:
> * GHA
> * Tiers 1 & 2
> * Manually verified that printing still works and outputs the intended information via running the following commands and comparing the output.
> 
> ../fastdebug-old/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_old.txt
> ../fastdebug-new/jdk/bin/java -XX:ErrorHandlerTest=14 -XX:+ErrorFileToStdout -XX:+Use${gc}GC --version > ${gc}_new.txt

This pull request has now been integrated.

Changeset: c494a00a
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c494a00a66d21d2e403fd9ce253eb132c34e455d
Stats:     141 lines in 16 files changed: 75 ins; 52 del; 14 mod

8353559: Restructure CollectedHeap error printing

Reviewed-by: stefank, eosterlund, ayang

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

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

From gziemski at openjdk.org  Mon Apr  7 13:16:57 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 7 Apr 2025 13:16:57 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v8]
In-Reply-To: <vnB9DaXVrJBc1nHQZC0uxCPay8k-sP4lzWIaPVEJ18g=.bca8d46f-c781-4ab3-87e9-2ee26f00f9b5@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <5b6QutsBRX4KGZY50opOtRztczGFdilIy3CwlisJ4s4=.7b8a3f1a-4f6f-469f-829b-1d693ad1355d@github.com>
 <vnB9DaXVrJBc1nHQZC0uxCPay8k-sP4lzWIaPVEJ18g=.bca8d46f-c781-4ab3-87e9-2ee26f00f9b5@github.com>
Message-ID: <5_Vl9wYJivfVf33dr0MVpWcufWJ_JPvpmWFvVkzm6Ds=.6c5adc3c-dbac-4af5-9566-29cb14f7ee51@github.com>

On Thu, 3 Apr 2025 11:16:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   The real feedback from StefanK
>
> src/hotspot/share/runtime/os.hpp line 527:
> 
>> 525: 
>> 526:   static char*  map_memory(int fd, const char* file_name, size_t file_offset,
>> 527:                            char *addr, size_t bytes, MemTag mem_tag, bool read_only = false,
> 
> AFAICT, there's no need to have a default value for read_only. I think we should remove this default value and move the MemTag parameter so that it comes after read_only and before allow_exec. This would make the parameter order more consistent with the other functions that accept a mem_tag and an executable.
> 
> Given that you have tested the current patch, I'm fine with doing this as a small follow-up patch.

Filed [NMT: change map_memory() signature to match other functions](https://bugs.openjdk.org/browse/JDK-8353854)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24282#discussion_r2031217805

From gziemski at openjdk.org  Mon Apr  7 13:30:45 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 7 Apr 2025 13:30:45 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v8]
In-Reply-To: <5b6QutsBRX4KGZY50opOtRztczGFdilIy3CwlisJ4s4=.7b8a3f1a-4f6f-469f-829b-1d693ad1355d@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <5b6QutsBRX4KGZY50opOtRztczGFdilIy3CwlisJ4s4=.7b8a3f1a-4f6f-469f-829b-1d693ad1355d@github.com>
Message-ID: <upuGq917Gy2vglCvv8TfYDszU1--3hKrAeVLtEhcfmM=.7ec7163d-9d8e-4403-a6cc-f8773b59ce30@github.com>

On Wed, 2 Apr 2025 18:37:36 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   The real feedback from StefanK

Thank you Stefan for all your feedback and help! Very much appreciated!

@afshin-zafari @jdksjolen I need one more review to move forward, could you please take a look?

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2783327357
PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2783334036

From gziemski at openjdk.org  Mon Apr  7 13:30:44 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 7 Apr 2025 13:30:44 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v9]
In-Reply-To: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
Message-ID: <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>

> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  small last feedback from Stefan

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24282/files
  - new: https://git.openjdk.org/jdk/pull/24282/files/3bd03cbe..88525c57

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

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

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

From wkemper at openjdk.org  Mon Apr  7 16:26:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 7 Apr 2025 16:26:31 GMT
Subject: Integrated: 8347804: GenShen: Crash with small GCCardSizeInBytes and
 small Java heap
In-Reply-To: <uonS7aydp73n9wGZXItGFh14fhVN0dzQvC9yom7kmtE=.ca1101c8-0178-43e7-89ac-2620fc2b30b6@github.com>
References: <uonS7aydp73n9wGZXItGFh14fhVN0dzQvC9yom7kmtE=.ca1101c8-0178-43e7-89ac-2620fc2b30b6@github.com>
Message-ID: <_o44nrBRwxFNmtC8xV1rbg-qjb9NhRa-mBj0Mw8sfz4=.5c29799f-0851-44ba-b2d3-b1829ef7bf6b@github.com>

On Fri, 4 Apr 2025 20:03:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, conflicts with SIZE_FORMAT macro removal.

This pull request has now been integrated.

Changeset: f2d843e1
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/f2d843e1f81bbcf81a780f509930c79d1774c153
Stats:     86 lines in 5 files changed: 63 ins; 4 del; 19 mod

8347804: GenShen: Crash with small GCCardSizeInBytes and small Java heap

Reviewed-by: kdnilsen
Backport-of: 0a4c5a8a483b23ec8c534054187c44f986d137bb

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

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

From ysr at openjdk.org  Tue Apr  8 01:29:09 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 8 Apr 2025 01:29:09 GMT
Subject: RFR: 8353218: Shenandoah: Out of date comment references Brooks
 pointers
In-Reply-To: <eg0ZISI_m2Q3w3R8yxhyTBpZJyKSsWknhaG34M0X0LI=.53914680-01da-49e6-a8b0-a221e813ff2e@github.com>
References: <eg0ZISI_m2Q3w3R8yxhyTBpZJyKSsWknhaG34M0X0LI=.53914680-01da-49e6-a8b0-a221e813ff2e@github.com>
Message-ID: <-zSlCWIHyxeR9-mjP1si49UGzRl9qMSSWscVELQxYAQ=.8f6e1108-bd47-49f8-918b-c2f6c9eb640b@github.com>

On Fri, 28 Mar 2025 23:33:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Trivial change, comment only.

Thanks for fixing this!

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24304#pullrequestreview-2748445404

From thartmann at openjdk.org  Tue Apr  8 08:05:29 2025
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 8 Apr 2025 08:05:29 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v6]
In-Reply-To: <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
 <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
Message-ID: <ckmsCGQWmE8_DR7uyfvs4nTYaoUNw73Wlf9LJ9GshFE=.c48d2a36-9da5-4358-a27d-04ee530cd41c@github.com>

On Sat, 5 Apr 2025 14:29:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> This patch remove slice parameter from LoadNode::make
>> 
>> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
>> 
>> Hi team, I am new, I'd appreciate any guidance. Thank a lot!
>
> Zihao Lin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8344116
>  - Fix build
>  - Fix test failed
>  - 8344116: C2: remove slice parameter from LoadNode::make

I think @rwestrel should have a look at this, since he suggested the cleanup in https://github.com/openjdk/jdk/pull/21834.

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

PR Comment: https://git.openjdk.org/jdk/pull/24258#issuecomment-2785582950

From stefank at openjdk.org  Tue Apr  8 13:12:23 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 8 Apr 2025 13:12:23 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v9]
In-Reply-To: <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>
Message-ID: <lQoNX7_uxBoEC3i9M9B2lDxqoOujyJRHLI3iHo09oik=.756e7bda-7c2b-422c-9ebc-2730fb140d79@github.com>

On Mon, 7 Apr 2025 13:30:44 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small last feedback from Stefan

Looks good. Thanks for incorporating my suggestions!

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24282#pullrequestreview-2749927765

From roland at openjdk.org  Tue Apr  8 13:14:25 2025
From: roland at openjdk.org (Roland Westrelin)
Date: Tue, 8 Apr 2025 13:14:25 GMT
Subject: RFR: 8344116: C2: remove slice parameter from LoadNode::make [v6]
In-Reply-To: <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
References: <Po0DIjZv6wmSdwNcL1BeN5s9xvih8YKDqaw7Io5wIl8=.82dc3319-de61-4afc-898c-a7550bf9c9ac@github.com>
 <m5vB8Gn_q-PnqON5IRqcftiaBdiDc04bSlDi2eyk68M=.20e35f3e-28f8-492d-b813-4ee04beaf803@github.com>
Message-ID: <F05XhIeM-2KYesDRQ4dtGv2iui5GvLh3hF_udP5IFjM=.8fd0ede3-df42-4d10-9aa9-85e6ea500d4a@github.com>

On Sat, 5 Apr 2025 14:29:28 GMT, Zihao Lin <duke at openjdk.org> wrote:

>> This patch remove slice parameter from LoadNode::make
>> 
>> Mention in https://github.com/openjdk/jdk/pull/21834#pullrequestreview-2429164805
>> 
>> Hi team, I am new, I'd appreciate any guidance. Thank a lot!
>
> Zihao Lin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8344116
>  - Fix build
>  - Fix test failed
>  - 8344116: C2: remove slice parameter from LoadNode::make

src/hotspot/share/gc/shared/c2/barrierSetC2.cpp line 223:

> 221:     MergeMemNode* mm = opt_access.mem();
> 222:     PhaseGVN& gvn = opt_access.gvn();
> 223:     Node* mem = mm->memory_at(gvn.C->get_alias_index(access.addr().type()));

Can we get rid of all uses of `access.addr().type()`?

src/hotspot/share/gc/shared/c2/cardTableBarrierSetC2.cpp line 105:

> 103:     // stores.  In theory we could relax the load from ctrl() to
> 104:     // no_ctrl, but that doesn't buy much latitude.
> 105:     Node* card_val = __ load( __ ctrl(), card_adr, TypeInt::BYTE, T_BYTE);

We could asssert that `C->get_alias_index(kit->type(card_adr) == Compile::AliasIdxRaw`, that is that computed slice is the same as hardcoded slide. Similar asserts could be added for every location where a slice/address type is removed in this patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24258#discussion_r2033149694
PR Review Comment: https://git.openjdk.org/jdk/pull/24258#discussion_r2033162534

From ysr at openjdk.org  Tue Apr  8 21:54:25 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 8 Apr 2025 21:54:25 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v4]
In-Reply-To: <JafFKLni2KuONpfU77jPe9JpYWjy-HYgjQcomECnF3E=.622319b2-a483-45b7-96ff-f06f4522a973@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <A_CO1fVrNHccOfpMVqUq73n13xpdjKMnsZLwIiH4uTk=.5331d3f3-91e5-482f-ba2c-c4ba2d380981@github.com>
 <c98-Q1B9uQuWe7E5_jF51rS-2165EvnXbEEiHR3poZM=.2f337747-b2d8-46da-966c-a5009a694c70@github.com>
 <kzfre6g611k1gQ0iCsbgDps0CGpAXHkIxtXGajw-Io8=.f784cdd1-5837-495e-92e7-e5f5a8ddaccb@github.com>
 <JafFKLni2KuONpfU77jPe9JpYWjy-HYgjQcomECnF3E=.622319b2-a483-45b7-96ff-f06f4522a973@github.com>
Message-ID: <iKQvxf_b7RlidRQtvYdtlx7on4KsPv8eJVsGKWRqdaI=.aa902e0b-6c75-4ff7-8d74-be9f5e1de2b0@github.com>

On Fri, 7 Mar 2025 00:33:58 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Right, active_generation should be used instead of global_generation to get the complete marking context, with the context of full GC, even we know it active_generation is the global gen, but it's better not to use global_generation directly for better maintainable code.
>
> Updated it to use active_generation.

Thanks for the fixes; this looks good!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2034084571

From wkemper at openjdk.org  Tue Apr  8 22:04:34 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Apr 2025 22:04:34 GMT
Subject: Integrated: 8353218: Shenandoah: Out of date comment references Brooks
 pointers
In-Reply-To: <eg0ZISI_m2Q3w3R8yxhyTBpZJyKSsWknhaG34M0X0LI=.53914680-01da-49e6-a8b0-a221e813ff2e@github.com>
References: <eg0ZISI_m2Q3w3R8yxhyTBpZJyKSsWknhaG34M0X0LI=.53914680-01da-49e6-a8b0-a221e813ff2e@github.com>
Message-ID: <rtVGCiGDzDq__mX-fmOeBNMNQy1qRJzjOeuaDrVpJ7w=.62bb3593-ad47-47a0-a8d3-c630eee04e93@github.com>

On Fri, 28 Mar 2025 23:33:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Trivial change, comment only.

This pull request has now been integrated.

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

8353218: Shenandoah: Out of date comment references Brooks pointers

Reviewed-by: ysr, kdnilsen

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

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

From wkemper at openjdk.org  Tue Apr  8 22:23:16 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 8 Apr 2025 22:23:16 GMT
Subject: RFR: 8342444: Shenandoah: Uncommit regions from a separate,
 STS aware thread
Message-ID: <gHDJhIDyewnf0wEcVh35e02a_gUQjEOXd6x7U0EtVEA=.4ba5313b-7c2d-4d31-9817-8b90d2f21845@github.com>

Not clean, has follow up bug fix

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

Commit messages:
 - 8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them
 - 8342444: Shenandoah: Uncommit regions from a separate, STS aware thread

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/171/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=171&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342444
  Stats: 515 lines in 9 files changed: 398 ins; 89 del; 28 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/171.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/171/head:pull/171

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

From ysr at openjdk.org  Tue Apr  8 23:30:27 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 8 Apr 2025 23:30:27 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v8]
In-Reply-To: <f60runkZ-0vCeBScjCilL3mFGnjHugyg9Oi0KWVAh1Y=.bfd3f127-4969-41ea-87b1-40298d46926b@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <f60runkZ-0vCeBScjCilL3mFGnjHugyg9Oi0KWVAh1Y=.bfd3f127-4969-41ea-87b1-40298d46926b@github.com>
Message-ID: <blrnqyVEK9b42fPLLa5NrdPg71dO9mkss7FUf5Igtus=.19bc45fb-f697-46b4-9931-06b75cb99e83@github.com>

On Fri, 4 Apr 2025 18:18:30 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed.
>> 
>> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] Tier 1
>> - [x]  Tier 2
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR comments

LGTM! Thanks for your patience!

?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23886#pullrequestreview-2751608049

From ysr at openjdk.org  Tue Apr  8 23:30:28 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 8 Apr 2025 23:30:28 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v7]
In-Reply-To: <vIkqQpuOCZVfqNSwDQJy8972svOjS2huDUi95yvF_p8=.dafdedd7-8e7d-4046-b900-7831ebb3dfc0@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <5Yxk8oBN69i5Ty_jRCtXoLeNjyet6DEySoFqnzxrblk=.9a1ad401-9da2-4d06-8e22-c51d810dd2f8@github.com>
 <6sjBSQODcXKXzjvshAJiHq96N4Ler-TEBaSuN4nNr6w=.a6ee8ec7-9a3e-49ae-9718-8d1a027e6420@github.com>
 <qn3QRhiyssn_aQeJHdD37WUjjbETj7N5HOKYiZy9wSA=.b1f5b17d-6bb6-4a4a-aa67-b4c1d0ec9131@github.com>
 <6dN8IY3rHlVn2aiHJwWdB-OKbbx8GABuvau9-Bdw6vU=.a74101a0-845d-4174-a87a-b41674e90579@github.com>
 <vIkqQpuOCZVfqNSwDQJy8972svOjS2huDUi95yvF_p8=.dafdedd7-8e7d-4046-b900-7831ebb3dfc0@github.com>
Message-ID: <y-Y2HUHRK8eVy_p5Kyy5fKC5ilG87rNuWhaM5wi6yAM=.03efb3a1-6fc4-45df-9b33-8289c7334d57@github.com>

On Fri, 4 Apr 2025 18:09:36 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> Curious; in that case should it not have failed in your testing because the objects not pinned may not have been marked as the verifier would have insisted they were? Why do we leave the regions with pinned objects marked? I am guessing once we have filled in the dead objects, the marks do not serve any purpose?
>> 
>> May be I am missing some corner case?
>
> It does, one of the changes in https://github.com/openjdk/jdk/pull/24092 is to set the marking completeness flag to false after Full GC because the bitmaps have been reset, `_verify_marked_complete` requires complete marking marking context so there is assert error.

Thanks; I looked through the code and see where I had confused myself above. This looks good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2034163269

From xpeng at openjdk.org  Tue Apr  8 23:45:33 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 8 Apr 2025 23:45:33 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v8]
In-Reply-To: <f60runkZ-0vCeBScjCilL3mFGnjHugyg9Oi0KWVAh1Y=.bfd3f127-4969-41ea-87b1-40298d46926b@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <f60runkZ-0vCeBScjCilL3mFGnjHugyg9Oi0KWVAh1Y=.bfd3f127-4969-41ea-87b1-40298d46926b@github.com>
Message-ID: <OYV9FsDgzOGxzwGgGOSUc6Gbzbat4LITCxYdlCMZYxs=.f4b1c429-1f39-4f21-88b6-5fab027c8856@github.com>

On Fri, 4 Apr 2025 18:18:30 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed.
>> 
>> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] Tier 1
>> - [x]  Tier 2
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR comments

thanks all for the reviews and suggestions!

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

PR Comment: https://git.openjdk.org/jdk/pull/23886#issuecomment-2787875051

From duke at openjdk.org  Tue Apr  8 23:45:33 2025
From: duke at openjdk.org (duke)
Date: Tue, 8 Apr 2025 23:45:33 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v8]
In-Reply-To: <f60runkZ-0vCeBScjCilL3mFGnjHugyg9Oi0KWVAh1Y=.bfd3f127-4969-41ea-87b1-40298d46926b@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <f60runkZ-0vCeBScjCilL3mFGnjHugyg9Oi0KWVAh1Y=.bfd3f127-4969-41ea-87b1-40298d46926b@github.com>
Message-ID: <3CxQWRmVEeYX_O3D2Lh5-1GiTRLSZRkaNKDc3ztM2ZE=.68ecc2fe-b5e1-4e62-a58e-0de858d9dc5f@github.com>

On Fri, 4 Apr 2025 18:18:30 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

>> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed.
>> 
>> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API.
>> 
>> ### Test
>> - [x] hotspot_gc_shenandoah
>> - [x] Tier 1
>> - [x]  Tier 2
>
> Xiaolong Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address PR comments

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

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

PR Comment: https://git.openjdk.org/jdk/pull/23886#issuecomment-2787877229

From xpeng at openjdk.org  Tue Apr  8 23:45:34 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Tue, 8 Apr 2025 23:45:34 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained [v7]
In-Reply-To: <y-Y2HUHRK8eVy_p5Kyy5fKC5ilG87rNuWhaM5wi6yAM=.03efb3a1-6fc4-45df-9b33-8289c7334d57@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
 <5Yxk8oBN69i5Ty_jRCtXoLeNjyet6DEySoFqnzxrblk=.9a1ad401-9da2-4d06-8e22-c51d810dd2f8@github.com>
 <6sjBSQODcXKXzjvshAJiHq96N4Ler-TEBaSuN4nNr6w=.a6ee8ec7-9a3e-49ae-9718-8d1a027e6420@github.com>
 <qn3QRhiyssn_aQeJHdD37WUjjbETj7N5HOKYiZy9wSA=.b1f5b17d-6bb6-4a4a-aa67-b4c1d0ec9131@github.com>
 <6dN8IY3rHlVn2aiHJwWdB-OKbbx8GABuvau9-Bdw6vU=.a74101a0-845d-4174-a87a-b41674e90579@github.com>
 <vIkqQpuOCZVfqNSwDQJy8972svOjS2huDUi95yvF_p8=.dafdedd7-8e7d-4046-b900-7831ebb3dfc0@github.com>
 <y-Y2HUHRK8eVy_p5Kyy5fKC5ilG87rNuWhaM5wi6yAM=.03efb3a1-6fc4-45df-9b33-8289c7334d57@github.com>
Message-ID: <6D387djX5BAacoBeaJCLj1HGYsNoRm3lTWVipWp6vn0=.ed5303a1-0107-405f-a0d0-e1360315fc46@github.com>

On Tue, 8 Apr 2025 23:27:33 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> It does, one of the changes in https://github.com/openjdk/jdk/pull/24092 is to set the marking completeness flag to false after Full GC because the bitmaps have been reset, `_verify_marked_complete` requires complete marking marking context so there is assert error.
>
> Thanks; I looked through the code and see where I had confused myself above. This looks good to me.

thank you!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23886#discussion_r2034171337

From kdnilsen at openjdk.org  Wed Apr  9 00:20:29 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 9 Apr 2025 00:20:29 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data
In-Reply-To: <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
Message-ID: <U77kqsRSBlKq2mS_cNrd77-pjafw2WBLyer03epT0XY=.9cbfeaae-866a-4634-9cc2-5ee318a4ac0a@github.com>

On Tue, 1 Apr 2025 17:49:38 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
>> 
>> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
>> 
>> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.inline.hpp line 159:
> 
>> 157: 
>> 158: inline size_t ShenandoahHeapRegion::get_mixed_candidate_live_data_bytes() const {
>> 159:   assert(SafepointSynchronize::is_at_safepoint(), "Should be at Shenandoah safepoint");
> 
> Could we use `shenandoah_assert_safepoint` here (and other places) instead?

Good call.  I'll make this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2034198164

From kdnilsen at openjdk.org  Wed Apr  9 00:29:25 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 9 Apr 2025 00:29:25 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data
In-Reply-To: <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
Message-ID: <mSt6hLV9yD3Ep5dUUM2mMo6Ic6ipp18qWxb6YlZfr30=.f4e79130-54f3-49ae-9ac8-784cd6ed9825@github.com>

On Tue, 1 Apr 2025 18:16:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
>> 
>> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
>> 
>> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 78:
> 
>> 76:   _live_data(0),
>> 77:   _critical_pins(0),
>> 78:   _mixed_candidate_garbage_words(0),
> 
> Do we need a new field to track this? During `final_mark`, we call `increase_live_data_alloc_words` to add `TAMS + top` to `_live_data` to account for objects allocated during mark. Could we "fix" `get_live_data` so that it always returned marked objects (counted by `increase_live_data_gc_words`) _plus_ `top - TAMS`. This way, the live data would not become stale after `final_mark` and we wouldn't have another field to manage. What do you think?

This is a good idea.  Let me experiment with this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2034208988

From xpeng at openjdk.org  Wed Apr  9 01:02:41 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 9 Apr 2025 01:02:41 GMT
Subject: Integrated: 8351091: Shenandoah: global marking context completeness
 is  not accurately maintained
In-Reply-To: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
References: <xaDE5v-It9OOCTL8rwXQNp-N3yJz8_ZmRAwThUIyZAo=.1f0175e7-deb6-4111-8c7c-2445d5c48c50@github.com>
Message-ID: <D8rN7KY5msw6zRD0mMRVr0tUofOq7qgGc7iqoWrCQrc=.995f254b-35a0-4e6a-a547-03dad0dc33e4@github.com>

On Tue, 4 Mar 2025 08:34:16 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> With the JEP 404: Generational Shenandoah implementation, there are generation specific marking completeness flags introduced, and the global marking context completeness flag is not updated at all after initialization, hence the global marking context completeness is not accurate anymore. This may cause expected behavior: [ShenandoahHeap::complete_marking_context()](https://github.com/openjdk/jdk/pull/23886/files#diff-d5ddf298c36b1c91bf33f9bff7bedcc063074edd68c298817f1fdf39d2ed970fL642) should throw assert error if the global marking context completeness flag is false, but now it always return the marking context even it marking is not complete, this may hide bugs where we expect the global/generational marking to be completed.
> 
> This change PR fix the bug in global marking context completeness flag, and update all the places using `ShenandoahHeap::complete_marking_context()` to use proper API.
> 
> ### Test
> - [x] hotspot_gc_shenandoah
> - [x] Tier 1
> - [x]  Tier 2

This pull request has now been integrated.

Changeset: aec1fe0a
Author:    Xiaolong Peng <xpeng at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aec1fe0a17fa6801e26a517d4d21656353409f7c
Stats:     71 lines in 17 files changed: 7 ins; 34 del; 30 mod

8351091: Shenandoah: global marking context completeness is  not accurately maintained

Reviewed-by: ysr, wkemper

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

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

From kdnilsen at openjdk.org  Wed Apr  9 01:55:48 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 9 Apr 2025 01:55:48 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v2]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <8UF5sC8lbb-hBUpkbzDarvFxOlbQU0nDPbTqWhAedM0=.e078bb2a-2331-47f7-aa67-807d09c4ca11@github.com>

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

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

  Experiment with reviewer suggestion
  
  Redefine the way ShenandoahHeapRegion::get_live_data_<type> works to
  simplify changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24319/files
  - new: https://git.openjdk.org/jdk/pull/24319/files/70613882..3c1f788a

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

  Stats: 28 lines in 5 files changed: 15 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/24319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319

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

From ysr at openjdk.org  Wed Apr  9 02:07:44 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 9 Apr 2025 02:07:44 GMT
Subject: RFR: 8342444: Shenandoah: Uncommit regions from a separate,
 STS aware thread
In-Reply-To: <gHDJhIDyewnf0wEcVh35e02a_gUQjEOXd6x7U0EtVEA=.4ba5313b-7c2d-4d31-9817-8b90d2f21845@github.com>
References: <gHDJhIDyewnf0wEcVh35e02a_gUQjEOXd6x7U0EtVEA=.4ba5313b-7c2d-4d31-9817-8b90d2f21845@github.com>
Message-ID: <KE2CIqzfvyYEq8qvk-ehRQSbGytMQq_d-rsLt2wLymI=.76c3364a-d2a1-4d55-adbd-548a55d26a98@github.com>

On Tue, 8 Apr 2025 21:35:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, has follow up bug fix

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/171#pullrequestreview-2751863532

From shade at openjdk.org  Wed Apr  9 08:31:44 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Apr 2025 08:31:44 GMT
Subject: RFR: 8351157: Clean up x86 GC barriers after 32-bit x86 removal
 [v3]
In-Reply-To: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
References: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
Message-ID: <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>

> Assembler GC barriers have quite a bit of coding to support 32-bit x86. As 32-bit x86 is removed, we can clean up those parts.
> 
> We can eliminate `!LP64` blocks quite easily. We can also prune passing around `thread` argument, and just trust that `r15_thread` is always available.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8351157-x86-gc-barriers
 - Merge branch 'master' into JDK-8351157-x86-gc-barriers
 - Also do tlab_allocate
 - Rely on R15 to be a thread register
 - Work

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

Changes: https://git.openjdk.org/jdk/pull/24253/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24253&range=02
  Stats: 543 lines in 20 files changed: 1 ins; 426 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/24253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24253/head:pull/24253

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

From shade at openjdk.org  Wed Apr  9 08:31:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Apr 2025 08:31:45 GMT
Subject: RFR: 8351157: Clean up x86 GC barriers after 32-bit x86 removal
 [v2]
In-Reply-To: <6aXRsWRRGrrJdkmNcZHPw8JBD5piGr6UrmjOdnHjlMY=.3dde2c28-bdfc-4eb1-8d1d-7a4c85d3234f@github.com>
References: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
 <6aXRsWRRGrrJdkmNcZHPw8JBD5piGr6UrmjOdnHjlMY=.3dde2c28-bdfc-4eb1-8d1d-7a4c85d3234f@github.com>
Message-ID: <44v659C-wJrB9RUCDMFObzkSMYE6zEdyx5oRzK7axHI=.71443b71-c44c-4661-8ec3-f34f15d2ffe2@github.com>

On Thu, 27 Mar 2025 12:31:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Assembler GC barriers have quite a bit of coding to support 32-bit x86. As 32-bit x86 is removed, we can clean up those parts.
>> 
>> We can eliminate `!LP64` blocks quite easily. We can also prune passing around `thread` argument, and just trust that `r15_thread` is always available.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Also do tlab_allocate
>  - Rely on R15 to be a thread register
>  - Work

Friendly reminder :)

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

PR Comment: https://git.openjdk.org/jdk/pull/24253#issuecomment-2788776594

From kbarrett at openjdk.org  Wed Apr  9 09:42:42 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 9 Apr 2025 09:42:42 GMT
Subject: RFR: 8351157: Clean up x86 GC barriers after 32-bit x86 removal
 [v3]
In-Reply-To: <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
References: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
 <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
Message-ID: <Xn0BO50ArtU8T6zI8PUQNio9Y2RLBNrKnd1ZKEs6E6A=.080387da-785b-43b5-9d3c-a86d67997c98@github.com>

On Wed, 9 Apr 2025 08:31:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Assembler GC barriers have quite a bit of coding to support 32-bit x86. As 32-bit x86 is removed, we can clean up those parts.
>> 
>> We can eliminate `!LP64` blocks quite easily. We can also prune passing around `thread` argument, and just trust that `r15_thread` is always available.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Also do tlab_allocate
>  - Rely on R15 to be a thread register
>  - Work

Still looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24253#pullrequestreview-2752823687

From shade at openjdk.org  Wed Apr  9 15:13:08 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Apr 2025 15:13:08 GMT
Subject: RFR: 8351152: x86: Remove code blocks that handle UseSSE < 2
Message-ID: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>

32-bit x86 was the platform that supported `UseSSE < 2`. 64-bit x86 baselines on `UseSSE >= 2`. After 32-bit x86 code is gone, we can remove all code blocks that are there to support `UseSSE < 2`.

Additional testing:
 - [x] Linux x86_64 server fastdebug, `all`

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

Commit messages:
 - Also 24-bit removals
 - Touchups
 - Fix

Changes: https://git.openjdk.org/jdk/pull/24484/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24484&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351152
  Stats: 643 lines in 16 files changed: 34 ins; 363 del; 246 mod
  Patch: https://git.openjdk.org/jdk/pull/24484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24484/head:pull/24484

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

From kdnilsen at openjdk.org  Wed Apr  9 15:18:58 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 9 Apr 2025 15:18:58 GMT
Subject: RFR: 8342444: Shenandoah: Uncommit regions from a separate,
 STS aware thread
In-Reply-To: <gHDJhIDyewnf0wEcVh35e02a_gUQjEOXd6x7U0EtVEA=.4ba5313b-7c2d-4d31-9817-8b90d2f21845@github.com>
References: <gHDJhIDyewnf0wEcVh35e02a_gUQjEOXd6x7U0EtVEA=.4ba5313b-7c2d-4d31-9817-8b90d2f21845@github.com>
Message-ID: <TbBCVjejlObc3m5WpYR9cUQUfnhjsJQ5-k8amgM5m3k=.6773f0e8-ff6b-445d-8ef1-748ef9902f2e@github.com>

On Tue, 8 Apr 2025 21:35:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, has follow up bug fix

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/171#pullrequestreview-2753862997

From shade at openjdk.org  Wed Apr  9 16:06:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 9 Apr 2025 16:06:45 GMT
Subject: RFR: 8351152: x86: Remove code blocks that handle UseSSE < 2 [v2]
In-Reply-To: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>
References: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>
Message-ID: <lCCpaLZzch6si0oZEvasmRFFlRH-aSy_Ho95WlD-RTk=.4263f81e-6667-4195-a9d0-f89356bfbabd@github.com>

> 32-bit x86 was the platform that supported `UseSSE < 2`. 64-bit x86 baselines on `UseSSE >= 2`: https://github.com/openjdk/jdk/blob/567c6885a377e5641deef9cd3498f79c5346cd6a/src/hotspot/cpu/x86/vm_version_x86.cpp#L895-L902
> 
> After 32-bit x86 code is gone, we can remove all code blocks that are there to support `UseSSE < 2`.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Also purge vestigial calls to VMVersion::supports_sse{2}

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24484/files
  - new: https://git.openjdk.org/jdk/pull/24484/files/04f50944..7f505137

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

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

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

From kvn at openjdk.org  Wed Apr  9 16:06:45 2025
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 9 Apr 2025 16:06:45 GMT
Subject: RFR: 8351152: x86: Remove code blocks that handle UseSSE < 2 [v2]
In-Reply-To: <lCCpaLZzch6si0oZEvasmRFFlRH-aSy_Ho95WlD-RTk=.4263f81e-6667-4195-a9d0-f89356bfbabd@github.com>
References: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>
 <lCCpaLZzch6si0oZEvasmRFFlRH-aSy_Ho95WlD-RTk=.4263f81e-6667-4195-a9d0-f89356bfbabd@github.com>
Message-ID: <TCPq_YHr84HmFnmYlhOSg5SVre0hQljqdEBA5Tampps=.08db2054-cfa7-4e5c-898f-a016b0afa8d0@github.com>

On Wed, 9 Apr 2025 16:03:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 32-bit x86 was the platform that supported `UseSSE < 2`. 64-bit x86 baselines on `UseSSE >= 2`: https://github.com/openjdk/jdk/blob/567c6885a377e5641deef9cd3498f79c5346cd6a/src/hotspot/cpu/x86/vm_version_x86.cpp#L895-L902
>> 
>> After 32-bit x86 code is gone, we can remove all code blocks that are there to support `UseSSE < 2`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Also purge vestigial calls to VMVersion::supports_sse{2}

Looks good.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24484#pullrequestreview-2754003015

From kdnilsen at openjdk.org  Wed Apr  9 17:05:38 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 9 Apr 2025 17:05:38 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v2]
In-Reply-To: <mSt6hLV9yD3Ep5dUUM2mMo6Ic6ipp18qWxb6YlZfr30=.f4e79130-54f3-49ae-9ac8-784cd6ed9825@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
 <mSt6hLV9yD3Ep5dUUM2mMo6Ic6ipp18qWxb6YlZfr30=.f4e79130-54f3-49ae-9ac8-784cd6ed9825@github.com>
Message-ID: <bDPPaiBwxA2WgnGGsUaq-LuzJ-R2QrJEPL8UplOc--w=.f5fbb510-5541-4254-8290-9e26bc0f5a73@github.com>

On Wed, 9 Apr 2025 00:27:17 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 78:
>> 
>>> 76:   _live_data(0),
>>> 77:   _critical_pins(0),
>>> 78:   _mixed_candidate_garbage_words(0),
>> 
>> Do we need a new field to track this? During `final_mark`, we call `increase_live_data_alloc_words` to add `TAMS + top` to `_live_data` to account for objects allocated during mark. Could we "fix" `get_live_data` so that it always returned marked objects (counted by `increase_live_data_gc_words`) _plus_ `top - TAMS`. This way, the live data would not become stale after `final_mark` and we wouldn't have another field to manage. What do you think?
>
> This is a good idea.  Let me experiment with this.

My experiment with an initial attempt at this failed with over 60 failures.  The "problem" is that we often consult get_live_data() in contexts from which it is "not appropriate" to add (top- TAMS) to the atomic volatile ShenandoahHeapRegion::_live_data() .  I think most of these are asserts.  I have so far confirmed that there are at least two different places that need to be fixed.  Not sure how many total scenarios.

I'm willing to move forward with changes to the failing asserts to make this change work.  I think the code would be cleaner with your suggested refactor.  It just makes this PR a little more far-reaching than the original.

See the most recent commit on this PR to see the direction this would move us.  Let me know if you think I should move forward with more refactoring, or revert this most recent change.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2035784267

From wkemper at openjdk.org  Wed Apr  9 17:45:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Apr 2025 17:45:13 GMT
Subject: Integrated: 8342444: Shenandoah: Uncommit regions from a separate,
 STS aware thread
In-Reply-To: <gHDJhIDyewnf0wEcVh35e02a_gUQjEOXd6x7U0EtVEA=.4ba5313b-7c2d-4d31-9817-8b90d2f21845@github.com>
References: <gHDJhIDyewnf0wEcVh35e02a_gUQjEOXd6x7U0EtVEA=.4ba5313b-7c2d-4d31-9817-8b90d2f21845@github.com>
Message-ID: <5DeMGFDxU3HqKlj0Qu3OCtbN1lcFqB8pAV0rogF4cl0=.06fb217a-17a7-463a-8af0-61e8d58dba02@github.com>

On Tue, 8 Apr 2025 21:35:47 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, has follow up bug fix

This pull request has now been integrated.

Changeset: 8c357046
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/8c35704670a265decc4aa6bdf900e9a84057dd25
Stats:     515 lines in 9 files changed: 398 ins; 89 del; 28 mod

8342444: Shenandoah: Uncommit regions from a separate, STS aware thread
8350605: assert(!heap->is_uncommit_in_progress()) failed: Cannot uncommit bitmaps while resetting them

Reviewed-by: ysr, kdnilsen
Backport-of: bedb68aba126c6400ce9f2182105b5294ff42021

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

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

From wkemper at openjdk.org  Wed Apr  9 17:53:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Apr 2025 17:53:31 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v2]
In-Reply-To: <bDPPaiBwxA2WgnGGsUaq-LuzJ-R2QrJEPL8UplOc--w=.f5fbb510-5541-4254-8290-9e26bc0f5a73@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
 <mSt6hLV9yD3Ep5dUUM2mMo6Ic6ipp18qWxb6YlZfr30=.f4e79130-54f3-49ae-9ac8-784cd6ed9825@github.com>
 <bDPPaiBwxA2WgnGGsUaq-LuzJ-R2QrJEPL8UplOc--w=.f5fbb510-5541-4254-8290-9e26bc0f5a73@github.com>
Message-ID: <bN-SlL1XCuG1Wvz8pazSE20N6TkM03QRPM2culnjauY=.753c8016-4c10-4554-bd84-0f2d3cbac670@github.com>

On Wed, 9 Apr 2025 17:02:40 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This is a good idea.  Let me experiment with this.
>
> My experiment with an initial attempt at this failed with over 60 failures.  The "problem" is that we often consult get_live_data() in contexts from which it is "not appropriate" to add (top- TAMS) to the atomic volatile ShenandoahHeapRegion::_live_data() .  I think most of these are asserts.  I have so far confirmed that there are at least two different places that need to be fixed.  Not sure how many total scenarios.
> 
> I'm willing to move forward with changes to the failing asserts to make this change work.  I think the code would be cleaner with your suggested refactor.  It just makes this PR a little more far-reaching than the original.
> 
> See the most recent commit on this PR to see the direction this would move us.  Let me know if you think I should move forward with more refactoring, or revert this most recent change.
> 
> Thanks.

It does look simpler. Do you have an example of one of the failing asserts? 

One thing I hadn't considered is how "hot" `ShenandoahHeapRegion::get_live_data_words` is. Is there going to be a significant performance hit if we make this method do more work? It does look like this method is called frequently.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2035852703

From kdnilsen at openjdk.org  Wed Apr  9 18:03:47 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 9 Apr 2025 18:03:47 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v2]
In-Reply-To: <bN-SlL1XCuG1Wvz8pazSE20N6TkM03QRPM2culnjauY=.753c8016-4c10-4554-bd84-0f2d3cbac670@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
 <mSt6hLV9yD3Ep5dUUM2mMo6Ic6ipp18qWxb6YlZfr30=.f4e79130-54f3-49ae-9ac8-784cd6ed9825@github.com>
 <bDPPaiBwxA2WgnGGsUaq-LuzJ-R2QrJEPL8UplOc--w=.f5fbb510-5541-4254-8290-9e26bc0f5a73@github.com>
 <bN-SlL1XCuG1Wvz8pazSE20N6TkM03QRPM2culnjauY=.753c8016-4c10-4554-bd84-0f2d3cbac670@github.com>
Message-ID: <pVyMRahOQ3bMqUDlAxwRe5g9Z8My24aa0rd9pUY0O9c=.e1f34a16-ecb1-45e6-8725-55be8aedadca@github.com>

On Wed, 9 Apr 2025 17:51:06 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> My experiment with an initial attempt at this failed with over 60 failures.  The "problem" is that we often consult get_live_data() in contexts from which it is "not appropriate" to add (top- TAMS) to the atomic volatile ShenandoahHeapRegion::_live_data() .  I think most of these are asserts.  I have so far confirmed that there are at least two different places that need to be fixed.  Not sure how many total scenarios.
>> 
>> I'm willing to move forward with changes to the failing asserts to make this change work.  I think the code would be cleaner with your suggested refactor.  It just makes this PR a little more far-reaching than the original.
>> 
>> See the most recent commit on this PR to see the direction this would move us.  Let me know if you think I should move forward with more refactoring, or revert this most recent change.
>> 
>> Thanks.
>
> It does look simpler. Do you have an example of one of the failing asserts? 
> 
> One thing I hadn't considered is how "hot" `ShenandoahHeapRegion::get_live_data_words` is. Is there going to be a significant performance hit if we make this method do more work? It does look like this method is called frequently.

Examples:
  FullGC worker:
   void ShenandoahMCResestCompleteBitmapTask::work(uint worker_id) {
    ShenandoahParallelWorkerSession worker_session(worker_id);
    ShenandoahHeapRegion* region = _regions.next();
    ShenandoahHeap* heap = ShenandoahHeap::heap();
    ShenandoahMarkingContext* const ctx = heap->complete_marking_context();
    while (region != nullptr) {
      if (heap->is_bitmap_slice_committed(region) && !region->is_pinned() && region->has_marked()) {
        //  kelvin replacing has_live() with new method has_marked() because has_live() calls get_live_data_words()
        //  and pointer_delta() asserts out because TAMS is not less than top().  has_marked() does what has_live()
        //  used to do...
        ctx->clear_bitmap(region);
      }
      region = _regions.next();
    }
  }

ShenandoahInitMarkUpdateRegionStateClosure::heap_region_do() {
-    assert(!r->has_live(), "Region %zu should have no live data", r->index());
+    assert(!r->has_marked(), "Region %zu should have no marked data", r->index());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2035869108

From kdnilsen at openjdk.org  Wed Apr  9 18:18:27 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 9 Apr 2025 18:18:27 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v2]
In-Reply-To: <pVyMRahOQ3bMqUDlAxwRe5g9Z8My24aa0rd9pUY0O9c=.e1f34a16-ecb1-45e6-8725-55be8aedadca@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
 <mSt6hLV9yD3Ep5dUUM2mMo6Ic6ipp18qWxb6YlZfr30=.f4e79130-54f3-49ae-9ac8-784cd6ed9825@github.com>
 <bDPPaiBwxA2WgnGGsUaq-LuzJ-R2QrJEPL8UplOc--w=.f5fbb510-5541-4254-8290-9e26bc0f5a73@github.com>
 <bN-SlL1XCuG1Wvz8pazSE20N6TkM03QRPM2culnjauY=.753c8016-4c10-4554-bd84-0f2d3cbac670@github.com>
 <pVyMRahOQ3bMqUDlAxwRe5g9Z8My24aa0rd9pUY0O9c=.e1f34a16-ecb1-45e6-8725-55be8aedadca@github.com>
Message-ID: <FUycnkJKlZt9tpL9vUhDhQA-tHhDWFaRd8-j4P3Aoug=.42f1f1d9-aa0c-4dfe-848d-8d83f7693002@github.com>

On Wed, 9 Apr 2025 18:01:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> It does look simpler. Do you have an example of one of the failing asserts? 
>> 
>> One thing I hadn't considered is how "hot" `ShenandoahHeapRegion::get_live_data_words` is. Is there going to be a significant performance hit if we make this method do more work? It does look like this method is called frequently.
>
> Examples:
>   FullGC worker:
>    void ShenandoahMCResestCompleteBitmapTask::work(uint worker_id) {
>     ShenandoahParallelWorkerSession worker_session(worker_id);
>     ShenandoahHeapRegion* region = _regions.next();
>     ShenandoahHeap* heap = ShenandoahHeap::heap();
>     ShenandoahMarkingContext* const ctx = heap->complete_marking_context();
>     while (region != nullptr) {
>       if (heap->is_bitmap_slice_committed(region) && !region->is_pinned() && region->has_marked()) {
>         //  kelvin replacing has_live() with new method has_marked() because has_live() calls get_live_data_words()
>         //  and pointer_delta() asserts out because TAMS is not less than top().  has_marked() does what has_live()
>         //  used to do...
>         ctx->clear_bitmap(region);
>       }
>       region = _regions.next();
>     }
>   }
> 
> ShenandoahInitMarkUpdateRegionStateClosure::heap_region_do() {
> -    assert(!r->has_live(), "Region %zu should have no live data", r->index());
> +    assert(!r->has_marked(), "Region %zu should have no marked data", r->index());

Not sure about performance impact, other than implementing and testing...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2035888970

From kdnilsen at openjdk.org  Wed Apr  9 18:24:36 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 9 Apr 2025 18:24:36 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v2]
In-Reply-To: <FUycnkJKlZt9tpL9vUhDhQA-tHhDWFaRd8-j4P3Aoug=.42f1f1d9-aa0c-4dfe-848d-8d83f7693002@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
 <mSt6hLV9yD3Ep5dUUM2mMo6Ic6ipp18qWxb6YlZfr30=.f4e79130-54f3-49ae-9ac8-784cd6ed9825@github.com>
 <bDPPaiBwxA2WgnGGsUaq-LuzJ-R2QrJEPL8UplOc--w=.f5fbb510-5541-4254-8290-9e26bc0f5a73@github.com>
 <bN-SlL1XCuG1Wvz8pazSE20N6TkM03QRPM2culnjauY=.753c8016-4c10-4554-bd84-0f2d3cbac670@github.com>
 <pVyMRahOQ3bMqUDlAxwRe5g9Z8My24aa0rd9pUY0O9c=.e1f34a16-ecb1-45e6-8725-55be8aedadca@github.com>
 <FUycnkJKlZt9tpL9vUhDhQA-tHhDWFaRd8-j4P3Aoug=.42f1f1d9-aa0c-4dfe-848d-8d83f7693002@github.com>
Message-ID: <xzNt9J87ZmqYN1NP67CtNeAigj7h-PwDPKL3BOLAArU=.2ccb444f-b643-4cde-b451-f0cc2a827316@github.com>

On Wed, 9 Apr 2025 18:15:38 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Examples:
>>   FullGC worker:
>>    void ShenandoahMCResestCompleteBitmapTask::work(uint worker_id) {
>>     ShenandoahParallelWorkerSession worker_session(worker_id);
>>     ShenandoahHeapRegion* region = _regions.next();
>>     ShenandoahHeap* heap = ShenandoahHeap::heap();
>>     ShenandoahMarkingContext* const ctx = heap->complete_marking_context();
>>     while (region != nullptr) {
>>       if (heap->is_bitmap_slice_committed(region) && !region->is_pinned() && region->has_marked()) {
>>         //  kelvin replacing has_live() with new method has_marked() because has_live() calls get_live_data_words()
>>         //  and pointer_delta() asserts out because TAMS is not less than top().  has_marked() does what has_live()
>>         //  used to do...
>>         ctx->clear_bitmap(region);
>>       }
>>       region = _regions.next();
>>     }
>>   }
>> 
>> ShenandoahInitMarkUpdateRegionStateClosure::heap_region_do() {
>> -    assert(!r->has_live(), "Region %zu should have no live data", r->index());
>> +    assert(!r->has_marked(), "Region %zu should have no marked data", r->index());
>
> Not sure about performance impact, other than implementing and testing...

i suspect performance impact is minimal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2035896982

From wkemper at openjdk.org  Wed Apr  9 18:47:45 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Apr 2025 18:47:45 GMT
Subject: RFR: 8351157: Clean up x86 GC barriers after 32-bit x86 removal
 [v3]
In-Reply-To: <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
References: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
 <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
Message-ID: <HoVmBguu_1z6j5Zo6WrEjpnu6Weo4GDIU0g5dXXfjmo=.8e402291-c266-47df-a6bc-8b3adbc2fe9a@github.com>

On Wed, 9 Apr 2025 08:31:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Assembler GC barriers have quite a bit of coding to support 32-bit x86. As 32-bit x86 is removed, we can clean up those parts.
>> 
>> We can eliminate `!LP64` blocks quite easily. We can also prune passing around `thread` argument, and just trust that `r15_thread` is always available.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Also do tlab_allocate
>  - Rely on R15 to be a thread register
>  - Work

This is a nice simplification.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24253#pullrequestreview-2754423734

From gziemski at openjdk.org  Wed Apr  9 20:35:32 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 9 Apr 2025 20:35:32 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v9]
In-Reply-To: <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>
Message-ID: <8KEGhJ5sXoeeT2ezqvyG-uYWlXUzBGSHD_RLwjAH8LI=.89670a1f-2e4a-4c88-8329-3261d462cae0@github.com>

On Mon, 7 Apr 2025 13:30:44 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small last feedback from Stefan

Thank you Stefan for providing the values of mem_tags and your feedback. Do you want to be a co-author on this PR?

@jdksjolen @afshin-zafari ping

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2790934209
PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2790935906

From wkemper at openjdk.org  Wed Apr  9 20:49:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 9 Apr 2025 20:49:11 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup
Message-ID: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>

Not clean

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

Commit messages:
 - 8345423: Shenandoah: Parallelize concurrent cleanup

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/172/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=172&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8345423
  Stats: 233 lines in 13 files changed: 87 ins; 56 del; 90 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/172.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/172/head:pull/172

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

From kdnilsen at openjdk.org  Wed Apr  9 22:32:46 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 9 Apr 2025 22:32:46 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v3]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <JvtBqPXRi4pm6OldcdYn-hDlE_9U15U8K042CMCrxjM=.67d4482d-abf0-46b9-8c4f-c718ad3f5fdd@github.com>

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

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

  Experiment 2: refinements to reduce regressions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24319/files
  - new: https://git.openjdk.org/jdk/pull/24319/files/3c1f788a..8ff388d1

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

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

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

From kdnilsen at openjdk.org  Thu Apr 10 04:36:38 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 10 Apr 2025 04:36:38 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v4]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <X3RG4NbnwJ4068Orz9W1boAlo9Ap6_jifzOHo2FFPfw=.b3370d5e-07e7-4a53-8371-55134840f327@github.com>

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

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

  Fix garbage_before_padded_for_promote()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24319/files
  - new: https://git.openjdk.org/jdk/pull/24319/files/8ff388d1..8e820f29

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

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

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

From shade at openjdk.org  Thu Apr 10 07:13:31 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Apr 2025 07:13:31 GMT
Subject: RFR: 8351157: Clean up x86 GC barriers after 32-bit x86 removal
 [v3]
In-Reply-To: <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
References: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
 <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
Message-ID: <g4xqSU5Obs9kajmvskEFbqnxE9qXhuvnNZuivXNGYnU=.7b125bb6-9f8d-4c03-a033-48c3a2579299@github.com>

On Wed, 9 Apr 2025 08:31:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Assembler GC barriers have quite a bit of coding to support 32-bit x86. As 32-bit x86 is removed, we can clean up those parts.
>> 
>> We can eliminate `!LP64` blocks quite easily. We can also prune passing around `thread` argument, and just trust that `r15_thread` is always available.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Also do tlab_allocate
>  - Rely on R15 to be a thread register
>  - Work

@tschatzl -- are you fine with G1 cleanups?

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

PR Comment: https://git.openjdk.org/jdk/pull/24253#issuecomment-2791775549

From tschatzl at openjdk.org  Thu Apr 10 07:21:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 10 Apr 2025 07:21:29 GMT
Subject: RFR: 8351157: Clean up x86 GC barriers after 32-bit x86 removal
 [v3]
In-Reply-To: <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
References: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
 <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
Message-ID: <VkXN3lF6amDUpx1CtrL6HjLRiqSoexyjjKrDcwyDbg8=.c6b5e57b-539c-48d1-89f9-79a145fba27e@github.com>

On Wed, 9 Apr 2025 08:31:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Assembler GC barriers have quite a bit of coding to support 32-bit x86. As 32-bit x86 is removed, we can clean up those parts.
>> 
>> We can eliminate `!LP64` blocks quite easily. We can also prune passing around `thread` argument, and just trust that `r15_thread` is always available.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Also do tlab_allocate
>  - Rely on R15 to be a thread register
>  - Work

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24253#pullrequestreview-2755601117

From shade at openjdk.org  Thu Apr 10 07:56:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Apr 2025 07:56:45 GMT
Subject: RFR: 8351157: Clean up x86 GC barriers after 32-bit x86 removal
 [v3]
In-Reply-To: <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
References: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
 <tFa4dEFZGSIj85Y6O81-0AESNd61jsop41dG_SwKKo8=.619f7219-5f1a-4dbe-af65-506bc79cc3a7@github.com>
Message-ID: <UOvrIdDEiMF94Fs9FT_kwZ3jIUDsfIKB6tmwm7kyg8A=.9348efea-22bc-43a5-96c9-4cc82f97ccdc@github.com>

On Wed, 9 Apr 2025 08:31:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Assembler GC barriers have quite a bit of coding to support 32-bit x86. As 32-bit x86 is removed, we can clean up those parts.
>> 
>> We can eliminate `!LP64` blocks quite easily. We can also prune passing around `thread` argument, and just trust that `r15_thread` is always available.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `tier1`
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Merge branch 'master' into JDK-8351157-x86-gc-barriers
>  - Also do tlab_allocate
>  - Rely on R15 to be a thread register
>  - Work

Thanks! I merged with current mainline locally, and there are no surprises. So I am integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/24253#issuecomment-2791873674

From shade at openjdk.org  Thu Apr 10 07:56:45 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Apr 2025 07:56:45 GMT
Subject: Integrated: 8351157: Clean up x86 GC barriers after 32-bit x86 removal
In-Reply-To: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
References: <W5jdL_FffdNXZUKf8zZgl7_Nuc0ndPeBHEUe9ljNBo8=.77b5100b-5121-434d-8b3f-3d8c4c4cdcf0@github.com>
Message-ID: <7cljRYtWnAH4Yn3zAUM2uHyPV3xteo3vEvZJhNHzKsk=.2533276f-0e18-4176-bc90-3ceaefa0dcdb@github.com>

On Wed, 26 Mar 2025 12:48:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Assembler GC barriers have quite a bit of coding to support 32-bit x86. As 32-bit x86 is removed, we can clean up those parts.
> 
> We can eliminate `!LP64` blocks quite easily. We can also prune passing around `thread` argument, and just trust that `r15_thread` is always available.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `tier1`
>  - [x] Linux x86_64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: 73c8c755
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73c8c755ea638c09147d28080646ee8887ee8283
Stats:     543 lines in 20 files changed: 1 ins; 426 del; 116 mod

8351157: Clean up x86 GC barriers after 32-bit x86 removal

Reviewed-by: kbarrett, wkemper, tschatzl

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

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

From shade at openjdk.org  Thu Apr 10 08:26:51 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 10 Apr 2025 08:26:51 GMT
Subject: RFR: 8351152: x86: Remove code blocks that handle UseSSE < 2 [v3]
In-Reply-To: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>
References: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>
Message-ID: <j29HW2244synpzlHKNeVfHTrSJDKbz1Yg4OHldybVlA=.8a5cf5ff-3ce9-4fed-b5bf-d828539d8d63@github.com>

> 32-bit x86 was the platform that supported `UseSSE < 2`. 64-bit x86 baselines on `UseSSE >= 2`: https://github.com/openjdk/jdk/blob/567c6885a377e5641deef9cd3498f79c5346cd6a/src/hotspot/cpu/x86/vm_version_x86.cpp#L895-L902
> 
> After 32-bit x86 code is gone, we can remove all code blocks that are there to support `UseSSE < 2`.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8351152-x86-sse2-everywhere
 - Also purge vestigial calls to VMVersion::supports_sse{2}
 - Also 24-bit removals
 - Touchups
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/24484/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24484&range=02
  Stats: 822 lines in 17 files changed: 34 ins; 542 del; 246 mod
  Patch: https://git.openjdk.org/jdk/pull/24484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24484/head:pull/24484

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

From stefank at openjdk.org  Thu Apr 10 09:03:34 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 10 Apr 2025 09:03:34 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v9]
In-Reply-To: <8KEGhJ5sXoeeT2ezqvyG-uYWlXUzBGSHD_RLwjAH8LI=.89670a1f-2e4a-4c88-8329-3261d462cae0@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>
 <8KEGhJ5sXoeeT2ezqvyG-uYWlXUzBGSHD_RLwjAH8LI=.89670a1f-2e4a-4c88-8329-3261d462cae0@github.com>
Message-ID: <uhegn3kJ5pXZy11DvfTZjvYXzemdjgZYQXAhYLi8WtE=.de674ebb-b034-4e88-83b1-02e1a264148f@github.com>

On Wed, 9 Apr 2025 20:32:15 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Thank you Stefan for providing the values of mem_tags and your feedback. Do you want to be a co-author on this PR?

Sure, why not.

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2792059171

From jsjolen at openjdk.org  Thu Apr 10 11:01:53 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Thu, 10 Apr 2025 11:01:53 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v9]
In-Reply-To: <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>
Message-ID: <Byv4eRvzPzUKxZD_r2hLdniQM9B9eGGsPlvUII6pho0=.3464a1b2-3789-4921-9d43-bfb90a676aef@github.com>

On Mon, 7 Apr 2025 13:30:44 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small last feedback from Stefan

Hi,

This looks good to me, thank you for doing this!

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24282#pullrequestreview-2756264572

From gziemski at openjdk.org  Thu Apr 10 14:17:32 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 10 Apr 2025 14:17:32 GMT
Subject: RFR: 8344883: Force clients to explicitly pass mem_tag value,
 even if it is mtNone [v9]
In-Reply-To: <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
 <WFQVOM491lQD89XYGiJWXknR5hu7TpMOTjEa-E76uzA=.88c99ec5-2f44-4b6f-b8bc-77568793edd1@github.com>
Message-ID: <xc2_Dh5q-cpNR723iSdF6Qm8e__-uO282Wl_7eJ_i_M=.35e76566-31cf-4353-aa67-eb7174f79902@github.com>

On Mon, 7 Apr 2025 13:30:44 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   small last feedback from Stefan

Thank you Johan!

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

PR Comment: https://git.openjdk.org/jdk/pull/24282#issuecomment-2793581212

From kdnilsen at openjdk.org  Thu Apr 10 16:28:21 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 10 Apr 2025 16:28:21 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v5]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <5jhoXMiuinw50NFwWr_kQdOudqZTx-3rfX8-4eCr4OY=.565602e3-8dc6-47eb-aa36-ddc5b9f27a08@github.com>

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:

 - Refactor for better abstraction
 - Fix set_live() after full gc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24319/files
  - new: https://git.openjdk.org/jdk/pull/24319/files/8e820f29..eb2679aa

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

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

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

From stefank at openjdk.org  Thu Apr 10 16:32:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 10 Apr 2025 16:32:21 GMT
Subject: RFR: 8354309: Sort GC includes
Message-ID: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>

We now have a tool to fix our include lines to better adhere to the HotSpot Style Guide. See test/hotspot/jtreg/sources/SortIncludes.java. I've run the tool against the GC code and propose the resulting changes. I did one manual change to move a section guarded with INCLUDE_JFR.

Builds successfully with GHA. I will run this through tier1-2.

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

Commit messages:
 - 8354309: Sort GC includes

Changes: https://git.openjdk.org/jdk/pull/24581/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24581&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354309
  Stats: 552 lines in 197 files changed: 268 ins; 270 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/24581.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24581/head:pull/24581

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

From eosterlund at openjdk.org  Thu Apr 10 17:20:27 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 10 Apr 2025 17:20:27 GMT
Subject: RFR: 8354309: Sort GC includes
In-Reply-To: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
References: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
Message-ID: <s75mZgljJC-ntoql26TN9O1BleNrOGOzzhkOxsu-9qc=.8118a9ac-29a4-4363-85a9-757fa3b20e0e@github.com>

On Thu, 10 Apr 2025 16:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We now have a tool to fix our include lines to better adhere to the HotSpot Style Guide. See test/hotspot/jtreg/sources/SortIncludes.java. I've run the tool against the GC code and propose the resulting changes. I did one manual change to move a section guarded with INCLUDE_JFR.
> 
> Builds successfully with GHA. I will run this through tier1-2.

Nice. Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24581#pullrequestreview-2757657683

From xpeng at openjdk.org  Thu Apr 10 19:01:06 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 10 Apr 2025 19:01:06 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup
In-Reply-To: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
References: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
Message-ID: <q-klwlSpcqs7S4Xjuy5fzZ855syi68U1uv-by8H_esc=.fb46ba5e-ac33-463d-abf6-03952dbc290a@github.com>

On Wed, 9 Apr 2025 20:17:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean

Looks good to me, thank you!

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

Marked as reviewed by xpeng (no project role).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/172#pullrequestreview-2758024604

From kdnilsen at openjdk.org  Thu Apr 10 21:55:45 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 10 Apr 2025 21:55:45 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v6]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <OM6xCOx4TciPnt2fS36f-t-sK2D7UJ1S8VVNbhSjPlY=.58391ab8-8b75-4468-a6f0-00a34fa73f93@github.com>

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:

 - Remove deprecation conditional compiles
 - Adjust candidate live memory for each mixed evac

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24319/files
  - new: https://git.openjdk.org/jdk/pull/24319/files/eb2679aa..ef783d48

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

  Stats: 85 lines in 6 files changed: 24 ins; 61 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/24319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24319/head:pull/24319

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

From kdnilsen at openjdk.org  Thu Apr 10 22:01:48 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 10 Apr 2025 22:01:48 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup
In-Reply-To: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
References: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
Message-ID: <c3QxOYxTyJZIBRi_Yhmb0-Btj_tGT97QsK3pL4fxG9s=.88f8e558-743d-469d-8763-f98a49fd1b5b@github.com>

On Wed, 9 Apr 2025 20:17:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/172#pullrequestreview-2758514801

From ysr at openjdk.org  Thu Apr 10 22:07:56 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 10 Apr 2025 22:07:56 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup
In-Reply-To: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
References: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
Message-ID: <EaV-Pzqy69g1T0JI4aYIOZu5VKH85BSkkrFsBGKS3oA=.b2be3553-3ed2-432e-bb3b-415d0bcc1bf0@github.com>

On Wed, 9 Apr 2025 20:17:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean

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

> 1271: 
> 1272: void ShenandoahFreeSet::recycle_trash() {
> 1273:   // lock is not non-reentrant, check we don't have it

Double negative.

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

PR Review Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/172#discussion_r2038407750

From ysr at openjdk.org  Thu Apr 10 22:07:56 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 10 Apr 2025 22:07:56 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup
In-Reply-To: <EaV-Pzqy69g1T0JI4aYIOZu5VKH85BSkkrFsBGKS3oA=.b2be3553-3ed2-432e-bb3b-415d0bcc1bf0@github.com>
References: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
 <EaV-Pzqy69g1T0JI4aYIOZu5VKH85BSkkrFsBGKS3oA=.b2be3553-3ed2-432e-bb3b-415d0bcc1bf0@github.com>
Message-ID: <KSTzPAd8L86hZRdQApWnwbeuArSTfEdaASXNNn7nz9g=.b91f1711-8a95-41fb-a226-d72fc6614321@github.com>

On Thu, 10 Apr 2025 22:05:06 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Not clean
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1273:
> 
>> 1271: 
>> 1272: void ShenandoahFreeSet::recycle_trash() {
>> 1273:   // lock is not non-reentrant, check we don't have it
> 
> Double negative.

I am guessing you wanted "not reentrant".

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

PR Review Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/172#discussion_r2038409020

From ysr at openjdk.org  Thu Apr 10 22:12:48 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 10 Apr 2025 22:12:48 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup
In-Reply-To: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
References: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
Message-ID: <6iVWPaeyy8N6iAVCwLXUpFBs-xL1P1npKzyQHZx6lnQ=.26e851df-752c-4dd8-aa98-e233e5dce150@github.com>

On Wed, 9 Apr 2025 20:17:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean

minor nit in comment. Ok not to fix if the issue also in upstream (likely), so as to avoid conflicts.

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

Marked as reviewed by ysr (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/172#pullrequestreview-2758547547

From ysr at openjdk.org  Thu Apr 10 22:36:25 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 10 Apr 2025 22:36:25 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v6]
In-Reply-To: <OM6xCOx4TciPnt2fS36f-t-sK2D7UJ1S8VVNbhSjPlY=.58391ab8-8b75-4468-a6f0-00a34fa73f93@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <OM6xCOx4TciPnt2fS36f-t-sK2D7UJ1S8VVNbhSjPlY=.58391ab8-8b75-4468-a6f0-00a34fa73f93@github.com>
Message-ID: <cOvG1uF8BHeYK0eSX4VZ5fqVeFpaerf-KgwaHlrQXDY=.ab417ae1-7b7f-4dd3-8ee7-e270a6b847c6@github.com>

On Thu, 10 Apr 2025 21:55:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
>> 
>> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
>> 
>> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.
>
> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove deprecation conditional compiles
>  - Adjust candidate live memory for each mixed evac

Haven't started looking at these changes, but I do wonder if it might be worthwhile to also consider (and implement under a tunable flag) the alternative policy of never adding to the collection set any regions that are still "active" at the point when the collection set for a marking cycle is first assembled at the end of the final marking. That way we don't have to do any re-computing, and the criterion for evacuation is garbage-first (or liveness-least) both of which remain invariant (and complements of each other) throughout the duration of evacuation and obviating entirely the need for recomputing the goodness/choice metric afresh.

The downside is that we may leave some garbage on the table in the active regions, but this is probably a minor price for most workloads and heap configurations, and doesn't unnecessarily complicate or overengineer the solution.

One question to consider is how G1 does this. May be regions placed in the collection set are retired (i.e. made inactive?) -- I prefer not to forcibly retire active regions as this wastes space that may have been usable.

Thoughts? (Can add this comment and discuss on the ticket if that is logistically preferable.)

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

PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-2795315167

From vlivanov at openjdk.org  Thu Apr 10 23:12:31 2025
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 10 Apr 2025 23:12:31 GMT
Subject: RFR: 8351152: x86: Remove code blocks that handle UseSSE < 2 [v3]
In-Reply-To: <j29HW2244synpzlHKNeVfHTrSJDKbz1Yg4OHldybVlA=.8a5cf5ff-3ce9-4fed-b5bf-d828539d8d63@github.com>
References: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>
 <j29HW2244synpzlHKNeVfHTrSJDKbz1Yg4OHldybVlA=.8a5cf5ff-3ce9-4fed-b5bf-d828539d8d63@github.com>
Message-ID: <KPUvqd3kA6qfswywINnx8oh1KhJVCrieGadRakbtx7U=.24c4c5e9-229b-4fd0-8916-e15750dd11e6@github.com>

On Thu, 10 Apr 2025 08:26:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 32-bit x86 was the platform that supported `UseSSE < 2`. 64-bit x86 baselines on `UseSSE >= 2`: https://github.com/openjdk/jdk/blob/567c6885a377e5641deef9cd3498f79c5346cd6a/src/hotspot/cpu/x86/vm_version_x86.cpp#L895-L902
>> 
>> After 32-bit x86 code is gone, we can remove all code blocks that are there to support `UseSSE < 2`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8351152-x86-sse2-everywhere
>  - Also purge vestigial calls to VMVersion::supports_sse{2}
>  - Also 24-bit removals
>  - Touchups
>  - Fix

Looks good.

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24484#pullrequestreview-2758733519

From iwalulya at openjdk.org  Fri Apr 11 04:45:31 2025
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 11 Apr 2025 04:45:31 GMT
Subject: RFR: 8354309: Sort GC includes
In-Reply-To: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
References: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
Message-ID: <QlSYrekxQC7k3OaiY322qwpHmrSZK7UaVsIlVg7jibE=.449a75b7-ae1b-49a1-8bdf-67f633228dfe@github.com>

On Thu, 10 Apr 2025 16:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We now have a tool to fix our include lines to better adhere to the HotSpot Style Guide. See test/hotspot/jtreg/sources/SortIncludes.java. I've run the tool against the GC code and propose the resulting changes. I did one manual change to move a section guarded with INCLUDE_JFR.
> 
> Builds successfully with GHA. I will run this through tier1-2.

LGTM!

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

Marked as reviewed by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24581#pullrequestreview-2759127458

From shade at openjdk.org  Fri Apr 11 07:13:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Apr 2025 07:13:38 GMT
Subject: RFR: 8351152: x86: Remove code blocks that handle UseSSE < 2 [v3]
In-Reply-To: <j29HW2244synpzlHKNeVfHTrSJDKbz1Yg4OHldybVlA=.8a5cf5ff-3ce9-4fed-b5bf-d828539d8d63@github.com>
References: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>
 <j29HW2244synpzlHKNeVfHTrSJDKbz1Yg4OHldybVlA=.8a5cf5ff-3ce9-4fed-b5bf-d828539d8d63@github.com>
Message-ID: <Kc33GunKmNNtMnqGy3wR6J3218UEiSJEWxHKrbXpzQM=.7810387d-2bf3-41aa-b29c-e19e595444ca@github.com>

On Thu, 10 Apr 2025 08:26:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 32-bit x86 was the platform that supported `UseSSE < 2`. 64-bit x86 baselines on `UseSSE >= 2`: https://github.com/openjdk/jdk/blob/567c6885a377e5641deef9cd3498f79c5346cd6a/src/hotspot/cpu/x86/vm_version_x86.cpp#L895-L902
>> 
>> After 32-bit x86 code is gone, we can remove all code blocks that are there to support `UseSSE < 2`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 server fastdebug, `all`
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8351152-x86-sse2-everywhere
>  - Also purge vestigial calls to VMVersion::supports_sse{2}
>  - Also 24-bit removals
>  - Touchups
>  - Fix

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/24484#issuecomment-2796044492

From shade at openjdk.org  Fri Apr 11 07:13:39 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 11 Apr 2025 07:13:39 GMT
Subject: Integrated: 8351152: x86: Remove code blocks that handle UseSSE < 2
In-Reply-To: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>
References: <Gc1SwGlnNxyqSpX8mhD0b-fqa8_8U6Tb-5TOgpA0vww=.ae6e23f4-89cf-4c76-9e1e-e861f2675763@github.com>
Message-ID: <01JFFMYO0BFI7M-u_OBkpexqhYYDKgCPFtT1aOoXzU8=.aba893de-0725-4487-a2e7-901a26014cfa@github.com>

On Mon, 7 Apr 2025 09:55:16 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> 32-bit x86 was the platform that supported `UseSSE < 2`. 64-bit x86 baselines on `UseSSE >= 2`: https://github.com/openjdk/jdk/blob/567c6885a377e5641deef9cd3498f79c5346cd6a/src/hotspot/cpu/x86/vm_version_x86.cpp#L895-L902
> 
> After 32-bit x86 code is gone, we can remove all code blocks that are there to support `UseSSE < 2`.
> 
> Additional testing:
>  - [x] Linux x86_64 server fastdebug, `all`

This pull request has now been integrated.

Changeset: cf0308b2
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf0308b2716053eb7c547cfcc6b160589cd6a2b0
Stats:     822 lines in 17 files changed: 34 ins; 542 del; 246 mod

8351152: x86: Remove code blocks that handle UseSSE < 2

Reviewed-by: vlivanov, kvn

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

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

From kbarrett at openjdk.org  Fri Apr 11 11:04:39 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 11 Apr 2025 11:04:39 GMT
Subject: RFR: 8354309: Sort GC includes
In-Reply-To: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
References: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
Message-ID: <AyZ9y829ngQBD0VBdlZNhyhgfHlprhVZEWPUa8Iy7do=.82f9aabe-7882-4a7a-aadc-89dfaad59859@github.com>

On Thu, 10 Apr 2025 16:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We now have a tool to fix our include lines to better adhere to the HotSpot Style Guide. See test/hotspot/jtreg/sources/SortIncludes.java. I've run the tool against the GC code and propose the resulting changes. I did one manual change to move a section guarded with INCLUDE_JFR.
> 
> Builds successfully with GHA. I will run this through tier1-2.

Need to update the list of source directories to check in the test.
https://github.com/openjdk/jdk/blame/d4e194bc463ff3ad09e55cbb96bea00283679ce6/test/hotspot/jtreg/sources/TestIncludesAreSorted.java#L45-L50

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24581#pullrequestreview-2759966226

From jsikstro at openjdk.org  Fri Apr 11 11:38:08 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 11 Apr 2025 11:38:08 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
Message-ID: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>

Hello,

> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.

Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.

What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).

Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.

I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.

Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth making, considering that memory for buffers of strings usually outweigh this extra memory cost. Additionally, when factoring in the improved code understandability and maintainability, I feel like it's a change worth making.

Some new changes in the way the printing looks are:
* Epsilon has received indentation in its print_on, which was not there before, in an effort to look similar to other GCs and also improve readability.
* Shenandoah has also received indentation to behave similar to other GCs.
* "the space" in Serial's output was indented by two spaces, now it's one.
* With the removal of print_on from print_on_error, I've also removed Epsilon's barrier set printing, making it's print_on_error empty. Before this, Serial printed two spaces between the sections in the hs_err file.

Code re-structure:
* PSOldGen::print_on had an inlined version of virtual_space()->print_space_boundaries_on(st), which is now called instead.
* PSYoungGen::print_on had its name inlined. Now, name() is called instead, which is how PSOldGen::print_on does it.
* I've added a common print_space_boundaries_on for the virtual space used in Serial's DefNewGeneration and TenuredGeneration, like how Parallel does it.
* I've opted to use fill_to() in Metaspace printing so that it works well with ZGC printing. This does not really affect other GCs since only ZGC aligns with the same column as Metaspace.

Testing:
* GHA, Oracle's tier 1-3
* Manual inspection of printed content 
  * Exit printing `-Xlog:gc+heap+exit=info`
  * Periodic printing `-Xlog:gc+heap=debug`
  * jcmd `jcmd <pid> GC.heap_info`
  * jcmd `jcmd <pid> VM.info`
  * hs_err file, both "Heap:" and "Heap before/after invocations=" printing, `-XX:ErrorHandlerTest=14`

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

Commit messages:
 - 8354362: Use automatic indentation in CollectedHeap printing

Changes: https://git.openjdk.org/jdk/pull/24593/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354362
  Stats: 239 lines in 26 files changed: 88 ins; 88 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/24593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24593/head:pull/24593

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

From jsikstro at openjdk.org  Fri Apr 11 11:38:08 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Fri, 11 Apr 2025 11:38:08 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <nuJbjxTbM_p-HmR-ytI6zQyq_4efFKDFSDfyEdqAbos=.d2dc6b85-aefe-4529-a267-a73a443ea47b@github.com>

On Fri, 11 Apr 2025 11:28:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

Ping @tstuefe regarding changes for `StreamAutoIndentor`. Would be nice to get your opinion since you are the author of it and its uses :)

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

PR Comment: https://git.openjdk.org/jdk/pull/24593#issuecomment-2796653117

From stefank at openjdk.org  Fri Apr 11 11:54:29 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 11 Apr 2025 11:54:29 GMT
Subject: RFR: 8354309: Sort GC includes
In-Reply-To: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
References: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
Message-ID: <omyXeXJFhic3TIY4xpYbyvuQ4YEUOb9qzHDFevGKrMU=.e54f7b99-7b61-460d-9067-770be18a04e6@github.com>

On Thu, 10 Apr 2025 16:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We now have a tool to fix our include lines to better adhere to the HotSpot Style Guide. See test/hotspot/jtreg/sources/SortIncludes.java. I've run the tool against the GC code and propose the resulting changes. I did one manual change to move a section guarded with INCLUDE_JFR.
> 
> Builds successfully with GHA. I will run this through tier1-2.

I don't think my patch *needs* to add this to the test.

Adding the GC directories to the test will make a small mistake in the include order a tier1 failure, and I'm not yet convinced that that is a good thing compared to lazily fixing sort order problems.

Any other Reviewers that have a strong opinion about this?

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

PR Comment: https://git.openjdk.org/jdk/pull/24581#issuecomment-2796694323

From tschatzl at openjdk.org  Fri Apr 11 14:24:29 2025
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 11 Apr 2025 14:24:29 GMT
Subject: RFR: 8354309: Sort GC includes
In-Reply-To: <omyXeXJFhic3TIY4xpYbyvuQ4YEUOb9qzHDFevGKrMU=.e54f7b99-7b61-460d-9067-770be18a04e6@github.com>
References: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
 <omyXeXJFhic3TIY4xpYbyvuQ4YEUOb9qzHDFevGKrMU=.e54f7b99-7b61-460d-9067-770be18a04e6@github.com>
Message-ID: <BHmiYBkKjV2R6HnJQuP7WZGJeCj2VBIgt8QaiM0YmvM=.381a7e30-6044-490f-803a-496514eb6e6f@github.com>

On Fri, 11 Apr 2025 11:51:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Any other Reviewers that have a strong opinion about this?

Not a strong opinion, but I would prefer to check automatically in some way. Does not need every run of tier1.

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

PR Comment: https://git.openjdk.org/jdk/pull/24581#issuecomment-2797060978

From wkemper at openjdk.org  Fri Apr 11 17:44:49 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 17:44:49 GMT
Subject: RFR: 8345423: Shenandoah: Parallelize concurrent cleanup
In-Reply-To: <KSTzPAd8L86hZRdQApWnwbeuArSTfEdaASXNNn7nz9g=.b91f1711-8a95-41fb-a226-d72fc6614321@github.com>
References: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
 <EaV-Pzqy69g1T0JI4aYIOZu5VKH85BSkkrFsBGKS3oA=.b2be3553-3ed2-432e-bb3b-415d0bcc1bf0@github.com>
 <KSTzPAd8L86hZRdQApWnwbeuArSTfEdaASXNNn7nz9g=.b91f1711-8a95-41fb-a226-d72fc6614321@github.com>
Message-ID: <8doYEJWy-4Bva_andtAorLx30cVozv0TCV8uUrcVh2U=.409bdcc5-45a9-4a8b-b8b8-b25a909da574@github.com>

On Thu, 10 Apr 2025 22:05:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 1273:
>> 
>>> 1271: 
>>> 1272: void ShenandoahFreeSet::recycle_trash() {
>>> 1273:   // lock is not non-reentrant, check we don't have it
>> 
>> Double negative.
>
> I am guessing you wanted "not reentrant".

Yeah, it's in upstream too. Will fix it there first.

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

PR Review Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/172#discussion_r2040013963

From wkemper at openjdk.org  Fri Apr 11 17:44:49 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 17:44:49 GMT
Subject: Integrated: 8345423: Shenandoah: Parallelize concurrent cleanup
In-Reply-To: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
References: <QlNqFYdrg0ccL9t6ngGfuMj47W-qAvQiZ5jbr6A54oI=.5cb15435-9451-4cd5-8ba6-c349ff2848fd@github.com>
Message-ID: <31RS05VZXUVunjwwZrLJFTZ0KqCaTTgHx9k5B8AIyjI=.02418194-1dbe-4f9e-bc0c-e68e75796b1b@github.com>

On Wed, 9 Apr 2025 20:17:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean

This pull request has now been integrated.

Changeset: bf98e3fa
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/bf98e3fa1170a41a7894c1c9000f10adf6bc180a
Stats:     233 lines in 13 files changed: 87 ins; 56 del; 90 mod

8345423: Shenandoah: Parallelize concurrent cleanup

Reviewed-by: xpeng, kdnilsen, ysr
Backport-of: 4da6fd4283a13be1711e7ad948f1d05a0a9148a5

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

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

From wkemper at openjdk.org  Fri Apr 11 19:21:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 19:21:42 GMT
Subject: RFR: 8338737: Shenandoah: Reset marking bitmaps after the cycle
Message-ID: <r5sBU7ADXLQPmUfwbX8rBzeguWwmcE99tY3F0zOznaM=.2ef0c542-14e2-456b-859f-11efa9d8cc97@github.com>

Clean backport

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

Commit messages:
 - 8338737: Shenandoah: Reset marking bitmaps after the cycle

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/173/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=173&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338737
  Stats: 180 lines in 8 files changed: 95 ins; 62 del; 23 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/173.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/173/head:pull/173

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

From wkemper at openjdk.org  Fri Apr 11 20:19:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 20:19:47 GMT
Subject: Integrated: 8338737: Shenandoah: Reset marking bitmaps after the cycle
In-Reply-To: <r5sBU7ADXLQPmUfwbX8rBzeguWwmcE99tY3F0zOznaM=.2ef0c542-14e2-456b-859f-11efa9d8cc97@github.com>
References: <r5sBU7ADXLQPmUfwbX8rBzeguWwmcE99tY3F0zOznaM=.2ef0c542-14e2-456b-859f-11efa9d8cc97@github.com>
Message-ID: <kce7vkAG6qh0rd-7CmxICdRFOAs6uVx1dA0qlWG-XS4=.4be94aaa-64c9-494f-9e38-3609823d91d0@github.com>

On Fri, 11 Apr 2025 19:09:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport

This pull request has now been integrated.

Changeset: ade23ea0
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/ade23ea025333b71c74addc7150b5065074c15fa
Stats:     180 lines in 8 files changed: 95 ins; 62 del; 23 mod

8338737: Shenandoah: Reset marking bitmaps after the cycle

Backport-of: 7c187b5d81a653b87fc498101ad9e2d99b72efc6

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

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

From wkemper at openjdk.org  Fri Apr 11 20:46:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 20:46:01 GMT
Subject: RFR: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
Message-ID: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>

Without enforcing limits on `ShenandoahControlIntervalMin` and `ShenandoahControlIntervalMax`, the user may supply values that cause assertions to fail.

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

Commit messages:
 - Enforce limits on control thread's minimum and maximum sleep times

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

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

From wkemper at openjdk.org  Fri Apr 11 20:52:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 20:52:55 GMT
Subject: RFR: 8349094: GenShen: Race between control and regulator threads may
 violate assertions
Message-ID: <RODGKxD-VxYbxrdJEXKDtwsLeFGnDn2onQOvQz6damo=.34cdd159-b95a-42ed-a129-2c4ec40e963b@github.com>

Not clean. Several follow up issues here.

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

Commit messages:
 - 8352299: GenShen: Young cycles that interrupt old cycles cannot be cancelled
 - 8351464: Shenandoah: Hang on ShenandoahController::handle_alloc_failure when run test TestAllocHumongousFragment#generational
 - 8352091: GenShen: assert(!(request.generation->is_old() && _heap->old_generation()->is_doing_mixed_evacuations())) failed: Old heuristic should not request cycles while it waits for mixed evacuation
 - 8352428: GenShen: Old-gen cycles are still looping
 - Backport 3a8a432c05999fe478b94de75b416404b5a515d2

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/174/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=174&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8349094
  Stats: 980 lines in 19 files changed: 334 ins; 295 del; 351 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/174.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/174/head:pull/174

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

From ysr at openjdk.org  Fri Apr 11 20:59:30 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Apr 2025 20:59:30 GMT
Subject: RFR: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
In-Reply-To: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>
References: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>
Message-ID: <sqmoOAnSMTQ_NCZ22h0HHDxtyp2alFxN08mCOi4Jv7M=.1830eda0-68ad-4ab3-ab35-4d11be00ba57@github.com>

On Fri, 11 Apr 2025 20:41:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Without enforcing limits on `ShenandoahControlIntervalMin` and `ShenandoahControlIntervalMax`, the user may supply values that cause assertions to fail.
> 
> This assertion failure has been observed in Genshen's regulator thread:
> 
> #0 0x000028e8062d021a in ShenandoahRegulatorThread::regulator_sleep (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:125
> #1 0x000028e8062d0027 in ShenandoahRegulatorThread::regulate_young_and_old_cycles (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:95
> #2 0x000028e8062cfd06 in ShenandoahRegulatorThread::run_service (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:51
> 
> But it could just as easily happen in other modes to the `ShenandoahControlThread` instance.

Left a comment for consideration but changes look fine if this changes doesn't interfere with potential tuning space etc.

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 1:

> 1: /*

Change looks fine, but I wonder about using a `naked_sleep()` and allowing longer durations without triggering asserts in those cases? Not sure where this could be used and whether 1-second is the maximum we might like for these numbers regardless.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24602#pullrequestreview-2761556102
PR Review Comment: https://git.openjdk.org/jdk/pull/24602#discussion_r2040287010

From wkemper at openjdk.org  Fri Apr 11 21:06:30 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:06:30 GMT
Subject: RFR: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
In-Reply-To: <sqmoOAnSMTQ_NCZ22h0HHDxtyp2alFxN08mCOi4Jv7M=.1830eda0-68ad-4ab3-ab35-4d11be00ba57@github.com>
References: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>
 <sqmoOAnSMTQ_NCZ22h0HHDxtyp2alFxN08mCOi4Jv7M=.1830eda0-68ad-4ab3-ab35-4d11be00ba57@github.com>
Message-ID: <3BSSSNcGzbGojKBsi0fMQ9y4CXR3xnGWMlsMVixnbSo=.fcaca705-04f0-45c7-b0c7-ed1355265edb@github.com>

On Fri, 11 Apr 2025 20:55:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Without enforcing limits on `ShenandoahControlIntervalMin` and `ShenandoahControlIntervalMax`, the user may supply values that cause assertions to fail.
>> 
>> This assertion failure has been observed in Genshen's regulator thread:
>> 
>> #0 0x000028e8062d021a in ShenandoahRegulatorThread::regulator_sleep (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:125
>> #1 0x000028e8062d0027 in ShenandoahRegulatorThread::regulate_young_and_old_cycles (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:95
>> #2 0x000028e8062cfd06 in ShenandoahRegulatorThread::run_service (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:51
>> 
>> But it could just as easily happen in other modes to the `ShenandoahControlThread` instance.
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 1:
> 
>> 1: /*
> 
> Change looks fine, but I wonder about using a `naked_sleep()` and allowing longer durations without triggering asserts in those cases? Not sure where this could be used and whether 1-second is the maximum we might like for these numbers regardless.

1 second is enforced by `naked_sleep` itself, so raising it would impact all callers. Not using `naked_sleep` would be possible here, but the default maximum sleep time is 10ms. Even 1 second (well, 999ms) would make the heuristics dangerously slow to respond.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24602#discussion_r2040294574

From ysr at openjdk.org  Fri Apr 11 21:12:25 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Apr 2025 21:12:25 GMT
Subject: RFR: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
In-Reply-To: <3BSSSNcGzbGojKBsi0fMQ9y4CXR3xnGWMlsMVixnbSo=.fcaca705-04f0-45c7-b0c7-ed1355265edb@github.com>
References: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>
 <sqmoOAnSMTQ_NCZ22h0HHDxtyp2alFxN08mCOi4Jv7M=.1830eda0-68ad-4ab3-ab35-4d11be00ba57@github.com>
 <3BSSSNcGzbGojKBsi0fMQ9y4CXR3xnGWMlsMVixnbSo=.fcaca705-04f0-45c7-b0c7-ed1355265edb@github.com>
Message-ID: <I6YAsNU5r3NfSXqdhGMiGtuvlpeQBsRVf3f0SMG7Zvw=.306e90e5-cbcc-4ed6-beaf-822e2efa473f@github.com>

On Fri, 11 Apr 2025 21:03:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 1:
>> 
>>> 1: /*
>> 
>> Change looks fine, but I wonder about using a `naked_sleep()` and allowing longer durations without triggering asserts in those cases? Not sure where this could be used and whether 1-second is the maximum we might like for these numbers regardless.
>
> 1 second is enforced by `naked_sleep` itself, so raising it would impact all callers. Not using `naked_sleep` would be possible here, but the default maximum sleep time is 10ms. Even 1 second (well, 999ms) would make the heuristics dangerously slow to respond.

Hmm, curious, I see this:

// Convenience wrapper around naked_short_sleep to allow for longer sleep
// times. Only for use by non-JavaThreads.
void os::naked_sleep(jlong millis) {
  assert(!Thread::current()->is_Java_thread(), "not for use by JavaThreads");
  const jlong limit = 999;
  while (millis > limit) {
    naked_short_sleep(limit);
    millis -= limit;
  }
  naked_short_sleep(millis);
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24602#discussion_r2040297668

From ysr at openjdk.org  Fri Apr 11 21:12:25 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 11 Apr 2025 21:12:25 GMT
Subject: RFR: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
In-Reply-To: <I6YAsNU5r3NfSXqdhGMiGtuvlpeQBsRVf3f0SMG7Zvw=.306e90e5-cbcc-4ed6-beaf-822e2efa473f@github.com>
References: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>
 <sqmoOAnSMTQ_NCZ22h0HHDxtyp2alFxN08mCOi4Jv7M=.1830eda0-68ad-4ab3-ab35-4d11be00ba57@github.com>
 <3BSSSNcGzbGojKBsi0fMQ9y4CXR3xnGWMlsMVixnbSo=.fcaca705-04f0-45c7-b0c7-ed1355265edb@github.com>
 <I6YAsNU5r3NfSXqdhGMiGtuvlpeQBsRVf3f0SMG7Zvw=.306e90e5-cbcc-4ed6-beaf-822e2efa473f@github.com>
Message-ID: <pWnGJS0xbz-np1gDFP1p1agUC9Bf9W2DLxl1UzFxIys=.6c00acb2-920a-4115-9a07-52dd9473dd3f@github.com>

On Fri, 11 Apr 2025 21:08:04 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> 1 second is enforced by `naked_sleep` itself, so raising it would impact all callers. Not using `naked_sleep` would be possible here, but the default maximum sleep time is 10ms. Even 1 second (well, 999ms) would make the heuristics dangerously slow to respond.
>
> Hmm, curious, I see this:
> 
> // Convenience wrapper around naked_short_sleep to allow for longer sleep
> // times. Only for use by non-JavaThreads.
> void os::naked_sleep(jlong millis) {
>   assert(!Thread::current()->is_Java_thread(), "not for use by JavaThreads");
>   const jlong limit = 999;
>   while (millis > limit) {
>     naked_short_sleep(limit);
>     millis -= limit;
>   }
>   naked_short_sleep(millis);
> }

Still if ppl aren't gonna need longer than 1 sec, and longer is a bad idea, then limiting it is a good idea.
Reviewed. ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24602#discussion_r2040298962

From wkemper at openjdk.org  Fri Apr 11 21:12:26 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:12:26 GMT
Subject: RFR: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
In-Reply-To: <pWnGJS0xbz-np1gDFP1p1agUC9Bf9W2DLxl1UzFxIys=.6c00acb2-920a-4115-9a07-52dd9473dd3f@github.com>
References: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>
 <sqmoOAnSMTQ_NCZ22h0HHDxtyp2alFxN08mCOi4Jv7M=.1830eda0-68ad-4ab3-ab35-4d11be00ba57@github.com>
 <3BSSSNcGzbGojKBsi0fMQ9y4CXR3xnGWMlsMVixnbSo=.fcaca705-04f0-45c7-b0c7-ed1355265edb@github.com>
 <I6YAsNU5r3NfSXqdhGMiGtuvlpeQBsRVf3f0SMG7Zvw=.306e90e5-cbcc-4ed6-beaf-822e2efa473f@github.com>
 <pWnGJS0xbz-np1gDFP1p1agUC9Bf9W2DLxl1UzFxIys=.6c00acb2-920a-4115-9a07-52dd9473dd3f@github.com>
Message-ID: <Vjc_6wOgYZfBwAvPyXutxQ-E293STfM3MjporAcdEAs=.33e443fe-3050-4a85-bed7-4246fef0ecc3@github.com>

On Fri, 11 Apr 2025 21:09:36 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Hmm, curious, I see this:
>> 
>> // Convenience wrapper around naked_short_sleep to allow for longer sleep
>> // times. Only for use by non-JavaThreads.
>> void os::naked_sleep(jlong millis) {
>>   assert(!Thread::current()->is_Java_thread(), "not for use by JavaThreads");
>>   const jlong limit = 999;
>>   while (millis > limit) {
>>     naked_short_sleep(limit);
>>     millis -= limit;
>>   }
>>   naked_short_sleep(millis);
>> }
>
> Still if ppl aren't gonna need longer than 1 sec, and longer is a bad idea, then limiting it is a good idea.
> Reviewed. ?

Aye - we _could_ use that, but I don't think we _should_. Having the heuristics sleep longer than this between evaluations wouldn't do anyone any good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24602#discussion_r2040299379

From wkemper at openjdk.org  Fri Apr 11 21:16:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:16:22 GMT
Subject: Integrated: 8351077: Shenandoah: Update comments in
 ShenandoahConcurrentGC::op_reset_after_collect
Message-ID: <8hq2MVXbiCK1KglpAaeq9sdYD_u34dD80eqjQKKqiKY=.b7189b1a-6b92-4843-b03a-5da499fbc610@github.com>

Clean, trivial comment only change.

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

Commit messages:
 - Backport 7c173fde4274a798f299876492a2cd833eee9fdd

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

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

From wkemper at openjdk.org  Fri Apr 11 21:16:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:16:22 GMT
Subject: Integrated: 8351077: Shenandoah: Update comments in
 ShenandoahConcurrentGC::op_reset_after_collect
In-Reply-To: <8hq2MVXbiCK1KglpAaeq9sdYD_u34dD80eqjQKKqiKY=.b7189b1a-6b92-4843-b03a-5da499fbc610@github.com>
References: <8hq2MVXbiCK1KglpAaeq9sdYD_u34dD80eqjQKKqiKY=.b7189b1a-6b92-4843-b03a-5da499fbc610@github.com>
Message-ID: <FIToQvd_mqnww-9g_AKCLBrBZvnkovotStNpKBT958I=.0f177ea4-fe2b-4749-a92a-dc8769461a5e@github.com>

On Fri, 11 Apr 2025 21:06:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean, trivial comment only change.

This pull request has now been integrated.

Changeset: 4a65a90a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/4a65a90aa07e1126a77afa8b50f989113e1a65d5
Stats:     5 lines in 1 file changed: 0 ins; 2 del; 3 mod

8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect

Backport-of: 7c173fde4274a798f299876492a2cd833eee9fdd

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

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

From wkemper at openjdk.org  Fri Apr 11 21:17:17 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:17:17 GMT
Subject: Integrated: 8351081: Off-by-one error in ShenandoahCardCluster
Message-ID: <NPStMEBZBxU1nuoi_uIcOfKa_Z7Qrf5yRYcuz4XzGQ4=.a914da54-19b4-4ff3-b9ef-85fa61e23beb@github.com>

Clean backport, simple change.

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

Commit messages:
 - Backport 38b4d46c1ff3701d75ff8347e5edbb01acd9b512

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

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

From wkemper at openjdk.org  Fri Apr 11 21:17:17 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:17:17 GMT
Subject: Integrated: 8351081: Off-by-one error in ShenandoahCardCluster
In-Reply-To: <NPStMEBZBxU1nuoi_uIcOfKa_Z7Qrf5yRYcuz4XzGQ4=.a914da54-19b4-4ff3-b9ef-85fa61e23beb@github.com>
References: <NPStMEBZBxU1nuoi_uIcOfKa_Z7Qrf5yRYcuz4XzGQ4=.a914da54-19b4-4ff3-b9ef-85fa61e23beb@github.com>
Message-ID: <cKrPneiXuBA4yowmxNwOhPemXZGXOsNd_P6fmVDmUC4=.af8a6289-1507-4a8f-b702-7d396c6b9d25@github.com>

On Fri, 11 Apr 2025 21:11:13 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport, simple change.

This pull request has now been integrated.

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

8351081: Off-by-one error in ShenandoahCardCluster

Backport-of: 38b4d46c1ff3701d75ff8347e5edbb01acd9b512

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

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

From wkemper at openjdk.org  Fri Apr 11 21:27:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:27:23 GMT
Subject: RFR: 8351444: Shenandoah: Class Unloading may encounter recycled oops
Message-ID: <oichoCqoKBmU_0CBDtGYh1Cwwt6z_UIaGTmJhk_xCIU=.a6fa2ce7-c7f0-4e03-a7aa-bf39ccef3743@github.com>

Not clean, but not hard to resolve.

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

Commit messages:
 - Backport cdf7632f8a85611077a27c91ad928ed8ea116f95

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

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

From wkemper at openjdk.org  Fri Apr 11 21:28:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:28:22 GMT
Subject: Integrated: 8350905: Shenandoah: Releasing a WeakHandle's referent may
 extend its lifetime
Message-ID: <40VrhWhKr0HmC65FWMMmOZVv_kugLzBwU_cVPrka2zo=.78277736-bfdd-4fdf-bb3f-69484dde75a8@github.com>

Clean backport.

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

Commit messages:
 - Backport a347ecdedc098bd23598ba6acf28d77db01be066

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

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

From wkemper at openjdk.org  Fri Apr 11 21:28:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:28:22 GMT
Subject: Integrated: 8350905: Shenandoah: Releasing a WeakHandle's referent may
 extend its lifetime
In-Reply-To: <40VrhWhKr0HmC65FWMMmOZVv_kugLzBwU_cVPrka2zo=.78277736-bfdd-4fdf-bb3f-69484dde75a8@github.com>
References: <40VrhWhKr0HmC65FWMMmOZVv_kugLzBwU_cVPrka2zo=.78277736-bfdd-4fdf-bb3f-69484dde75a8@github.com>
Message-ID: <DSY692Tw8YETChVIf8hjGoV5D1SQ7rkWx_F9N7nw0e4=.9eeab0be-1061-4ede-8a70-e5e4a39685b3@github.com>

On Fri, 11 Apr 2025 21:22:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: ae5737a4
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/ae5737a42fe7d197fc94355bd8ff1d90809ff8dd
Stats:     10 lines in 1 file changed: 10 ins; 0 del; 0 mod

8350905: Shenandoah: Releasing a WeakHandle's referent may extend its lifetime

Backport-of: a347ecdedc098bd23598ba6acf28d77db01be066

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

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

From kdnilsen at openjdk.org  Fri Apr 11 21:28:12 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 11 Apr 2025 21:28:12 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v7]
In-Reply-To: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
Message-ID: <JYKa8jPnquAfLY8uf8_uAns_jKItTJQURBfYuakNy7s=.c205c76e-1338-4482-bcbc-700c0ec4517e@github.com>

> The existing implementation of get_live_data_bytes() and git_live_data_words() does not always behave as might be expected.  In particular, the value returned ignores any allocations that occur subsequent to the most recent mark effort that identified live data within the region.  This is typically ok for young regions that are going to be added or not to the collection set during final-mark safepoint.
> 
> However, old-gen regions that are placed into the set of candidates for mixed evacuation are more complicated.  In particular, by the time the old-gen region is added to a mixed evacuation, its live data may be much larger than at the time concurrent old marking ended.
> 
> This PR provides comments to clarify the shortcomings of the existing functions, and adds new functions that provide more accurate accountings of live data for mixed-evacuation candidate regions.

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

  Fix uninitialized variable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24319/files
  - new: https://git.openjdk.org/jdk/pull/24319/files/ef783d48..e6e44b67

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

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

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

From wkemper at openjdk.org  Fri Apr 11 21:28:31 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:28:31 GMT
Subject: RFR: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
In-Reply-To: <sqmoOAnSMTQ_NCZ22h0HHDxtyp2alFxN08mCOi4Jv7M=.1830eda0-68ad-4ab3-ab35-4d11be00ba57@github.com>
References: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>
 <sqmoOAnSMTQ_NCZ22h0HHDxtyp2alFxN08mCOi4Jv7M=.1830eda0-68ad-4ab3-ab35-4d11be00ba57@github.com>
Message-ID: <paTVypLtwBBcUMy41PDQrtostms2A4iCYW3wlEpmBfQ=.e0f90c50-87a2-4761-93c7-35a7e025f74d@github.com>

On Fri, 11 Apr 2025 20:56:26 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Without enforcing limits on `ShenandoahControlIntervalMin` and `ShenandoahControlIntervalMax`, the user may supply values that cause assertions to fail.
>> 
>> This assertion failure has been observed in Genshen's regulator thread:
>> 
>> #0 0x000028e8062d021a in ShenandoahRegulatorThread::regulator_sleep (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:125
>> #1 0x000028e8062d0027 in ShenandoahRegulatorThread::regulate_young_and_old_cycles (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:95
>> #2 0x000028e8062cfd06 in ShenandoahRegulatorThread::run_service (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:51
>> 
>> But it could just as easily happen in other modes to the `ShenandoahControlThread` instance.
>
> Left a comment for consideration but changes look fine if this changes doesn't interfere with potential tuning space etc.

Appreciate the careful review @ysramakrishna !

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

PR Comment: https://git.openjdk.org/jdk/pull/24602#issuecomment-2798035149

From wkemper at openjdk.org  Fri Apr 11 21:28:32 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:28:32 GMT
Subject: Integrated: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
In-Reply-To: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>
References: <MSXi05YQYBlOpSqnm83oPbDJcYGuZJ8EJ8UdH9fWRCM=.c9fd4c44-91e9-40ab-a0b0-3cd2428df977@github.com>
Message-ID: <uf_sFQoLWzN1s-eaPJH9BdWa17Cgyw-Fq61yJEPZhao=.ee8518e4-a77d-4fd0-8eba-b788237d2ba7@github.com>

On Fri, 11 Apr 2025 20:41:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Without enforcing limits on `ShenandoahControlIntervalMin` and `ShenandoahControlIntervalMax`, the user may supply values that cause assertions to fail.
> 
> This assertion failure has been observed in Genshen's regulator thread:
> 
> #0 0x000028e8062d021a in ShenandoahRegulatorThread::regulator_sleep (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:125
> #1 0x000028e8062d0027 in ShenandoahRegulatorThread::regulate_young_and_old_cycles (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:95
> #2 0x000028e8062cfd06 in ShenandoahRegulatorThread::run_service (this=0x4ef9701893b0) at src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp:51
> 
> But it could just as easily happen in other modes to the `ShenandoahControlThread` instance.

This pull request has now been integrated.

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

8354452: Shenandoah: Enforce range checks on parameters controlling heuristic sleep times

Reviewed-by: ysr

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

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

From kdnilsen at openjdk.org  Fri Apr 11 21:30:28 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 11 Apr 2025 21:30:28 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v6]
In-Reply-To: <cOvG1uF8BHeYK0eSX4VZ5fqVeFpaerf-KgwaHlrQXDY=.ab417ae1-7b7f-4dd3-8ee7-e270a6b847c6@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <OM6xCOx4TciPnt2fS36f-t-sK2D7UJ1S8VVNbhSjPlY=.58391ab8-8b75-4468-a6f0-00a34fa73f93@github.com>
 <cOvG1uF8BHeYK0eSX4VZ5fqVeFpaerf-KgwaHlrQXDY=.ab417ae1-7b7f-4dd3-8ee7-e270a6b847c6@github.com>
Message-ID: <YMsmHcemskfi1eM0bpNDwb0x1AGWy-41HvaddO4nkL0=.e24b8b96-8ad5-4a3d-9e53-7f8556178109@github.com>

On Thu, 10 Apr 2025 22:33:28 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove deprecation conditional compiles
>>  - Adjust candidate live memory for each mixed evac
>
> Haven't started looking at these changes, but I do wonder if it might be worthwhile to also consider (and implement under a tunable flag) the alternative policy of never adding to the collection set any regions that are still "active" at the point when the collection set for a marking cycle is first assembled at the end of the final marking. That way we don't have to do any re-computing, and the criterion for evacuation is garbage-first (or liveness-least) both of which remain invariant (and complements of each other) throughout the duration of evacuation and obviating entirely the need for recomputing the goodness/choice metric afresh.
> 
> The downside is that we may leave some garbage on the table in the active regions, but this is probably a minor price for most workloads and heap configurations, and doesn't unnecessarily complicate or overengineer the solution.
> 
> One question to consider is how G1 does this. May be regions placed in the collection set are retired (i.e. made inactive?) -- I prefer not to forcibly retire active regions as this wastes space that may have been usable.
> 
> Thoughts? (Can add this comment and discuss on the ticket if that is logistically preferable.)

@ysramakrishna : Interesting idea.  Definitely worthy of an experiment.  On the upside, this can make GC more "efficient" by procrastinating until the GC effort maximizes the returns of allocatable memory.  On the downside, this can allow garbage to hide out for arbitrarily long times in regions that are not "fully used".  I'd be in favor of proposing these experiments and possible feature enhancements in the context of a separate JBS ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/24319#issuecomment-2798040688

From wkemper at openjdk.org  Fri Apr 11 21:36:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 11 Apr 2025 21:36:00 GMT
Subject: RFR: 8351444: Shenandoah: Class Unloading may encounter recycled
 oops [v2]
In-Reply-To: <oichoCqoKBmU_0CBDtGYh1Cwwt6z_UIaGTmJhk_xCIU=.a6fa2ce7-c7f0-4e03-a7aa-bf39ccef3743@github.com>
References: <oichoCqoKBmU_0CBDtGYh1Cwwt6z_UIaGTmJhk_xCIU=.a6fa2ce7-c7f0-4e03-a7aa-bf39ccef3743@github.com>
Message-ID: <3yAfl9TvS26Uy_uYDiQU3whr4Vrnng0oldMaCi3tkSE=.911af299-90f4-482d-b40f-b9858cc39cc5@github.com>

> Not clean, but not hard to resolve.

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

  Remove vestigial inline is_in implementation

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/177/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/177/files/ccd1ba06..ee804750

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

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

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

From kdnilsen at openjdk.org  Fri Apr 11 21:58:45 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 11 Apr 2025 21:58:45 GMT
Subject: RFR: 8351444: Shenandoah: Class Unloading may encounter recycled
 oops [v2]
In-Reply-To: <3yAfl9TvS26Uy_uYDiQU3whr4Vrnng0oldMaCi3tkSE=.911af299-90f4-482d-b40f-b9858cc39cc5@github.com>
References: <oichoCqoKBmU_0CBDtGYh1Cwwt6z_UIaGTmJhk_xCIU=.a6fa2ce7-c7f0-4e03-a7aa-bf39ccef3743@github.com>
 <3yAfl9TvS26Uy_uYDiQU3whr4Vrnng0oldMaCi3tkSE=.911af299-90f4-482d-b40f-b9858cc39cc5@github.com>
Message-ID: <1WDX9yN75CrJ2RTZp3YRtMlQO4PuXQ1eiMI7EUrpSw4=.61a34315-81a1-4b7a-98bc-f30e0d137ffc@github.com>

On Fri, 11 Apr 2025 21:36:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Not clean, but not hard to resolve.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove vestigial inline is_in implementation

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/177#pullrequestreview-2761657052

From kdnilsen at openjdk.org  Fri Apr 11 22:13:38 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 11 Apr 2025 22:13:38 GMT
Subject: RFR: 8349094: GenShen: Race between control and regulator threads
 may violate assertions
In-Reply-To: <RODGKxD-VxYbxrdJEXKDtwsLeFGnDn2onQOvQz6damo=.34cdd159-b95a-42ed-a129-2c4ec40e963b@github.com>
References: <RODGKxD-VxYbxrdJEXKDtwsLeFGnDn2onQOvQz6damo=.34cdd159-b95a-42ed-a129-2c4ec40e963b@github.com>
Message-ID: <puMUoRMaJiRO9-YO6bT_Ynp5d2H37z6cDRdlIqNRic4=.d6529c81-15c1-4f15-99d8-4859558c2d90@github.com>

On Fri, 11 Apr 2025 20:45:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean. Several follow up issues here.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/174#pullrequestreview-2761676953

From gziemski at openjdk.org  Mon Apr 14 16:24:57 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 14 Apr 2025 16:24:57 GMT
Subject: Integrated: 8344883: Force clients to explicitly pass mem_tag value, 
 even if it is mtNone
In-Reply-To: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
References: <saKMBidkDYoo7dJMPsCiof9ohBkGN4rZGQUOmrcsP-8=.cbfdae06-a2e2-448b-918b-a57191319990@github.com>
Message-ID: <gXN5y-pDPeQrZhRwZkaSRTc3rDgppqB6-bH_DdCxLCA=.5bcaaa34-8a09-4699-bdef-4c249331d594@github.com>

On Thu, 27 Mar 2025 16:21:01 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> This is a follow-up to #21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
> 
> Testing: passes Mach5 tier1-5

This pull request has now been integrated.

Changeset: 43b19474
Author:    Gerard Ziemski <gziemski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/43b194741cc307a73bd8dd2da877ab1b16250fc1
Stats:     144 lines in 47 files changed: 18 ins; 1 del; 125 mod

8344883: Force clients to explicitly pass mem_tag value, even if it is mtNone

Co-authored-by: Stefan Karlsson <stefank at openjdk.org>
Reviewed-by: stefank, jsjolen

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

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

From kdnilsen at openjdk.org  Mon Apr 14 16:40:47 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 14 Apr 2025 16:40:47 GMT
Subject: RFR: 8353115: GenShen: mixed evacuation candidate regions need
 accurate live_data [v7]
In-Reply-To: <xzNt9J87ZmqYN1NP67CtNeAigj7h-PwDPKL3BOLAArU=.2ccb444f-b643-4cde-b451-f0cc2a827316@github.com>
References: <qC9JSeBvUjpSLlOoO-67V0uPxzYYRRqFXbGHCnGVq90=.4c365a01-760b-47ad-8b5c-7866ffc716f9@github.com>
 <lOhn-SRiJoTPcPIu229DSdeBTS0cZRiEtPevGrQrdmI=.7f4b5199-738d-4ba8-a454-efb0aead14a2@github.com>
 <mSt6hLV9yD3Ep5dUUM2mMo6Ic6ipp18qWxb6YlZfr30=.f4e79130-54f3-49ae-9ac8-784cd6ed9825@github.com>
 <bDPPaiBwxA2WgnGGsUaq-LuzJ-R2QrJEPL8UplOc--w=.f5fbb510-5541-4254-8290-9e26bc0f5a73@github.com>
 <bN-SlL1XCuG1Wvz8pazSE20N6TkM03QRPM2culnjauY=.753c8016-4c10-4554-bd84-0f2d3cbac670@github.com>
 <pVyMRahOQ3bMqUDlAxwRe5g9Z8My24aa0rd9pUY0O9c=.e1f34a16-ecb1-45e6-8725-55be8aedadca@github.com>
 <FUycnkJKlZt9tpL9vUhDhQA-tHhDWFaRd8-j4P3Aoug=.42f1f1d9-aa0c-4dfe-848d-8d83f7693002@github.com>
 <xzNt9J87ZmqYN1NP67CtNeAigj7h-PwDPKL3BOLAArU=.2ccb444f-b643-4cde-b451-f0cc2a827316@github.com>
Message-ID: <HXNF6hxgCjc3g--Y3_b7vEo4NiD6HIMgzRiOAxFnD2U=.dcc78d5f-de84-4b35-b981-f1599cb1b4cb@github.com>

On Wed, 9 Apr 2025 18:21:43 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Not sure about performance impact, other than implementing and testing...
>
> i suspect performance impact is minimal.

I've committed changes that endeavor to implement the suggested refactor.  Performance impact does appear to be minimal.  This broader refactoring does change behavior slightly.  In particular:

1. We now have a better understanding of live-memory evacuated during mixed evacuations.  This allows the selection of old-candidates for mixed evacuations to be more conservative.  We'll have fewer old regions in order to honor the intended budget.
2. Potentially, this will result in more mixed evacuations, but each mixed evacuation should take less time.
3. There should be no impact on behavior of traditional Shenandoah.

On one recently completed test run, we observed the following impacts compared to tip:
Shenandoah
-------------------------------------------------------------------------------------------------------
+80.69% specjbb2015/trigger_failure p=0.00000
  Control:     58.250   (+/- 13.48  )        110
  Test:       105.250   (+/- 33.13  )         30


Genshen
-------------------------------------------------------------------------------------------------------
-19.46% jme/context_switch_count p=0.00176
  Control:    117.420   (+/- 28.01  )        108
  Test:        98.292   (+/- 32.76  )         30

Perhaps we need more data to decide whether this is "significant".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2042510606

From wkemper at openjdk.org  Mon Apr 14 17:20:15 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 14 Apr 2025 17:20:15 GMT
Subject: Integrated: 8349094: GenShen: Race between control and regulator
 threads may violate assertions
In-Reply-To: <RODGKxD-VxYbxrdJEXKDtwsLeFGnDn2onQOvQz6damo=.34cdd159-b95a-42ed-a129-2c4ec40e963b@github.com>
References: <RODGKxD-VxYbxrdJEXKDtwsLeFGnDn2onQOvQz6damo=.34cdd159-b95a-42ed-a129-2c4ec40e963b@github.com>
Message-ID: <OKpAVFxSpg82KjyAMV_N10FE-mwVzuy9Q0bc_Aa2JCE=.696a7eda-4bfa-409c-95f5-109641e3f9fc@github.com>

On Fri, 11 Apr 2025 20:45:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean. Several follow up issues here.

This pull request has now been integrated.

Changeset: 9a690ba3
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/9a690ba36601e6aea50f63b710c91d87735a8be3
Stats:     980 lines in 19 files changed: 334 ins; 295 del; 351 mod

8349094: GenShen: Race between control and regulator threads may violate assertions
8352428: GenShen: Old-gen cycles are still looping
8352091: GenShen: assert(!(request.generation->is_old() && _heap->old_generation()->is_doing_mixed_evacuations())) failed: Old heuristic should not request cycles while it waits for mixed evacuation
8351464: Shenandoah: Hang on ShenandoahController::handle_alloc_failure when run test TestAllocHumongousFragment#generational
8352299: GenShen: Young cycles that interrupt old cycles cannot be cancelled

Reviewed-by: kdnilsen
Backport-of: 3a8a432c05999fe478b94de75b416404b5a515d2

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

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

From wkemper at openjdk.org  Mon Apr 14 17:20:15 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 14 Apr 2025 17:20:15 GMT
Subject: RFR: 8349094: GenShen: Race between control and regulator threads
 may violate assertions
In-Reply-To: <RODGKxD-VxYbxrdJEXKDtwsLeFGnDn2onQOvQz6damo=.34cdd159-b95a-42ed-a129-2c4ec40e963b@github.com>
References: <RODGKxD-VxYbxrdJEXKDtwsLeFGnDn2onQOvQz6damo=.34cdd159-b95a-42ed-a129-2c4ec40e963b@github.com>
Message-ID: <pzhjGEjSGEif_hHofuy5cf85k6R8h-bFTZU3bq4yZ8o=.8e42a083-f538-4dae-b2b7-ea21673d1d3c@github.com>

On Fri, 11 Apr 2025 20:45:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean. Several follow up issues here.

Internal testing for this branch is green. MacOS build failure looks unrelated.

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

PR Comment: https://git.openjdk.org/shenandoah-jdk21u/pull/174#issuecomment-2802374328

From wkemper at openjdk.org  Mon Apr 14 17:30:06 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 14 Apr 2025 17:30:06 GMT
Subject: RFR: 8351444: Shenandoah: Class Unloading may encounter recycled
 oops [v3]
In-Reply-To: <oichoCqoKBmU_0CBDtGYh1Cwwt6z_UIaGTmJhk_xCIU=.a6fa2ce7-c7f0-4e03-a7aa-bf39ccef3743@github.com>
References: <oichoCqoKBmU_0CBDtGYh1Cwwt6z_UIaGTmJhk_xCIU=.a6fa2ce7-c7f0-4e03-a7aa-bf39ccef3743@github.com>
Message-ID: <QSjvc2Kl2ZAdANxUt-7hDqhlTcRS45NYlq9IPenS5go=.9b4799ca-d9e0-4120-a990-7cb3637ed573@github.com>

> Not clean, but not hard to resolve.

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

  Fix build

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/177/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/177/files/ee804750..511c9805

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

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

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

From cslucas at openjdk.org  Mon Apr 14 18:48:37 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Mon, 14 Apr 2025 18:48:37 GMT
Subject: RFR: 8354541: Remove Shenandoah post barrier expand loop opts
Message-ID: <NUhDOYoV9638wYxRMxjYQaAxVMGbkpdXPmWIGFnYhB0=.df930962-5416-4a34-a03a-800de76104e9@github.com>

Please review this patch to remove Shenandoah post-barrier expand loop optimizations. This optimization was added in the first iteration os Shenandoah barriers. Nowadays, we try to always insert LRB at the earliest place and the impact of these optimizations is minimal; they are also frequent source of bugs.

Tested on OSX Aarch64 & Linux amd64 with JTREG tier1-3.

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

Commit messages:
 - Remove Shenandoah post barrier expand loop opts.

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

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

From stefank at openjdk.org  Mon Apr 14 18:51:35 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 14 Apr 2025 18:51:35 GMT
Subject: Integrated: 8354535: [BACKOUT] Force clients to explicitly pass
 mem_tag value, even if it is mtNone
In-Reply-To: <NVJoUdgoxllOFhQY5g6OZ31sYcUVomiWrk9bQm-1VPQ=.ce43432a-c3a5-4d63-8061-b2cf4770b6bd@github.com>
References: <NVJoUdgoxllOFhQY5g6OZ31sYcUVomiWrk9bQm-1VPQ=.ce43432a-c3a5-4d63-8061-b2cf4770b6bd@github.com>
Message-ID: <likTE1os34nzcKX39NEto4GRVX6YaDuJ8DrJxnYMZMM=.c62039b1-280f-49ab-9c3b-6338a99b6abe@github.com>

On Mon, 14 Apr 2025 17:59:40 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> 8354535: [BACKOUT] Force clients to explicitly pass mem_tag value, even if it is mtNone

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24627#pullrequestreview-2765284200

From gziemski at openjdk.org  Mon Apr 14 18:51:34 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 14 Apr 2025 18:51:34 GMT
Subject: Integrated: 8354535: [BACKOUT] Force clients to explicitly pass
 mem_tag value, even if it is mtNone
Message-ID: <NVJoUdgoxllOFhQY5g6OZ31sYcUVomiWrk9bQm-1VPQ=.ce43432a-c3a5-4d63-8061-b2cf4770b6bd@github.com>

8354535: [BACKOUT] Force clients to explicitly pass mem_tag value, even if it is mtNone

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

Commit messages:
 - Revert "8344883: Force clients to explicitly pass mem_tag value, even if it is mtNone"

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

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

From gziemski at openjdk.org  Mon Apr 14 18:51:36 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 14 Apr 2025 18:51:36 GMT
Subject: Integrated: 8354535: [BACKOUT] Force clients to explicitly pass
 mem_tag value, even if it is mtNone
In-Reply-To: <NVJoUdgoxllOFhQY5g6OZ31sYcUVomiWrk9bQm-1VPQ=.ce43432a-c3a5-4d63-8061-b2cf4770b6bd@github.com>
References: <NVJoUdgoxllOFhQY5g6OZ31sYcUVomiWrk9bQm-1VPQ=.ce43432a-c3a5-4d63-8061-b2cf4770b6bd@github.com>
Message-ID: <BNgYXOCi4R6JSdczCnW48vRwMjkbrEHD9p9hjb16LEk=.fb92648c-373b-4b7e-8831-f6b13e7a3be5@github.com>

On Mon, 14 Apr 2025 17:59:40 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> 8354535: [BACKOUT] Force clients to explicitly pass mem_tag value, even if it is mtNone

This pull request has now been integrated.

Changeset: 0da480a9
Author:    Gerard Ziemski <gziemski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0da480a91d31ee8dc2532cfec76bbf5b1d6c4eeb
Stats:     144 lines in 47 files changed: 1 ins; 18 del; 125 mod

8354535: [BACKOUT] Force clients to explicitly pass mem_tag value, even if it is mtNone

Reviewed-by: stefank, jsjolen

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

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

From jsjolen at openjdk.org  Mon Apr 14 18:51:35 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Mon, 14 Apr 2025 18:51:35 GMT
Subject: Integrated: 8354535: [BACKOUT] Force clients to explicitly pass
 mem_tag value, even if it is mtNone
In-Reply-To: <NVJoUdgoxllOFhQY5g6OZ31sYcUVomiWrk9bQm-1VPQ=.ce43432a-c3a5-4d63-8061-b2cf4770b6bd@github.com>
References: <NVJoUdgoxllOFhQY5g6OZ31sYcUVomiWrk9bQm-1VPQ=.ce43432a-c3a5-4d63-8061-b2cf4770b6bd@github.com>
Message-ID: <sDrbbwZtgr8iVOnf7zjIgNqyFzcUuzfphNKMc5a0Mnc=.52ea5895-52aa-4582-b26e-52f9c1cdeae7@github.com>

On Mon, 14 Apr 2025 17:59:40 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> 8354535: [BACKOUT] Force clients to explicitly pass mem_tag value, even if it is mtNone

Marked as reviewed by jsjolen (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24627#pullrequestreview-2765299726

From gziemski at openjdk.org  Mon Apr 14 19:58:18 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 14 Apr 2025 19:58:18 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag value,
 even if it is mtNone
Message-ID: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>

Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.

I tried to fill in tag, when I was pretty certain that I had the right type.

At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.

Testing: passes Mach5 tier1-5

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

Commit messages:
 - fix build break
 - redo

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

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

From gziemski at openjdk.org  Mon Apr 14 19:58:18 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 14 Apr 2025 19:58:18 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone
In-Reply-To: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
Message-ID: <3HCB7-3ujkMzxvKGhWl9rOpeJ8Urdl7x7jUlYVkU7r8=.6b78e11b-8815-4885-a43d-0330dcc01c66@github.com>

On Mon, 14 Apr 2025 19:49:54 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
> 
> Testing: passes Mach5 tier1-5

The fix for the build break from the original fix was super simple, from:


          char* p = os::attempt_reserve_memory_at(mapped_base_address, prot_zone_size,
                                                  false, MemTag::mtClassShared);


to


          char* p = os::attempt_reserve_memory_at(mapped_base_address, prot_zone_size,
                                                  mtClassShared, false);

@jdksjolen @stefank @afshin-zafari re-do.

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

PR Comment: https://git.openjdk.org/jdk/pull/24634#issuecomment-2802839371
PR Comment: https://git.openjdk.org/jdk/pull/24634#issuecomment-2802841516

From wkemper at openjdk.org  Mon Apr 14 20:38:09 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 14 Apr 2025 20:38:09 GMT
Subject: Integrated: 8351444: Shenandoah: Class Unloading may encounter
 recycled oops
In-Reply-To: <oichoCqoKBmU_0CBDtGYh1Cwwt6z_UIaGTmJhk_xCIU=.a6fa2ce7-c7f0-4e03-a7aa-bf39ccef3743@github.com>
References: <oichoCqoKBmU_0CBDtGYh1Cwwt6z_UIaGTmJhk_xCIU=.a6fa2ce7-c7f0-4e03-a7aa-bf39ccef3743@github.com>
Message-ID: <jG8ptdCUZoz2NC7vXN-Xecf9LOrhHxUUL71lUEeHHCo=.404e8cd0-8c15-4c31-b218-ff0fec632a2e@github.com>

On Fri, 11 Apr 2025 21:21:22 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean, but not hard to resolve.

This pull request has now been integrated.

Changeset: 315f98ff
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/315f98ff7e9b251708de6b300d20bfa09d1d0973
Stats:     59 lines in 6 files changed: 38 ins; 13 del; 8 mod

8351444: Shenandoah: Class Unloading may encounter recycled oops

Reviewed-by: kdnilsen
Backport-of: cdf7632f8a85611077a27c91ad928ed8ea116f95

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

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

From stefank at openjdk.org  Mon Apr 14 20:38:40 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 14 Apr 2025 20:38:40 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone
In-Reply-To: <3HCB7-3ujkMzxvKGhWl9rOpeJ8Urdl7x7jUlYVkU7r8=.6b78e11b-8815-4885-a43d-0330dcc01c66@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <3HCB7-3ujkMzxvKGhWl9rOpeJ8Urdl7x7jUlYVkU7r8=.6b78e11b-8815-4885-a43d-0330dcc01c66@github.com>
Message-ID: <GQ1HgOiJvfbf5Id7kKKyBYHubL-51vML-tOrDnL2-6s=.807d859f-6f69-407f-91a1-d28a6fc92d5e@github.com>

On Mon, 14 Apr 2025 19:55:07 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>> 
>> Testing: passes Mach5 tier1-5
>
> @jdksjolen @stefank @afshin-zafari re-do.

@gerard-ziemski You have other failures as well. I don't see how this can be true:
> Testing: passes Mach5 tier1-5

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

PR Comment: https://git.openjdk.org/jdk/pull/24634#issuecomment-2802925269

From wkemper at openjdk.org  Tue Apr 15 00:21:01 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 15 Apr 2025 00:21:01 GMT
Subject: RFR: 8350898: Shenandoah: Eliminate final roots safepoint
Message-ID: <-L8jOYm9KnsXdTN8eILrxA_2Zp87GjoK5EAulnMvg30=.779e75b6-bcf5-497b-8c15-6f7684ac2278@github.com>

Not clean. Conflicts with oop closure refactoring (8342588).

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

Commit messages:
 - 8350898: Shenandoah: Eliminate final roots safepoint

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/179/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=179&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8350898
  Stats: 296 lines in 14 files changed: 199 ins; 47 del; 50 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/179.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/179/head:pull/179

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

From shade at openjdk.org  Tue Apr 15 13:47:43 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 15 Apr 2025 13:47:43 GMT
Subject: RFR: 8354541: Remove Shenandoah post barrier expand loop opts
In-Reply-To: <NUhDOYoV9638wYxRMxjYQaAxVMGbkpdXPmWIGFnYhB0=.df930962-5416-4a34-a03a-800de76104e9@github.com>
References: <NUhDOYoV9638wYxRMxjYQaAxVMGbkpdXPmWIGFnYhB0=.df930962-5416-4a34-a03a-800de76104e9@github.com>
Message-ID: <WzU_XTAKVRo9aRfHBuNpe2VbKovEpeJTqCvPsJRs5jY=.de987191-9653-4e07-9741-555ef7501a90@github.com>

On Mon, 14 Apr 2025 18:42:23 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please review this patch to remove Shenandoah post-barrier expand loop optimizations. This optimization was added in the first iteration os Shenandoah barriers. Nowadays, we try to always insert LRB at the earliest place and the impact of these optimizations is minimal; they are also frequent source of bugs.
> 
> Tested on OSX Aarch64 & Linux amd64 with JTREG tier1-3.

Looks OK in principle. This would likely not matter also when we switch to late barrier expansion for Shenandoah, following the examples of Z an G1. Have you seen any performance impact at all with this patch?

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24630#pullrequestreview-2768339030

From gziemski at openjdk.org  Tue Apr 15 14:22:49 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 15 Apr 2025 14:22:49 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone
In-Reply-To: <3HCB7-3ujkMzxvKGhWl9rOpeJ8Urdl7x7jUlYVkU7r8=.6b78e11b-8815-4885-a43d-0330dcc01c66@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <3HCB7-3ujkMzxvKGhWl9rOpeJ8Urdl7x7jUlYVkU7r8=.6b78e11b-8815-4885-a43d-0330dcc01c66@github.com>
Message-ID: <aH0QOG7eirVQVCqav3RqKVI4HWfb71H2tK9s-FWGuwk=.af547ebb-8c05-4936-a22e-a96ff8458f9a@github.com>

On Mon, 14 Apr 2025 19:55:07 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>> 
>> Testing: tier1 (tier1-5 in progress)
>
> @jdksjolen @stefank @afshin-zafari re-do.

> @gerard-ziemski You have other failures as well. I don't see how this can be true:
> 
> > Testing: passes Mach5 tier1-5

Hmm, let's see...

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

PR Comment: https://git.openjdk.org/jdk/pull/24634#issuecomment-2805371485

From gziemski at openjdk.org  Tue Apr 15 14:52:03 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 15 Apr 2025 14:52:03 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v2]
In-Reply-To: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
Message-ID: <X0F9HEm7JwUIlI3ZDz0zqWBXrmia5fPBIjztED2kJMw=.3febc6c9-bce3-4dfc-9392-152e85413489@github.com>

> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
> 
> Testing: tier1-5 in progress

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  fix build break

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24634/files
  - new: https://git.openjdk.org/jdk/pull/24634/files/aba60b75..471728dc

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

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

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

From stefank at openjdk.org  Tue Apr 15 15:01:53 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 15 Apr 2025 15:01:53 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v2]
In-Reply-To: <X0F9HEm7JwUIlI3ZDz0zqWBXrmia5fPBIjztED2kJMw=.3febc6c9-bce3-4dfc-9392-152e85413489@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <X0F9HEm7JwUIlI3ZDz0zqWBXrmia5fPBIjztED2kJMw=.3febc6c9-bce3-4dfc-9392-152e85413489@github.com>
Message-ID: <1CakSkpLtqRCeLHfHpRUiyScyyYnMaw2bRWQfb6WqMU=.ab87cf18-a8f7-4f2b-919e-ad16993d77ce@github.com>

On Tue, 15 Apr 2025 14:52:03 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>> 
>> Testing: tier1-5 in progress
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix build break

In the previous iteration of this patch we removed the unnecessary `false`/`!ExecMem` arguments, but that last two changes keep them. After fixing these, please make sure to test that this builds.

src/hotspot/share/cds/metaspaceShared.cpp line 1348:

> 1346:           assert(prot_zone_size >= os::vm_allocation_granularity(), "must be"); // not just page size!
> 1347:           char* p = os::attempt_reserve_memory_at(mapped_base_address, prot_zone_size,
> 1348:                                                   mtClassShared, false);

Suggestion:

                                                  mtClassShared);

test/hotspot/gtest/gc/z/test_zVirtualMemoryManager.cpp line 131:

> 129:     // Reserve the memory that is acting as a blocking reservation.
> 130:     {
> 131:       char* const result = os::attempt_reserve_memory_at((char*)untype(blocked), ZGranuleSize, mtTest, !ExecMem);

Suggestion:

      char* const result = os::attempt_reserve_memory_at((char*)untype(blocked), ZGranuleSize, mtTest);

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

Changes requested by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24634#pullrequestreview-2768728457
PR Review Comment: https://git.openjdk.org/jdk/pull/24634#discussion_r2044839241
PR Review Comment: https://git.openjdk.org/jdk/pull/24634#discussion_r2044818399

From gziemski at openjdk.org  Tue Apr 15 17:29:46 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 15 Apr 2025 17:29:46 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone
In-Reply-To: <GQ1HgOiJvfbf5Id7kKKyBYHubL-51vML-tOrDnL2-6s=.807d859f-6f69-407f-91a1-d28a6fc92d5e@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <3HCB7-3ujkMzxvKGhWl9rOpeJ8Urdl7x7jUlYVkU7r8=.6b78e11b-8815-4885-a43d-0330dcc01c66@github.com>
 <GQ1HgOiJvfbf5Id7kKKyBYHubL-51vML-tOrDnL2-6s=.807d859f-6f69-407f-91a1-d28a6fc92d5e@github.com>
Message-ID: <OCkzrmMvuyzGq2T2BrrsM5kjCZ0XGWF6bCK0fXM53fM=.7345ba17-a276-4f94-a918-bd26950d3687@github.com>

On Mon, 14 Apr 2025 20:35:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> @jdksjolen @stefank @afshin-zafari re-do.
>
> @gerard-ziemski You have other failures as well. I don't see how this can be true:
>> Testing: passes Mach5 tier1-5

@stefank Thank you for taking another look and offering more feedback!

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

PR Comment: https://git.openjdk.org/jdk/pull/24634#issuecomment-2806956896

From andrew at openjdk.org  Tue Apr 15 19:43:41 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 19:43:41 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 4 new changesets
Message-ID: <5c710702-fb70-4d54-b6d2-ea090954214b@openjdk.org>

Changeset: 680b09c7
Branch: master
Author:    Joshua Cao <joshcao at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2022-05-16 17:03:29 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/680b09c7568fd3ba476e63c0dbca0a6301bf3d95

8168926: C2: Bytecode escape analyzer crashes due to stack overflow

Reviewed-by: phh

! hotspot/src/share/vm/ci/bcEscapeAnalyzer.cpp
! hotspot/src/share/vm/ci/ciMethod.hpp

Changeset: 6b94b65d
Branch: master
Author:    ktakakuri <83941312+ktakakuri at users.noreply.github.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2022-05-19 09:50:54 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/6b94b65db942406c746319957e9c04b92f5507d9

8278138: OpenJDK8 fails to start on Windows 8.1 after upgrading compiler to VS2017

Reviewed-by: jnordstrom, erikj

! jdk/make/Images.gmk

Changeset: 3e0eb096
Branch: master
Author:    Takakuri <k.takakuri at fujitsu.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2022-05-19 15:23:44 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/3e0eb096153e9b7f4c2ed367c9282d09307bbd6b

8248876: LoadObject with bad base address created for exec file on linux

Reviewed-by: phh
Backport-of: 9d59dec200490f11bfc1c661b30f10c7edee3a6d

! hotspot/agent/src/os/linux/ps_core.c
! hotspot/agent/src/share/classes/sun/jvm/hotspot/debugger/linux/LinuxCDebugger.java

Changeset: 35e46413
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-15 19:16:12 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/35e46413e8e61906f55584774cadf0941e6faaad

Merge jdk8u342-b03

Added tag jdk8u342-b03 for changeset 3e0eb09615



From andrew at openjdk.org  Tue Apr 15 19:43:55 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 19:43:55 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u342-b03 for changeset
 3e0eb096
Message-ID: <a9c595ca-fc57-4499-a87d-4a3eb7f6d06a@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-24 02:23:58 +0000

Added tag jdk8u342-b03 for changeset 3e0eb09615
Changeset: 3e0eb096
Author:    Takakuri <k.takakuri at fujitsu.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2022-05-19 15:23:44 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/3e0eb096153e9b7f4c2ed367c9282d09307bbd6b


From andrew at openjdk.org  Tue Apr 15 19:43:57 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 19:43:57 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u342-b03 for
 changeset 35e46413
Message-ID: <2bb54d32-c299-4ca9-a032-2ac2af90592f@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-15 20:36:47 +0000

Added tag shenandoah8u342-b03 for changeset 35e46413e8e
Changeset: 35e46413
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-15 19:16:12 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/35e46413e8e61906f55584774cadf0941e6faaad


From gziemski at openjdk.org  Tue Apr 15 20:02:07 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 15 Apr 2025 20:02:07 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v3]
In-Reply-To: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
Message-ID: <I1d0YL-aLmDZaaaolaWh85I-e7DuSN3uks_YcML1KN0=.ca88c27e-c995-4611-91b4-516dc8fcb04d@github.com>

> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
> 
> Testing: tier1-5 in progress

Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:

  remove last default argument (found by Stefan)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24634/files
  - new: https://git.openjdk.org/jdk/pull/24634/files/471728dc..d5cea15d

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

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

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

From coleenp at openjdk.org  Tue Apr 15 20:17:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 15 Apr 2025 20:17:46 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v3]
In-Reply-To: <I1d0YL-aLmDZaaaolaWh85I-e7DuSN3uks_YcML1KN0=.ca88c27e-c995-4611-91b4-516dc8fcb04d@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <I1d0YL-aLmDZaaaolaWh85I-e7DuSN3uks_YcML1KN0=.ca88c27e-c995-4611-91b4-516dc8fcb04d@github.com>
Message-ID: <ki5fwGUOxKrHq6J9ONAgOkN2r_iHWyqTGC_62fiT44E=.ccb65ecb-0384-4c91-81dd-567a898fc100@github.com>

On Tue, 15 Apr 2025 20:02:07 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>> 
>> Testing: passes tier1 locally on my mac, Mach5 tier1-5 in progress
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove last default argument (found by Stefan)

This looks like it'll help remove the inadvertent mtNone categorizations, provided future changes fix the rest of the mtNone to the right categories.
Please take this through a tier1-3 round of testing on your latest change before pushing.

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

Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24634#pullrequestreview-2769691566

From andrew at openjdk.org  Tue Apr 15 23:12:02 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:12:02 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <8v_BOBtKZ6S0U0fDvcBGaA91365anLcqE55bocM46hM=.574971f4-e387-442f-813a-10599d309b48@github.com>

Merge jdk8u342-b04

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

Commit messages:
 - Merge jdk8u342-b04
 - 8031567: Better model for storing source revision information
 - 8202142: jfr/event/io/TestInstrumentation is unstable
 - 8266187: Memory leak in appendBootClassPath()
 - 8283350: (tz) Update Timezone Data to 2022a
 - 8286989: Build failure on macOS after 8281814
 - 8285727: [11u, 17u] Unify fix for JDK-8284920 with version from head
 - 8284620: CodeBuffer may leak _overflow_arena
 - 8285523: Improve test java/io/FileOutputStream/OpenNUL.java

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

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/18/files
  Stats: 1036 lines in 44 files changed: 525 ins; 84 del; 427 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/18.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u.git pull/18/head:pull/18

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/18

From andrew at openjdk.org  Tue Apr 15 23:12:02 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:12:02 GMT
Subject: RFR: Merge jdk8u:master
In-Reply-To: <8v_BOBtKZ6S0U0fDvcBGaA91365anLcqE55bocM46hM=.574971f4-e387-442f-813a-10599d309b48@github.com>
References: <8v_BOBtKZ6S0U0fDvcBGaA91365anLcqE55bocM46hM=.574971f4-e387-442f-813a-10599d309b48@github.com>
Message-ID: <ogmSyLqePODoqcL5w0gKsA7pqym1Hz96Xnw7lI6ek0I=.513cc762-4b80-4897-8322-58785e5da72c@github.com>

On Tue, 15 Apr 2025 23:07:33 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u342-b04

GHA builds will not work until [JDK-8284622](https://bugs.openjdk.org/browse/JDK-8284622) is merged in 8u362-b03

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

PR Comment: https://git.openjdk.org/shenandoah-jdk8u/pull/18#issuecomment-2807733124

From andrew at openjdk.org  Tue Apr 15 23:13:48 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:13:48 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 9 new changesets
Message-ID: <ea8d08fa-52b5-4111-8959-4a0000bdf18e@openjdk.org>

Changeset: db52470b
Branch: master
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2022-05-24 05:47:34 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/db52470b5fdcf48490bef30891424d23fe6b57dc

8285523: Improve test java/io/FileOutputStream/OpenNUL.java

Reviewed-by: andrew
Backport-of: f42631e354d4abf7994abd92aa5def6b2ceeab3a

! jdk/test/java/io/FileOutputStream/OpenNUL.java

Changeset: eb5711be
Branch: master
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2022-05-24 12:50:23 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/eb5711bebec7bc655629b9471d6a52bdec76c5c2

8284620: CodeBuffer may leak _overflow_arena

Reviewed-by: phh
Backport-of: 4d45c3ebc493bb2c85dab84b97840c8ba093ab1f

! hotspot/src/share/vm/asm/codeBuffer.cpp

Changeset: 7961755b
Branch: master
Author:    Yuri Nesterenko <yan at openjdk.org>
Date:      2022-05-24 13:02:20 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/7961755b8cd02c112ccfaceb9c20671c94a6c8e2

8285727: [11u, 17u] Unify fix for JDK-8284920 with version from head

Backport-of: a95482acf83cc03bc562baace0d55d831d0b2b41

! jaxp/src/com/sun/org/apache/xpath/internal/compiler/Lexer.java
! jaxp/src/com/sun/org/apache/xpath/internal/compiler/Token.java
! jaxp/src/com/sun/org/apache/xpath/internal/compiler/XPathParser.java
+ jdk/test/javax/xml/jaxp/unittest/xpath/XPathExpTest.java

Changeset: c5f96be5
Branch: master
Author:    Zdenek Zambersky <zzambers at redhat.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
Date:      2022-05-24 13:27:42 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/c5f96be5e370f01fbb8677049e2feeeeb3b3012d

8286989: Build failure on macOS after 8281814

Reviewed-by: sgehwolf

! make/common/NativeCompilation.gmk

Changeset: 83fbc961
Branch: master
Author:    Dmitry Cherepanov <dcherepanov at openjdk.org>
Date:      2022-05-24 13:51:25 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/83fbc9612f96d3485eec2754b3b37d2f6415bd80

8283350: (tz) Update Timezone Data to 2022a

Reviewed-by: sgehwolf
Backport-of: b05d4ccf8e54635c16bc2c26aa7a8fcc2e3b3dde

! jdk/make/data/tzdata/VERSION
! jdk/make/data/tzdata/africa
! jdk/make/data/tzdata/asia
! jdk/make/data/tzdata/europe
! jdk/make/data/tzdata/leapseconds
! jdk/make/data/tzdata/southamerica
! jdk/test/sun/util/calendar/zi/tzdata/VERSION
! jdk/test/sun/util/calendar/zi/tzdata/africa
! jdk/test/sun/util/calendar/zi/tzdata/asia
! jdk/test/sun/util/calendar/zi/tzdata/europe
! jdk/test/sun/util/calendar/zi/tzdata/leapseconds
! jdk/test/sun/util/calendar/zi/tzdata/southamerica

Changeset: d35dea79
Branch: master
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2022-05-24 14:20:53 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d35dea79f48691ea280f1f8863f23113fd0c6816

8266187: Memory leak in appendBootClassPath()

Backport-of: aa90df6f51940a73f9aa078a32768855c8568034

! jdk/src/share/instrument/InvocationAdapter.c

Changeset: 2194c539
Branch: master
Author:    Dongbo He <dongbohe at openjdk.org>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2022-05-25 12:04:16 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/2194c5399fb39fca711a6437a9f72700e951d930

8202142: jfr/event/io/TestInstrumentation is unstable

Reviewed-by: phh, zgu
Backport-of: 0b9ff0c3a418070996f61f69165de02d33070f7f

! jdk/test/jdk/jfr/event/io/IOEvent.java
! jdk/test/jdk/jfr/event/io/IOHelper.java
! jdk/test/jdk/jfr/event/io/TestDisabledEvents.java
! jdk/test/jdk/jfr/event/io/TestFileChannelEvents.java
! jdk/test/jdk/jfr/event/io/TestFileReadOnly.java
! jdk/test/jdk/jfr/event/io/TestFileStreamEvents.java
! jdk/test/jdk/jfr/event/io/TestInstrumentation.java
! jdk/test/jdk/jfr/event/io/TestRandomAccessFileEvents.java
! jdk/test/jdk/jfr/event/io/TestRandomAccessFileThread.java
! jdk/test/jdk/jfr/event/io/TestSocketChannelEvents.java
! jdk/test/jdk/jfr/event/io/TestSocketEvents.java

Changeset: e3b9a06a
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-26 00:35:39 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/e3b9a06ab885289e943167935912b42ab53244e3

8031567: Better model for storing source revision information
8170385: JDK-8031567 broke source bundles
8170392: JDK-8031567 broke builds from source bundles

Reviewed-by: sgehwolf
Backport-of: 27b7ab8b27a5548ed4cd823d35c8190a594bfdd1

! .hgignore
! common/autoconf/generated-configure.sh
! corba/.hgignore
! hotspot/.hgignore
! jaxp/.hgignore
! jaxws/.hgignore
! jdk/.hgignore
! jdk/make/Images.gmk
! langtools/.hgignore
! make/Main.gmk
+ make/SourceRevision.gmk
! make/common/MakeBase.gmk
! nashorn/.hgignore

Changeset: d27d9a12
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-15 20:45:36 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d27d9a12673de92b8a8eee4cd3d3673c97797521

Merge jdk8u342-b04

Added tag jdk8u342-b04 for changeset e3b9a06ab8



From andrew at openjdk.org  Tue Apr 15 23:14:08 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:14:08 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u352-b00 for changeset
 e3b9a06a
Message-ID: <c5c4015c-3c1a-4fa7-ac04-76bec20bf33c@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-09-01 18:29:53 +0000

Added tag jdk8u352-b00 for changeset e3b9a06ab88
Changeset: e3b9a06a
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-26 00:35:39 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/e3b9a06ab885289e943167935912b42ab53244e3


From andrew at openjdk.org  Tue Apr 15 23:14:12 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:14:12 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u352-b00 for
 changeset d27d9a12
Message-ID: <98418928-59ca-48f0-bb30-5cfa0cbc8e5a@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-16 00:11:53 +0000

Added tag shenandoah8u352-b00 for changeset d27d9a12673
Changeset: d27d9a12
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-15 20:45:36 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d27d9a12673de92b8a8eee4cd3d3673c97797521


From andrew at openjdk.org  Tue Apr 15 23:14:21 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:14:21 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u342-b04 for changeset
 e3b9a06a
Message-ID: <4d46cd4c-2e2a-438f-8da7-289de41ee19d@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-30 01:43:06 +0000

Added tag jdk8u342-b04 for changeset e3b9a06ab8
Changeset: e3b9a06a
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2022-05-26 00:35:39 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/e3b9a06ab885289e943167935912b42ab53244e3


From andrew at openjdk.org  Tue Apr 15 23:14:25 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:14:25 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u342-b04 for
 changeset d27d9a12
Message-ID: <0278f5cf-3c8b-4e71-ad35-8f8816e4546c@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-15 20:49:48 +0000

Added tag shenandoah8u342-b04 for changeset d27d9a12673
Changeset: d27d9a12
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-15 20:45:36 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/d27d9a12673de92b8a8eee4cd3d3673c97797521


From andrew at openjdk.org  Tue Apr 15 23:15:29 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:15:29 GMT
Subject: RFR: Merge jdk8u:master [v2]
In-Reply-To: <8v_BOBtKZ6S0U0fDvcBGaA91365anLcqE55bocM46hM=.574971f4-e387-442f-813a-10599d309b48@github.com>
References: <8v_BOBtKZ6S0U0fDvcBGaA91365anLcqE55bocM46hM=.574971f4-e387-442f-813a-10599d309b48@github.com>
Message-ID: <qPKPUYEOT_bXNjnVpfPAymTU0pBDmOgPhirP3HuYhP0=.351b198d-0b61-4220-bfee-a5791562cc3a@github.com>

> Merge jdk8u342-b04

Andrew John Hughes 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-jdk8u/pull/18/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/18/files/d27d9a12..d27d9a12

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

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/18

From iris at openjdk.org  Tue Apr 15 23:15:29 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 15 Apr 2025 23:15:29 GMT
Subject: Withdrawn: Merge jdk8u:master
In-Reply-To: <8v_BOBtKZ6S0U0fDvcBGaA91365anLcqE55bocM46hM=.574971f4-e387-442f-813a-10599d309b48@github.com>
References: <8v_BOBtKZ6S0U0fDvcBGaA91365anLcqE55bocM46hM=.574971f4-e387-442f-813a-10599d309b48@github.com>
Message-ID: <BRn9AenJ9FSRddkwAwRU4PO-fvXcRheCelt_PbdlcsM=.fed61cea-7594-417d-8464-a472f3e04305@github.com>

On Tue, 15 Apr 2025 23:07:33 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u342-b04

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/18

From andrew at openjdk.org  Tue Apr 15 23:40:16 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:40:16 GMT
Subject: git: openjdk/shenandoah-jdk8u: master: 2 new changesets
Message-ID: <35c791da-7697-4fe3-b997-6f2b9ae8cafc@openjdk.org>

Changeset: 95962f14
Branch: master
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2022-06-03 16:51:25 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/95962f141c996834e9f12cd8780a2f6e0c56d782

8287537: 8u JDK-8284620 backport broke AArch64 build

Reviewed-by: andrew

! hotspot/src/share/vm/asm/codeBuffer.cpp

Changeset: 259058e6
Branch: master
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-16 00:13:33 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/259058e632f3e8d7537a174756fd60530d185519

Merge jdk8u342-b05

Added tag jdk8u342-b05 for changeset 95962f141c



From andrew at openjdk.org  Tue Apr 15 23:40:24 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:40:24 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag jdk8u342-b05 for changeset
 95962f14
Message-ID: <8d5d8779-861c-4646-9e25-53e0f0447513@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2022-06-08 02:03:25 +0000

Added tag jdk8u342-b05 for changeset 95962f141c
Changeset: 95962f14
Author:    Zhengyu Gu <zgu at openjdk.org>
Date:      2022-06-03 16:51:25 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/95962f141c996834e9f12cd8780a2f6e0c56d782


From andrew at openjdk.org  Tue Apr 15 23:40:27 2025
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 15 Apr 2025 23:40:27 GMT
Subject: git: openjdk/shenandoah-jdk8u: Added tag shenandoah8u342-b05 for
 changeset 259058e6
Message-ID: <5aec31ed-640c-4666-bd22-c8420ad3707c@openjdk.org>

Tagged by: Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-16 00:34:44 +0000

Added tag shenandoah8u342-b05 for changeset 259058e632f
Changeset: 259058e6
Author:    Andrew John Hughes <andrew at openjdk.org>
Date:      2025-04-16 00:13:33 +0000
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/259058e632f3e8d7537a174756fd60530d185519


From stuefe at openjdk.org  Wed Apr 16 05:28:47 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 16 Apr 2025 05:28:47 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <A_y8LFDsZL8Ak7h3bYyfnQijgi_CU-jYCBBsDfKW5E0=.3d35072d-2fad-4204-b587-cf880fabe090@github.com>

On Fri, 11 Apr 2025 11:28:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

Hi @jsikstro, good cleanup, some small nits remain.

Cheers, Thomas

src/hotspot/share/gc/shared/collectedHeap.cpp line 119:

> 117:     heap->print_on(&st);
> 118:     MetaspaceUtils::print_on(&st);
> 119:   }

Pre-existing, the other cases of printing in this file have a preceding ResourceMark. It is either needed here or not needed there.

src/hotspot/share/memory/metaspace.cpp line 221:

> 219:   MetaspaceCombinedStats stats = get_combined_statistics();
> 220:   out->print("Metaspace");
> 221:   out->fill_to(17);

We rely on absolute position here? Will not work well with different indentation levels.

src/hotspot/share/utilities/vmError.cpp line 1399:

> 1397:       st->cr();
> 1398:     }
> 1399:     Universe::heap()->print_on_error(st);

Why is print_on_error called outside the indentation scope?

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

PR Review: https://git.openjdk.org/jdk/pull/24593#pullrequestreview-2770781675
PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2046093409
PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2046096635
PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2046084544

From jsjolen at openjdk.org  Wed Apr 16 06:47:42 2025
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Wed, 16 Apr 2025 06:47:42 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v3]
In-Reply-To: <I1d0YL-aLmDZaaaolaWh85I-e7DuSN3uks_YcML1KN0=.ca88c27e-c995-4611-91b4-516dc8fcb04d@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <I1d0YL-aLmDZaaaolaWh85I-e7DuSN3uks_YcML1KN0=.ca88c27e-c995-4611-91b4-516dc8fcb04d@github.com>
Message-ID: <bV9YWObD08JErY_5lyGklQN7-eqlJOmvK0V3FYLMXIk=.ce1bc738-d8e3-46e0-9d12-df8a565e03a8@github.com>

On Tue, 15 Apr 2025 20:02:07 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>> 
>> Testing: passes tier1 locally on my mac, Mach5 tier1-5 in progress
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove last default argument (found by Stefan)

GHA tier1 passes, only failing test is Shenandoah-related (not relevant to this change).

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

Marked as reviewed by jsjolen (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24634#pullrequestreview-2771320025

From stuefe at openjdk.org  Wed Apr 16 08:30:51 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 16 Apr 2025 08:30:51 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <x8AYWmSuO87dlDNGIDNVHFxCFQEEzez-NkrFjDcQFRA=.a7c9753d-bd97-4264-844b-3168cd3aac1d@github.com>

On Fri, 11 Apr 2025 11:28:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

Notes:

- We may want to simplify at some point and merge streamIndentor and streamAutoIndentor. That includes checking which existing call sites use streamIndentor *without* wanting auto indentation. Not sure but I guess there are none.
I think the existing cases fall into two categories: where streamIndentor was used on a stream that had already autoindent enabled, and where the code uses "cr_indent()" or "indent" to manually indent.

- It would be nice to have a short comment in collectedHeap.hpp about when print_on resp print_on_error is used. From your explanation, I expect print_on_error to be used for information that should only be printed in case of a fatal error, right?

- To simplify and prevent mistakes, we should consider making set_autoindent in outputStream private and make the indentor RAII classes friends of outputStream.

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

PR Comment: https://git.openjdk.org/jdk/pull/24593#issuecomment-2808804192

From stefank at openjdk.org  Wed Apr 16 08:37:42 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 16 Apr 2025 08:37:42 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v3]
In-Reply-To: <I1d0YL-aLmDZaaaolaWh85I-e7DuSN3uks_YcML1KN0=.ca88c27e-c995-4611-91b4-516dc8fcb04d@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <I1d0YL-aLmDZaaaolaWh85I-e7DuSN3uks_YcML1KN0=.ca88c27e-c995-4611-91b4-516dc8fcb04d@github.com>
Message-ID: <wxWRJ_0rVdjqwiDC4TkpeotxBXMIn8GX9TDYqaU6Np4=.e80d34e0-810d-471a-9e99-715879aca319@github.com>

On Tue, 15 Apr 2025 20:02:07 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
>> 
>> I tried to fill in tag, when I was pretty certain that I had the right type.
>> 
>> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
>> 
>> Testing: passes tier1 locally on my mac, Mach5 tier1-5 in progress
>
> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove last default argument (found by Stefan)

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24634#pullrequestreview-2771664245

From duke at openjdk.org  Wed Apr 16 09:10:53 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Apr 2025 09:10:53 GMT
Subject: Withdrawn: 8340434: Excessive Young GCs Triggered by CodeCache GC
 Threshold
In-Reply-To: <g22FgTJTATrz5UIKsSy3a98OgJIm8hvZ9KFm4u75PyY=.dea7d218-c0d7-43a9-afff-d167383eeb63@github.com>
References: <g22FgTJTATrz5UIKsSy3a98OgJIm8hvZ9KFm4u75PyY=.dea7d218-c0d7-43a9-afff-d167383eeb63@github.com>
Message-ID: <GfVAgfsKPTQ5Sv7kOGk5eblVTn24lyE2j0HZAPmtwUw=.ddecf12a-bee0-4f9d-8c09-a96550cc9089@github.com>

On Thu, 19 Sep 2024 08:43:50 GMT, sli-x <duke at openjdk.org> wrote:

> The trigger of _codecache_GC_threshold in CodeCache::gc_on_allocation is the key to this problem.
> 
> if (used_ratio > threshold) {
>     // After threshold is reached, scale it by free_ratio so that more aggressive
>     // GC is triggered as we approach code cache exhaustion
>     threshold *= free_ratio;
>   }
>   // If code cache has been allocated without any GC at all, let's make sure
>   // it is eventually invoked to avoid trouble.
>   if (allocated_since_last_ratio > threshold) {
>     // In case the GC is concurrent, we make sure only one thread requests the GC.
>     if (Atomic::cmpxchg(&_unloading_threshold_gc_requested, false, true) == false) {
>       log_info(codecache)("Triggering threshold (%.3f%%) GC due to allocating %.3f%% since last unloading (%.3f%% used -> %.3f%% used)",
>                           threshold * 100.0, allocated_since_last_ratio * 100.0, last_used_ratio * 100.0, used_ratio * 100.0);
>       Universe::heap()->collect(GCCause::_codecache_GC_threshold);
>     }
>   }
> 
> Here with the limited codecache size, the free_ratio will get lower and lower (so as the threshold) if no methods can be swept and thus leads to a more and more frequent collection behavior. Since the collection happens in stw, the whole performance of gc will also be degraded. 
> 
> So a simple solution is to delete the scaling logic here. However, I think here lies some problems worth further exploring.
> 
> There're two options to control a code cache sweeper,  StartAggressiveSweepingAt and SweeperThreshold.  StartAggressiveSweepingAt is a sweeper triggered for little space in codeCache and does little harm. However,  SweeperThreshold, first introduced by [JDK-8244660](https://bugs.openjdk.org/browse/JDK-8244660), was designed for a regular sweep for codecache, when codeCache sweeper and heap collection are actually individual. After [JDK-8290025](https://bugs.openjdk.org/browse/JDK-8290025) and some patches related, the old mechanism of codeCache sweeper is merged into a concurrent heap collection. So the Code cache sweeper heuristics and the unloading behavior will be promised by the concurrent collection. There's no longer any "zombie" methods to be counted. Considering it will introduce lots of useless collection jobs, I think SweeperThreshold should be deleted now.

This pull request has been closed without being integrated.

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

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

From jsikstro at openjdk.org  Wed Apr 16 13:25:47 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 16 Apr 2025 13:25:47 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
In-Reply-To: <A_y8LFDsZL8Ak7h3bYyfnQijgi_CU-jYCBBsDfKW5E0=.3d35072d-2fad-4204-b587-cf880fabe090@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <A_y8LFDsZL8Ak7h3bYyfnQijgi_CU-jYCBBsDfKW5E0=.3d35072d-2fad-4204-b587-cf880fabe090@github.com>
Message-ID: <f_SMX_AA-zDzTZ3AFa0mmp8sAHCHlumFpiDDkqKZmEM=.41d8eeab-cd21-43a2-ac78-91dfd9cad1fb@github.com>

On Wed, 16 Apr 2025 05:21:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hello,
>> 
>>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
>> 
>> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
>> 
>> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
>> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
>> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
>> 
>> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
>> 
>> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
>> 
>> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, th...
>
> src/hotspot/share/gc/shared/collectedHeap.cpp line 119:
> 
>> 117:     heap->print_on(&st);
>> 118:     MetaspaceUtils::print_on(&st);
>> 119:   }
> 
> Pre-existing, the other cases of printing in this file have a preceding ResourceMark. It is either needed here or not needed there.

The ResourceMarks that are used in other places in this file are not needed anymore. The reason they are placed where they are is because previously (a long time ago, since before [this](https://github.com/openjdk/jdk/commit/d12604111ccd6a5da38602077f4574adc850d9b8#diff-f9496186f2b54da5514e073a08b00afe2e2f8fbae899b13c182c8fbccc7aa7a6) commit), they were next to creating a debug stream. When the debug stream was replaced with a LogStream, the ResourceMark should have followed the LogStream, but it didn't in the changes for print_heap_{before,after}_gc(), see universe.cpp in [this](https://github.com/openjdk/jdk/commit/d12604111ccd6a5da38602077f4574adc850d9b8#diff-f9496186f2b54da5514e073a08b00afe2e2f8fbae899b13c182c8fbccc7aa7a6) commit, where the printing methods were before being moved to collectedHeap.cpp. 

The ResourceMarks should be removed, like Casper has done in [JDK-8294954](https://github.com/openjdk/jdk/pull/24162). I talked with Casper about the ResourceMarks, as he have looked over why the ResourceMarks are there in his patch and he agrees that they should be removed from print_heap_{before,after}_gc(), as they are likely there only for the LogStream.

To summarise, no, ResourceMarks are not needed here, and they should be removed in the other places in this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2046931370

From jsikstro at openjdk.org  Wed Apr 16 13:56:07 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 16 Apr 2025 13:56:07 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
In-Reply-To: <A_y8LFDsZL8Ak7h3bYyfnQijgi_CU-jYCBBsDfKW5E0=.3d35072d-2fad-4204-b587-cf880fabe090@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <A_y8LFDsZL8Ak7h3bYyfnQijgi_CU-jYCBBsDfKW5E0=.3d35072d-2fad-4204-b587-cf880fabe090@github.com>
Message-ID: <O78gXn7tR6ZGKk1epESKclLMeCbTvj4vq-TQLnlGzqk=.64f0a3ad-028d-4892-b3ea-b203e6577efd@github.com>

On Wed, 16 Apr 2025 05:15:40 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hello,
>> 
>>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
>> 
>> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
>> 
>> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
>> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
>> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
>> 
>> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
>> 
>> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
>> 
>> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, th...
>
> src/hotspot/share/utilities/vmError.cpp line 1399:
> 
>> 1397:       st->cr();
>> 1398:     }
>> 1399:     Universe::heap()->print_on_error(st);
> 
> Why is print_on_error called outside the indentation scope?

This is because print_on() is in its "own" block, inside "Heap:", while print_on_error() prints its own blocks, like "ZGC Globals:" below. Other GCs behave in the same way.


Heap:
 ZHeap           used 7740M, capacity 9216M, max capacity 9216M
  Cache          1476M (2)
   size classes  128M (1), 1G (1)
 Metaspace       used 18526K, committed 18816K, reserved 1114112K
  class space    used 1603K, committed 1728K, reserved 1048576K

ZGC Globals:
 Young Collection:   Mark/51
 Old Collection:     Mark/18
 Offset Max:         144G (0x0000002400000000)
 Page Size Small:    2M
 Page Size Medium:   32M

ZGC Metadata Bits:
 LoadGood:           0x000000000000d000
 LoadBad:            0x0000000000002000
...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2046992916

From jsikstro at openjdk.org  Wed Apr 16 14:08:47 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 16 Apr 2025 14:08:47 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
In-Reply-To: <A_y8LFDsZL8Ak7h3bYyfnQijgi_CU-jYCBBsDfKW5E0=.3d35072d-2fad-4204-b587-cf880fabe090@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <A_y8LFDsZL8Ak7h3bYyfnQijgi_CU-jYCBBsDfKW5E0=.3d35072d-2fad-4204-b587-cf880fabe090@github.com>
Message-ID: <g_b8A8y_5PAEKTt7-qirNoYeZ0R_wjoP-kJk1ako61c=.d00697bf-de5b-4a73-b6d5-dc5fc9762ae1@github.com>

On Wed, 16 Apr 2025 05:25:31 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hello,
>> 
>>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
>> 
>> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
>> 
>> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
>> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
>> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
>> 
>> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
>> 
>> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
>> 
>> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, th...
>
> src/hotspot/share/memory/metaspace.cpp line 221:
> 
>> 219:   MetaspaceCombinedStats stats = get_combined_statistics();
>> 220:   out->print("Metaspace");
>> 221:   out->fill_to(17);
> 
> We rely on absolute position here? Will not work well with different indentation levels.

This was intended to align good with how ZGC does it. After some thought I think a better strategy is to add a space at the end of the string before filling, like:

```c++
out->print("Metaspace ");
out->fill_to(17);

This still aligns to the 17th column, but will not break printing for deeper indentation levels (currently 6 or more).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2047019290

From jsikstro at openjdk.org  Wed Apr 16 14:19:03 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 16 Apr 2025 14:19:03 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v2]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <R3xyubNH0neBqIQbO4IHPObL6aBZvsGTL9LNNSWAKmI=.9555ad20-b5c4-4749-aa9f-59ec430dbe25@github.com>

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

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

 - Safety padding for deep indentation
 - Remove superfluous ResourceMarks
 - Comment for print_on_error()
 - Merge 'master' into JDK-8354362_autoindent_collectedheap

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/2c0c0b2b..9fea46ab

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

  Stats: 180592 lines in 408 files changed: 10159 ins; 169115 del; 1318 mod
  Patch: https://git.openjdk.org/jdk/pull/24593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24593/head:pull/24593

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

From jsikstro at openjdk.org  Wed Apr 16 14:19:49 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 16 Apr 2025 14:19:49 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v3]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <qnmOv6L5fTbPyNfiZSJ1o5n01qUFhkrTT8-k1goWAQk=.457e76a1-6278-4916-a873-882f860b1edc@github.com>

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

Joel Sikstr?m has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8354362_autoindent_collectedheap
 - Safety padding for deep indentation
 - Remove superfluous ResourceMarks
 - Comment for print_on_error()
 - 8354362: Use automatic indentation in CollectedHeap printing

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

Changes: https://git.openjdk.org/jdk/pull/24593/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=02
  Stats: 246 lines in 27 files changed: 88 ins; 89 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/24593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24593/head:pull/24593

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

From jsikstro at openjdk.org  Wed Apr 16 14:19:49 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 16 Apr 2025 14:19:49 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <MMrelg8tG_uBhnqsmPAxHZmjJSBNQcidr90VkKibQDM=.239f6f74-e8f4-46e1-8946-39c7ac67eeb6@github.com>

On Fri, 11 Apr 2025 11:28:12 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

Sorry for the force-push, made a mistake when merging with master. No comments should have been removed.

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

PR Comment: https://git.openjdk.org/jdk/pull/24593#issuecomment-2809736966

From jsikstro at openjdk.org  Wed Apr 16 14:28:46 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 16 Apr 2025 14:28:46 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
In-Reply-To: <x8AYWmSuO87dlDNGIDNVHFxCFQEEzez-NkrFjDcQFRA=.a7c9753d-bd97-4264-844b-3168cd3aac1d@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <x8AYWmSuO87dlDNGIDNVHFxCFQEEzez-NkrFjDcQFRA=.a7c9753d-bd97-4264-844b-3168cd3aac1d@github.com>
Message-ID: <X6QM64cBDes3TTbDHJT6--eT3T-GpxQgH-PWxh1gWdk=.95987a30-8002-4ea6-bbb8-ce91f7b32629@github.com>

On Wed, 16 Apr 2025 08:28:22 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hello,
>> 
>>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
>> 
>> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
>> 
>> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
>> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
>> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
>> 
>> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
>> 
>> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
>> 
>> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, th...
>
> Notes:
> 
> - We may want to simplify at some point and merge streamIndentor and streamAutoIndentor. That includes checking which existing call sites use streamIndentor *without* wanting auto indentation. Not sure but I guess there are none.
> I think the existing cases fall into two categories: where streamIndentor was used on a stream that had already autoindent enabled, and where the code uses "cr_indent()" or "indent" to manually indent.
> 
> - It would be nice to have a short comment in collectedHeap.hpp about when print_on resp print_on_error is used. From your explanation, I expect print_on_error to be used for information that should only be printed in case of a fatal error, right?
> 
> - To simplify and prevent mistakes, we should consider making set_autoindent in outputStream private and make the indentor RAII classes friends of outputStream.

Thank you for looking at this @tstuefe! 

I've addressed some of your comments with new commits. I agree that we likely want to merge streamIndentor and StreamAutoIndentor in a follow up RFE, where it also would be good to look at making set_autoindent() private. 

I haven't looked into it, but it feels weird to have an indentation level on an outputStream and use it only explicitly via indent() and not via a StreamAutoIndentor. I think a good solution would be to only allow indentation via the StreamAutoIndentor API like you're proposing, and look into whether there should be some API for temporarily disabling indentation with a RAII object (or just some parameters to StreamAutoIndentor) if there are cases that require it.

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

PR Comment: https://git.openjdk.org/jdk/pull/24593#issuecomment-2809764389

From duke at openjdk.org  Wed Apr 16 17:07:56 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Apr 2025 17:07:56 GMT
Subject: RFR: 8354541: Remove Shenandoah post barrier expand loop opts
In-Reply-To: <NUhDOYoV9638wYxRMxjYQaAxVMGbkpdXPmWIGFnYhB0=.df930962-5416-4a34-a03a-800de76104e9@github.com>
References: <NUhDOYoV9638wYxRMxjYQaAxVMGbkpdXPmWIGFnYhB0=.df930962-5416-4a34-a03a-800de76104e9@github.com>
Message-ID: <w8VH5GRfTj851gu9Ty312C4NKa8EdgtrqVHCI5zIegk=.0f9447df-2872-4d8a-9a29-c3840ad168e4@github.com>

On Mon, 14 Apr 2025 18:42:23 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please review this patch to remove Shenandoah post-barrier expand loop optimizations. This optimization was added in the first iteration os Shenandoah barriers. Nowadays, we try to always insert LRB at the earliest place and the impact of these optimizations is minimal; they are also frequent source of bugs.
> 
> Tested on OSX Aarch64 & Linux amd64 with JTREG tier1-3.

@JohnTortugo 
Your change (at version bc1dbaf4c33f71745a3454c0789972b52117ed22) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24630#issuecomment-2810192707

From stuefe at openjdk.org  Thu Apr 17 05:25:54 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 17 Apr 2025 05:25:54 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v3]
In-Reply-To: <g_b8A8y_5PAEKTt7-qirNoYeZ0R_wjoP-kJk1ako61c=.d00697bf-de5b-4a73-b6d5-dc5fc9762ae1@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <A_y8LFDsZL8Ak7h3bYyfnQijgi_CU-jYCBBsDfKW5E0=.3d35072d-2fad-4204-b587-cf880fabe090@github.com>
 <g_b8A8y_5PAEKTt7-qirNoYeZ0R_wjoP-kJk1ako61c=.d00697bf-de5b-4a73-b6d5-dc5fc9762ae1@github.com>
Message-ID: <tv1ts8cA0wAhCHOBUh5Iwzdv7frc2nOyNnKjSxASdbw=.6567216a-f89d-4444-822f-cedcae29184d@github.com>

On Wed, 16 Apr 2025 14:06:21 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> src/hotspot/share/memory/metaspace.cpp line 221:
>> 
>>> 219:   MetaspaceCombinedStats stats = get_combined_statistics();
>>> 220:   out->print("Metaspace");
>>> 221:   out->fill_to(17);
>> 
>> We rely on absolute position here? Will not work well with different indentation levels.
>
> This was intended to align good with how ZGC does it. After some thought I think a better strategy is to add a space at the end of the string before filling, like:
> 
> ```c++
> out->print("Metaspace ");
> out->fill_to(17);
> 
> This still aligns to the 17th column, but will not break printing for deeper indentation levels (currently 6 or more).

Yes that sounds better

>> src/hotspot/share/utilities/vmError.cpp line 1399:
>> 
>>> 1397:       st->cr();
>>> 1398:     }
>>> 1399:     Universe::heap()->print_on_error(st);
>> 
>> Why is print_on_error called outside the indentation scope?
>
> This is because print_on() is in its "own" block, inside "Heap:", while print_on_error() prints its own blocks, like "ZGC Globals:" below. Other GCs behave in the same way.
> 
> 
> Heap:
>  ZHeap           used 7740M, capacity 9216M, max capacity 9216M
>   Cache          1476M (2)
>    size classes  128M (1), 1G (1)
>  Metaspace       used 18526K, committed 18816K, reserved 1114112K
>   class space    used 1603K, committed 1728K, reserved 1048576K
> 
> ZGC Globals:
>  Young Collection:   Mark/51
>  Old Collection:     Mark/18
>  Offset Max:         144G (0x0000002400000000)
>  Page Size Small:    2M
>  Page Size Medium:   32M
> 
> ZGC Metadata Bits:
>  LoadGood:           0x000000000000d000
>  LoadBad:            0x0000000000002000
> ...

Hmm, that may be an indication that this should be in its own error reporting STEP, then? Probably does not matter much, just aesthetics

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2048252477
PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2048252150

From jsikstro at openjdk.org  Thu Apr 17 09:13:34 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 17 Apr 2025 09:13:34 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v4]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <qz-0leMo9qeUmps1g1HMwNpu6iFKB9t-dYBM2qgbEz4=.867e574d-4afd-4b94-8848-c873c6b05fc4@github.com>

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

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

 - Separate print_heap_on and print_gc_on in VMError printing
 - Rename print_on and print_on_error to print_heap_on and print_gc_on

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/c1140b86..2979316c

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

  Stats: 71 lines in 15 files changed: 19 ins; 6 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/24593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24593/head:pull/24593

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

From jsikstro at openjdk.org  Thu Apr 17 09:13:35 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 17 Apr 2025 09:13:35 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v4]
In-Reply-To: <tv1ts8cA0wAhCHOBUh5Iwzdv7frc2nOyNnKjSxASdbw=.6567216a-f89d-4444-822f-cedcae29184d@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <A_y8LFDsZL8Ak7h3bYyfnQijgi_CU-jYCBBsDfKW5E0=.3d35072d-2fad-4204-b587-cf880fabe090@github.com>
 <g_b8A8y_5PAEKTt7-qirNoYeZ0R_wjoP-kJk1ako61c=.d00697bf-de5b-4a73-b6d5-dc5fc9762ae1@github.com>
 <tv1ts8cA0wAhCHOBUh5Iwzdv7frc2nOyNnKjSxASdbw=.6567216a-f89d-4444-822f-cedcae29184d@github.com>
Message-ID: <4Swh7By1eRJ19p7ULrAryORBm97i0783ErfLDJhdnKw=.1a0e864e-e74f-4491-a153-fc1c049688be@github.com>

On Thu, 17 Apr 2025 05:23:10 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This is because print_on() is in its "own" block, inside "Heap:", while print_on_error() prints its own blocks, like "ZGC Globals:" below. Other GCs behave in the same way.
>> 
>> 
>> Heap:
>>  ZHeap           used 7740M, capacity 9216M, max capacity 9216M
>>   Cache          1476M (2)
>>    size classes  128M (1), 1G (1)
>>  Metaspace       used 18526K, committed 18816K, reserved 1114112K
>>   class space    used 1603K, committed 1728K, reserved 1048576K
>> 
>> ZGC Globals:
>>  Young Collection:   Mark/51
>>  Old Collection:     Mark/18
>>  Offset Max:         144G (0x0000002400000000)
>>  Page Size Small:    2M
>>  Page Size Medium:   32M
>> 
>> ZGC Metadata Bits:
>>  LoadGood:           0x000000000000d000
>>  LoadBad:            0x0000000000002000
>> ...
>
> Hmm, that may be an indication that this should be in its own error reporting STEP, then? Probably does not matter much, just aesthetics

I agree. With some suggestions from @stefank, I've renamed print_on() to print_heap_on() and print_on_error() to print_gc_on() to better reflect their purpose. I've also separated print_heap_on() and print_gc_on() into their own "STEPs" in the printing in vmError.cpp:


STEP("printing heap information")
  ...
  print_heap_on();
  ...

STEP("printing GC information")
  ...
  print_gc_on()
  ...


With this change it would make better sense to print the precious log in the GC section rather than the heap section. This would change the printing order, which I have not yet done in this patch, so I think it would be better in a follow up RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2048556654

From jsikstro at openjdk.org  Thu Apr 17 09:47:17 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 17 Apr 2025 09:47:17 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v5]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <nMO8jYUWutt1BwlJzc2w9HxunaltuqLo3b58QLxYopE=.dbe07c38-8c56-42c1-87dd-9118c4ab8c38@github.com>

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

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

  Shenandoah print rename

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/2979316c..33d20641

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

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

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

From stuefe at openjdk.org  Thu Apr 17 10:44:53 2025
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 17 Apr 2025 10:44:53 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v5]
In-Reply-To: <nMO8jYUWutt1BwlJzc2w9HxunaltuqLo3b58QLxYopE=.dbe07c38-8c56-42c1-87dd-9118c4ab8c38@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <nMO8jYUWutt1BwlJzc2w9HxunaltuqLo3b58QLxYopE=.dbe07c38-8c56-42c1-87dd-9118c4ab8c38@github.com>
Message-ID: <AoUojD7AAuFbb8-kO3aawPAk043OBa4xgJ4DBNj8crU=.7f1c0f70-513d-48c1-a2c0-ea3a3834e53f@github.com>

On Thu, 17 Apr 2025 09:47:17 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
>> 
>> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
>> 
>> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
>> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
>> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
>> 
>> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
>> 
>> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
>> 
>> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, th...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shenandoah print rename

Looks fine to me, but GC people should look at this too.

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

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24593#pullrequestreview-2775319824

From jsikstro at openjdk.org  Thu Apr 17 10:49:39 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 17 Apr 2025 10:49:39 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v6]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <xce57to-FioiaSagdwewc6j9xXD71s5_slcqnESy7tc=.37a74592-cd20-4962-b46a-35800c07b868@github.com>

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

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

  Rename ZGC printing to match print_heap_on() and print_gc_on()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/33d20641..0824712c

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

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

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

From stefank at openjdk.org  Thu Apr 17 11:28:04 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 17 Apr 2025 11:28:04 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v6]
In-Reply-To: <xce57to-FioiaSagdwewc6j9xXD71s5_slcqnESy7tc=.37a74592-cd20-4962-b46a-35800c07b868@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <xce57to-FioiaSagdwewc6j9xXD71s5_slcqnESy7tc=.37a74592-cd20-4962-b46a-35800c07b868@github.com>
Message-ID: <_rpazMMpjOnpEthySjhhfKE_Lit3eMNkH27qke5-Syc=.c0a68c73-9fdc-4ba8-950a-9fead760abda@github.com>

On Thu, 17 Apr 2025 10:49:39 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
>> 
>> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
>> 
>> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
>> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
>> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
>> 
>> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
>> 
>> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
>> 
>> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, th...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename ZGC printing to match print_heap_on() and print_gc_on()

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 680:

> 678:   }
> 679:   st->cr();
> 680: 

Below this line we still have a print_on_error call.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2048749718

From jsikstro at openjdk.org  Thu Apr 17 12:15:45 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 17 Apr 2025 12:15:45 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v7]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <uf5nqJaPwP4Zix45cEx0IsMSR4plawbZrMVAqJgjnFk=.558e58d8-9eff-4c80-952d-9ff541f9fd0e@github.com>

> Hello,
> 
>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
> 
> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
> 
> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
> 
> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
> 
> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
> 
> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, this is a trade-off worth makin...

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

  Rename print_on_error() in the remaining call-paths from print_gc_on()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/0824712c..042c0aee

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

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

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

From jsikstro at openjdk.org  Thu Apr 17 12:15:46 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 17 Apr 2025 12:15:46 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v6]
In-Reply-To: <_rpazMMpjOnpEthySjhhfKE_Lit3eMNkH27qke5-Syc=.c0a68c73-9fdc-4ba8-950a-9fead760abda@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <xce57to-FioiaSagdwewc6j9xXD71s5_slcqnESy7tc=.37a74592-cd20-4962-b46a-35800c07b868@github.com>
 <_rpazMMpjOnpEthySjhhfKE_Lit3eMNkH27qke5-Syc=.c0a68c73-9fdc-4ba8-950a-9fead760abda@github.com>
Message-ID: <go-lEh2oiQLWCFYt7794TT85pEk8lCQAKcIJ3Qe5uxw=.87b982fb-e42f-4c01-9748-339c01a23d20@github.com>

On Thu, 17 Apr 2025 11:24:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename ZGC printing to match print_heap_on() and print_gc_on()
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 680:
> 
>> 678:   }
>> 679:   st->cr();
>> 680: 
> 
> Below this line we still have a print_on_error call.

I renamed the remaining instances of print_on_error() in GC code with alternative names, all the way down to BitMap::print_on_error() which I renamed to BitMap::print_range_on(). The only remaining print_on_error() is GCLogPrecious::print_on_error(), which I figured might be left unchanged.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2048817231

From gziemski at openjdk.org  Thu Apr 17 12:57:27 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 17 Apr 2025 12:57:27 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v4]
In-Reply-To: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
Message-ID: <UVXwHwQFd7aZ3AfsDX-LPFeM-lJh2yZey_etc-DmvTU=.a242e2f0-b8ca-4fa0-87d1-47013e050153@github.com>

> Redo for a follow-up to https://github.com/openjdk/jdk/pull/21843. Here we are focusing on removing the mem tag paremeter with default value of mtNone, to force everyone to provide mem tag, if known.
> 
> I tried to fill in tag, when I was pretty certain that I had the right type.
> 
> At least one more follow-up will be needed after this, to change the remaining mtNone to valid values.
> 
> Testing: passes tier1 locally on my mac, Mach5 tier1-5 in progress

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 five additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - remove last default argument (found by Stefan)
 - fix build break
 - fix build break
 - redo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24634/files
  - new: https://git.openjdk.org/jdk/pull/24634/files/d5cea15d..07a3e5c9

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

  Stats: 11700 lines in 230 files changed: 9301 ins; 1557 del; 842 mod
  Patch: https://git.openjdk.org/jdk/pull/24634.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24634/head:pull/24634

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

From stefank at openjdk.org  Thu Apr 17 13:01:46 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 17 Apr 2025 13:01:46 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v7]
In-Reply-To: <uf5nqJaPwP4Zix45cEx0IsMSR4plawbZrMVAqJgjnFk=.558e58d8-9eff-4c80-952d-9ff541f9fd0e@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <uf5nqJaPwP4Zix45cEx0IsMSR4plawbZrMVAqJgjnFk=.558e58d8-9eff-4c80-952d-9ff541f9fd0e@github.com>
Message-ID: <OlgnPqFTZHIY5A_z6ujffqAwDypRMLA0Mm-sDQaGUOA=.385e193b-10e9-4d28-9d70-586cfd6dcd0d@github.com>

On Thu, 17 Apr 2025 12:15:45 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>>> This PR only focuses on fixing indentation and re-arranging some callsites. It does *not* change the contents of any output, apart from some (IMO relevant) indentation/whitespace additions.
>> 
>> Currently, the CollectedHeap printing code (print_on and print_on_error, with calls "below") prepends spaces in messages in a way that only makes sense if you write the code and then check the output to see if you've done everything correctly. To make writing and maintaining printing code easy, I propose we move to a system where each printing method, starting at callers of print_on and print_on_error, uses the indentation API in outputStream and does not rely on prepending spaces like is done right now.
>> 
>> What I propose is that any (GC) printing method should not make any assumptions of the indentation level of its caller(s). This means that each function shall:
>> 1. Not prepend any spaces to its printing, and instead expect that the caller(s) should handle any indentation before calling this function.
>> 2. Enforce its own indentation, by enabling auto indentation in its own context and for its "lower level" calls (which is often the desired outcome).
>> 
>> Combining these two rules means that *any* (GC) printing method can be called from anywhere and give sensible output, without (seemingly random) indentation of expectations elsewhere.
>> 
>> I have aggregated calls that print on the same indentation level to the same callsite. This makes it clear where to look in the code and also makes it easier to add/enforce indendation. To this end, I have re-arranged print_on_error so that it never includes print_on. The new system I propose is that print_on and print_on_error can be called separately for different information, which aligns well with having the same callsite for the same indentation. See changes in vmError.cpp for how this is implemented.
>> 
>> Instead of prepending spaces, I use StreamAutoIndentor, defined in ostream.hpp. To make using automatic indentation easier, I've made some changes to StreamAutoIndentor so that it inherits from streamIndentor and also add an *optional* argument to StreamAutoIndentor to apply an indentation. My reasoning for this is that most places that use streamIndentor also want to use StreamAutoIndentor (either immediately or some time before) so that it is automatically applied. A downside of this change is that any previous uses of StreamAutoIndentor now also needs to store an extra int worth of memory. To me, th...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename print_on_error() in the remaining call-paths from print_gc_on()

I think this looks good. Not yet a full review, thought, but just wanted to send out my +1 on the changes. I've added a couple of more suggestions.

src/hotspot/share/gc/serial/tenuredGeneration.cpp line 449:

> 447: 
> 448:   StreamAutoIndentor indentor(st, 1);
> 449:   st->print("the  "); _the_space->print_on(st);

Suggestion:

  st->print("the  ");
  _the_space->print_on(st);

src/hotspot/share/gc/z/zPageAllocator.cpp line 1171:

> 1169: }
> 1170: 
> 1171: void ZPartition::print_extended_cache_on(outputStream* st) const {

I would like to suggest that you flip the 'extended' and 'cache' words:
Suggestion:

void ZPartition::print_cache_extended_on(outputStream* st) const {


So, that we have the structure:

print_<what>_on
print_<what>_extended_on

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

PR Review: https://git.openjdk.org/jdk/pull/24593#pullrequestreview-2775538728
PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2048825842
PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2048839661

From wkemper at openjdk.org  Thu Apr 17 14:25:10 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 17 Apr 2025 14:25:10 GMT
Subject: RFR: Merge openjdk/jdk21u:master
Message-ID: <5HXqnKSRbTjYXx2P7ovdNJqk4QEHMxnND0QGrelIVfo=.34e09bf6-d161-459a-a8ca-291e153324a4@github.com>

Merges tag jdk-21.0.7-ga

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

Commit messages:
 - 8353904: [21u] Remove designator DEFAULT_PROMOTED_VERSION_PRE=ea for release 21.0.7
 - 8331735: UpcallLinker::on_exit races with GC when copying frame anchor
 - 8339810: Clean up the code in sun.tools.jar.Main to properly close resources and use ZipFile during extract
 - 8309841: Jarsigner should print a warning if an entry is removed
 - 8347847: Enhance jar file support
 - 8343007: Enhance Buffered Image handling
 - 8342562: Enhance Deflater operations
 - 8338430: Improve compiler transformations
 - 8337692: Better TLS connection support
 - 8337494: Clarify JarInputStream behavior

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

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/180/files
  Stats: 743 lines in 19 files changed: 504 ins; 87 del; 152 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/180.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/180/head:pull/180

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

From cslucas at openjdk.org  Thu Apr 17 17:43:55 2025
From: cslucas at openjdk.org (Cesar Soares Lucas)
Date: Thu, 17 Apr 2025 17:43:55 GMT
Subject: Integrated: 8354541: Remove Shenandoah post barrier expand loop opts
In-Reply-To: <NUhDOYoV9638wYxRMxjYQaAxVMGbkpdXPmWIGFnYhB0=.df930962-5416-4a34-a03a-800de76104e9@github.com>
References: <NUhDOYoV9638wYxRMxjYQaAxVMGbkpdXPmWIGFnYhB0=.df930962-5416-4a34-a03a-800de76104e9@github.com>
Message-ID: <A_i8NBooLvweARMcE4rGRkyDs07stGG2YvEt_Ws1eSs=.35199177-69aa-4fb7-bce8-ca9601208fa6@github.com>

On Mon, 14 Apr 2025 18:42:23 GMT, Cesar Soares Lucas <cslucas at openjdk.org> wrote:

> Please review this patch to remove Shenandoah post-barrier expand loop optimizations. This optimization was added in the first iteration os Shenandoah barriers. Nowadays, we try to always insert LRB at the earliest place and the impact of these optimizations is minimal; they are also frequent source of bugs.
> 
> Tested on OSX Aarch64 & Linux amd64 with JTREG tier1-3.

This pull request has now been integrated.

Changeset: 4eae9b5b
Author:    Cesar Soares Lucas <cslucas at openjdk.org>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4eae9b5ba61bfe262b43346a7499c98c1a54d2fe
Stats:     251 lines in 6 files changed: 0 ins; 248 del; 3 mod

8354541: Remove Shenandoah post barrier expand loop opts

Reviewed-by: shade

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

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

From kbarrett at openjdk.org  Fri Apr 18 01:18:57 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 18 Apr 2025 01:18:57 GMT
Subject: RFR: 8354309: Sort GC includes
In-Reply-To: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
References: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
Message-ID: <71sU43p9BXcVwu_0Axefr0ZH6s38dWXvM3WqDap7rG0=.562f8062-7c4d-4518-ae54-89f1d2981eb4@github.com>

On Thu, 10 Apr 2025 16:26:42 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> We now have a tool to fix our include lines to better adhere to the HotSpot Style Guide. See test/hotspot/jtreg/sources/SortIncludes.java. I've run the tool against the GC code and propose the resulting changes. I did one manual change to move a section guarded with INCLUDE_JFR.
> 
> Builds successfully with GHA. I will run this through tier1-2.

It seems there is disagreement over whether the jtreg include order test is
desirable. In the interest of not blocking what I think is an otherwise good
cleanup, I'm withdrawing my request for an update to the test.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24581#pullrequestreview-2777201796

From wkemper at openjdk.org  Fri Apr 18 20:19:25 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 18 Apr 2025 20:19:25 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
Message-ID: <KGR0BKfv87Ksx-_j8JL2umYy7QRFbGFFqXUFCMFCnpI=.e3f1444f-7040-4de8-8dcf-d3d645d9c9b9@github.com>

Need this to complete partial backport of related work in early change.

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

Commit messages:
 - 8337981: ShenandoahHeap::is_in should check for alive regions

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/181/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=181&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337981
  Stats: 103 lines in 10 files changed: 49 ins; 7 del; 47 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/181.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/181/head:pull/181

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

From kdnilsen at openjdk.org  Fri Apr 18 23:03:12 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 18 Apr 2025 23:03:12 GMT
Subject: RFR: 8337981: ShenandoahHeap::is_in should check for alive regions
In-Reply-To: <KGR0BKfv87Ksx-_j8JL2umYy7QRFbGFFqXUFCMFCnpI=.e3f1444f-7040-4de8-8dcf-d3d645d9c9b9@github.com>
References: <KGR0BKfv87Ksx-_j8JL2umYy7QRFbGFFqXUFCMFCnpI=.e3f1444f-7040-4de8-8dcf-d3d645d9c9b9@github.com>
Message-ID: <HBZ2_kryUVnPXTTxSIirOT_KgHVbc6JHTusdHD8u8k8=.194bf78f-3b06-4162-acda-a8ee4dac64c6@github.com>

On Fri, 18 Apr 2025 20:14:49 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Need this to complete partial backport of related work in early change.

Thanks for backport

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/181#pullrequestreview-2779589256