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

From gziemski at openjdk.org  Mon Apr 21 15:35:59 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 21 Apr 2025 15:35:59 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v5]
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: <4BfmRS_o0oAkdjGIhrQLs3CwLQ2qLRO4xNz5u-6ucxI=.87752d36-e205-42c4-a059-18cef4aaf0dd@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 six additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - 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/07a3e5c9..51ef0c5c

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

  Stats: 8560 lines in 160 files changed: 7396 ins; 844 del; 320 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 wkemper at openjdk.org  Mon Apr 21 15:50:17 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 21 Apr 2025 15:50:17 GMT
Subject: Integrated: 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: <Xot0MLAhxhPioEleYPalrJGEYZb2Wcx5NFl14o3atHM=.be81b1a7-904f-4b1f-a67b-8b02acf34537@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.

This pull request has now been integrated.

Changeset: 320b3afe
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/320b3afe87ce7906e3ba4061e9c5bf2ea341b2c0
Stats:     103 lines in 10 files changed: 49 ins; 7 del; 47 mod

8337981: ShenandoahHeap::is_in should check for alive regions

Reviewed-by: kdnilsen
Backport-of: b9d49dcef22ab81a087d890bbac0329a5244a2ef

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

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

From wkemper at openjdk.org  Mon Apr 21 15:52:28 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 21 Apr 2025 15:52:28 GMT
Subject: RFR: Merge openjdk/jdk21u:master [v2]
In-Reply-To: <5HXqnKSRbTjYXx2P7ovdNJqk4QEHMxnND0QGrelIVfo=.34e09bf6-d161-459a-a8ca-291e153324a4@github.com>
References: <5HXqnKSRbTjYXx2P7ovdNJqk4QEHMxnND0QGrelIVfo=.34e09bf6-d161-459a-a8ca-291e153324a4@github.com>
Message-ID: <dE_1aFvK_os-t-bUc0hCEK29rpdIl9E6hH-CCUuBZpY=.05c26640-716a-4e7e-80bc-0ec9a76c6f57@github.com>

> Merges tag jdk-21.0.7-ga

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

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/180/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/180/files/42157792..42157792

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 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 wkemper at openjdk.org  Mon Apr 21 15:52:29 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 21 Apr 2025 15:52:29 GMT
Subject: Integrated: Merge openjdk/jdk21u:master
In-Reply-To: <5HXqnKSRbTjYXx2P7ovdNJqk4QEHMxnND0QGrelIVfo=.34e09bf6-d161-459a-a8ca-291e153324a4@github.com>
References: <5HXqnKSRbTjYXx2P7ovdNJqk4QEHMxnND0QGrelIVfo=.34e09bf6-d161-459a-a8ca-291e153324a4@github.com>
Message-ID: <bRtZQfveSmBmbhzDfGL4vU87tBRQzc_NoFNVM__QD70=.912c31b0-c0dc-411e-88bd-e1452ad5ac37@github.com>

On Thu, 17 Apr 2025 14:21:27 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Merges tag jdk-21.0.7-ga

This pull request has now been integrated.

Changeset: 3c934aaa
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/3c934aaaa4c1536965186dfb651031a63611997e
Stats:     743 lines in 19 files changed: 504 ins; 87 del; 152 mod

Merge

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

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

From wkemper at openjdk.org  Mon Apr 21 20:08:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 21 Apr 2025 20:08:50 GMT
Subject: RFR: 8350898: Shenandoah: Eliminate final roots safepoint [v2]
In-Reply-To: <-L8jOYm9KnsXdTN8eILrxA_2Zp87GjoK5EAulnMvg30=.779e75b6-bcf5-497b-8c15-6f7684ac2278@github.com>
References: <-L8jOYm9KnsXdTN8eILrxA_2Zp87GjoK5EAulnMvg30=.779e75b6-bcf5-497b-8c15-6f7684ac2278@github.com>
Message-ID: <e0x03Xhr8BJI1f3TtXqoWTb5RoFpnH3806CUpq8UqjE=.c2ce3fa0-a24c-4f14-9d2a-ecb796beb14e@github.com>

> Not clean. Conflicts with oop closure refactoring (8342588).

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 two additional commits since the last revision:

 - Merge branch 'shenandoah-jdk21u-master' into backport-shenandoah-jdk21u-8350898
 - 8350898: Shenandoah: Eliminate final roots safepoint
   
   Reviewed-by: rkennke, kdnilsen, cslucas

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/179/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/179/files/fd062d26..a8d6e133

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

  Stats: 846 lines in 29 files changed: 553 ins; 94 del; 199 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 gziemski at openjdk.org  Mon Apr 21 20:20:27 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 21 Apr 2025 20:20:27 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v6]
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: <PFT33HuQYIGpc3_-vo55iNiuCr44BZsR42Fjv7TqcdI=.de81470d-e13e-460c-bf41-6bdf0fa809b4@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 seven additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - 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/51ef0c5c..de111829

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

  Stats: 1059 lines in 34 files changed: 860 ins; 139 del; 60 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 22 08:17:11 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Apr 2025 08:17:11 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v6]
In-Reply-To: <PFT33HuQYIGpc3_-vo55iNiuCr44BZsR42Fjv7TqcdI=.de81470d-e13e-460c-bf41-6bdf0fa809b4@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <PFT33HuQYIGpc3_-vo55iNiuCr44BZsR42Fjv7TqcdI=.de81470d-e13e-460c-bf41-6bdf0fa809b4@github.com>
Message-ID: <i3PGwEnJupfefgVSbGXAZR2xtQP7Q2EemdLoaeblC3k=.4ff915cd-559e-4091-a864-13c7086041c0@github.com>

On Mon, 21 Apr 2025 20:20:27 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - remove last default argument (found by Stefan)
>  - fix build break
>  - fix build break
>  - redo

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24634#pullrequestreview-2783240953

From jsikstro at openjdk.org  Tue Apr 22 09:26:41 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 22 Apr 2025 09:26:41 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v8]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <Xwsjq67vcYwhB1kj1QoXHfZzAz8SBEPLtfgNd0SW3oo=.dc455ec0-5798-4267-b098-aa95d80d7857@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 13 commits:

 - Merge branch 'master' into JDK-8354362_autoindent_collectedheap
 - Flip extended_on naming order
 - Revert line-break in tenuredGeneration.cpp
 - Rename print_on_error() in the remaining call-paths from print_gc_on()
 - Rename ZGC printing to match print_heap_on() and print_gc_on()
 - Shenandoah print rename
 - 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
 - Merge branch 'master' into JDK-8354362_autoindent_collectedheap
 - Safety padding for deep indentation
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9eeb86d9...1e9d4be4

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

Changes: https://git.openjdk.org/jdk/pull/24593/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=07
  Stats: 327 lines in 42 files changed: 105 ins; 92 del; 130 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  Tue Apr 22 11:47:54 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 22 Apr 2025 11:47:54 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: <kmKFmBBg6yD3sxWrBHgoBiniOOyezmbW9WsKvbBF-TU=.5f454950-8750-491a-9f1b-f840b6888063@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.

Thanks for unblocking the cleanup!

Given that there's not an unanimous desire for having a strict test in tier1 I'm glad that we can defer that discussion out of my PR and have it as a follow-up discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/24581#issuecomment-2821067297

From gziemski at openjdk.org  Tue Apr 22 12:48:04 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 22 Apr 2025 12:48:04 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v7]
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: <dUvjt1QKJxfDU9Q_7q-H7CR_r_AURjUOFI7YbzMGn_4=.ef6b5c5a-bfcd-47d8-8c61-c43252d36595@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 eight additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - 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/de111829..bfec2cf3

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

  Stats: 9359 lines in 110 files changed: 8641 ins; 476 del; 242 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 jsikstro at openjdk.org  Tue Apr 22 13:25:22 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 22 Apr 2025 13:25:22 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v9]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <7yvwm_aaSWl-nzKgMpUIScBEYSRLLLH_QyXlagLQGCU=.1ed25b3e-fc52-4034-b268-e3ad691947be@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.
> 
>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. With this change, printing heap information and gc information is now two distinct steps in vmError.cpp.
> 
> 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 StreamAutoInden...

Joel Sikstr?m has updated the pull request incrementally with two additional commits since the last revision:

 - Ternary instead of conditional in VirtualSpace::print_on
 - Consistent line-breaking and spaces

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/1e9d4be4..115dc41a

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

  Stats: 23 lines in 4 files changed: 7 ins; 5 del; 11 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  Tue Apr 22 13:25:24 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 22 Apr 2025 13:25:24 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v8]
In-Reply-To: <Xwsjq67vcYwhB1kj1QoXHfZzAz8SBEPLtfgNd0SW3oo=.dc455ec0-5798-4267-b098-aa95d80d7857@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <Xwsjq67vcYwhB1kj1QoXHfZzAz8SBEPLtfgNd0SW3oo=.dc455ec0-5798-4267-b098-aa95d80d7857@github.com>
Message-ID: <IQlEPZzk2yVT9c_nPpQNc8cO-yRL7iWRMhzGhtKSMPw=.659949e8-0e94-40a6-be76-58366da7e824@github.com>

On Tue, 22 Apr 2025 09:26:41 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.
>> 
>>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. With this change, printing heap information and gc information is now two distinct steps in vmError.cpp.
>> 
>> 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 *optio...
>
> 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 13 commits:
> 
>  - Merge branch 'master' into JDK-8354362_autoindent_collectedheap
>  - Flip extended_on naming order
>  - Revert line-break in tenuredGeneration.cpp
>  - Rename print_on_error() in the remaining call-paths from print_gc_on()
>  - Rename ZGC printing to match print_heap_on() and print_gc_on()
>  - Shenandoah print rename
>  - 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
>  - Merge branch 'master' into JDK-8354362_autoindent_collectedheap
>  - Safety padding for deep indentation
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/9eeb86d9...1e9d4be4

After some discussion with @lkorinth and @xmas92 I've opted to use consistent line-breaking and some other style changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/24593#issuecomment-2821318776

From gziemski at openjdk.org  Tue Apr 22 14:07:42 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 22 Apr 2025 14:07:42 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v7]
In-Reply-To: <dUvjt1QKJxfDU9Q_7q-H7CR_r_AURjUOFI7YbzMGn_4=.ef6b5c5a-bfcd-47d8-8c61-c43252d36595@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <dUvjt1QKJxfDU9Q_7q-H7CR_r_AURjUOFI7YbzMGn_4=.ef6b5c5a-bfcd-47d8-8c61-c43252d36595@github.com>
Message-ID: <QjQdt_jIWnPv3hS9-q8c2NwFNTXaOn6EpwXoiwUWUg8=.0a630b29-ac3e-452a-b24d-daa91f2d69a3@github.com>

On Tue, 22 Apr 2025 12:48:04 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - remove last default argument (found by Stefan)
>  - fix build break
>  - fix build break
>  - redo

Thank you all for reviews. I merged yesterday and ran tier1-3, which passes. I merged again this morning and ran tier1 locally, which passes.

I'm going to integrate as soon as [Pre-submit tests - windows-x64 / test - Test (tier1)](https://github.com/openjdk/jdk/pull/24634/checks?check_run_id=40944629903) finishes.

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

PR Comment: https://git.openjdk.org/jdk/pull/24634#issuecomment-2821449233

From gziemski at openjdk.org  Tue Apr 22 14:56:49 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 22 Apr 2025 14:56:49 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v7]
In-Reply-To: <dUvjt1QKJxfDU9Q_7q-H7CR_r_AURjUOFI7YbzMGn_4=.ef6b5c5a-bfcd-47d8-8c61-c43252d36595@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <dUvjt1QKJxfDU9Q_7q-H7CR_r_AURjUOFI7YbzMGn_4=.ef6b5c5a-bfcd-47d8-8c61-c43252d36595@github.com>
Message-ID: <qB3313brtlkJA14zGQvDkGE0Q-6G867eSteBnsWx_Ow=.99e783d4-c5de-46cd-a34b-b8a16d47316e@github.com>

On Tue, 22 Apr 2025 12:48:04 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - remove last default argument (found by Stefan)
>  - fix build break
>  - fix build break
>  - redo

Mach5 is undergoing upgrade, so need to wait till that is done.

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

PR Comment: https://git.openjdk.org/jdk/pull/24634#issuecomment-2821603214

From jsikstro at openjdk.org  Tue Apr 22 14:57:06 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 22 Apr 2025 14:57:06 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v10]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <yhwfdGaDbakOmqWqFd-5BqTyrQIeSjARMaaMzXJVfuE=.a675eb3c-520f-430a-a3ba-1ddcc9b65d65@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.
> 
>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. With this change, printing heap information and gc information is now two distinct steps in vmError.cpp.
> 
> 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 StreamAutoInden...

Joel Sikstr?m has updated the pull request incrementally with three additional commits since the last revision:

 - Fix Parallel NUMA printing
 - Use prefix for Parallel printing
 - Use prefix for Serial printing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/115dc41a..1cb525aa

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

  Stats: 37 lines in 11 files changed: 7 ins; 8 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 jsikstro at openjdk.org  Tue Apr 22 15:05:08 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Tue, 22 Apr 2025 15:05:08 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v11]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <FoXAWU_R9kbAXYMVKyg8ZhAYgNiqMass4EMIiQKupZA=.d8961437-039f-4fea-826b-338fe6304c54@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.
> 
>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. With this change, printing heap information and gc information is now two distinct steps in vmError.cpp.
> 
> 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 StreamAutoInden...

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Use FormatBuffer instead of local char buf

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/1cb525aa..e89b916f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=09-10

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 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  Wed Apr 23 10:10:20 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 23 Apr 2025 10:10:20 GMT
Subject: RFR: 8354309: Sort GC includes [v2]
In-Reply-To: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
References: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
Message-ID: <Cv-Km9iqUivPlVzDSRRrWIxgLjQatQEtTbhdRLSMl0E=.5defd101-328b-4f0e-bdb9-55c637b11b71@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.

Stefan Karlsson 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:

 - Fix windows compliation error
 - Merge remote-tracking branch 'upstream/master' into 8354309_sort_gc_includes
 - Merge remote-tracking branch 'upstream/master' into 8354309_sort_gc_includes
 - 8354309: Sort GC includes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24581/files
  - new: https://git.openjdk.org/jdk/pull/24581/files/cf81077d..54a5d61b

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

  Stats: 214494 lines in 1181 files changed: 38563 ins; 172575 del; 3356 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 stefank at openjdk.org  Wed Apr 23 10:10:21 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 23 Apr 2025 10:10:21 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: <MvqeTTBhjn3C3CNCsunOXHGi9-aRQThNkdCiIRUxUog=.2dcd1919-62de-49bf-a695-3ffbc0bd556e@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.

You can't safely reorder Memoryapi.h and Windows.h when compiling on Windows. I've simply removed the redundant include of Memoryapi.h to get this to compile.

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

PR Comment: https://git.openjdk.org/jdk/pull/24581#issuecomment-2823776122

From eosterlund at openjdk.org  Wed Apr 23 10:16:47 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 23 Apr 2025 10:16:47 GMT
Subject: RFR: 8354309: Sort GC includes [v2]
In-Reply-To: <Cv-Km9iqUivPlVzDSRRrWIxgLjQatQEtTbhdRLSMl0E=.5defd101-328b-4f0e-bdb9-55c637b11b71@github.com>
References: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
 <Cv-Km9iqUivPlVzDSRRrWIxgLjQatQEtTbhdRLSMl0E=.5defd101-328b-4f0e-bdb9-55c637b11b71@github.com>
Message-ID: <EMw4TIirSjNyYyTkV8r_UBGfgLTAXEvQDo-JfYw5EhI=.412069d9-647a-4fe8-bf0f-51e0ad42679b@github.com>

On Wed, 23 Apr 2025 10:10:20 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.
>
> Stefan Karlsson 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:
> 
>  - Fix windows compliation error
>  - Merge remote-tracking branch 'upstream/master' into 8354309_sort_gc_includes
>  - Merge remote-tracking branch 'upstream/master' into 8354309_sort_gc_includes
>  - 8354309: Sort GC includes

Still good!

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

Marked as reviewed by eosterlund (Reviewer).

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

From stefank at openjdk.org  Wed Apr 23 10:16:47 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 23 Apr 2025 10:16:47 GMT
Subject: RFR: 8354309: Sort GC includes [v2]
In-Reply-To: <Cv-Km9iqUivPlVzDSRRrWIxgLjQatQEtTbhdRLSMl0E=.5defd101-328b-4f0e-bdb9-55c637b11b71@github.com>
References: <qhM1ISrYAXLMF1bbJE-6arENXcac8j98Rebo4ZrUPPA=.3ebc43dc-e02d-4777-90c4-e184670ef241@github.com>
 <Cv-Km9iqUivPlVzDSRRrWIxgLjQatQEtTbhdRLSMl0E=.5defd101-328b-4f0e-bdb9-55c637b11b71@github.com>
Message-ID: <zJZPYdVPGyd-bgDbuxqZRZ_inKtfnffvTceBg6Jloag=.246503ea-830d-4d1b-8429-f37e994c9f3a@github.com>

On Wed, 23 Apr 2025 10:10:20 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.
>
> Stefan Karlsson 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:
> 
>  - Fix windows compliation error
>  - Merge remote-tracking branch 'upstream/master' into 8354309_sort_gc_includes
>  - Merge remote-tracking branch 'upstream/master' into 8354309_sort_gc_includes
>  - 8354309: Sort GC includes

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24581#issuecomment-2823789685

From stefank at openjdk.org  Wed Apr 23 10:16:48 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 23 Apr 2025 10:16:48 GMT
Subject: Integrated: 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: <JzNgUGKYI7BgOp1tBt79mYUzE5UG_r9ARUymMspdNvo=.1af732ef-cdc6-41cb-b759-1fc049d0041c@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.

This pull request has now been integrated.

Changeset: e76f2030
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e76f20301c3dcd65610e982fc98b7a08ebf0c8f1
Stats:     551 lines in 197 files changed: 267 ins; 270 del; 14 mod

8354309: Sort GC includes

Reviewed-by: eosterlund, iwalulya, kbarrett

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

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

From kdnilsen at openjdk.org  Wed Apr 23 15:47:24 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 23 Apr 2025 15:47:24 GMT
Subject: RFR: 8355336: GenShen: Resume Old GC even with back-to-back Young GC
 triggers
Message-ID: <Szc4G3tgDn8HMc4fAWx1nc3TDB60Mwru4PMS337zE6g=.b633bef0-f770-40f7-9794-9b2a0224d255@github.com>

Allow old-gen concurrent marking cycles to get their full time slice even when young-gc is triggered back-to-back.

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

Commit messages:
 - Fix white space
 - Allow old-gen incrments of work between young gc
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 26 more: https://git.openjdk.org/jdk/compare/b7e8952a...322e2eca

Changes: https://git.openjdk.org/jdk/pull/24810/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24810&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8355336
  Stats: 26 lines in 3 files changed: 8 ins; 14 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24810/head:pull/24810

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

From jsikstro at openjdk.org  Wed Apr 23 16:02:39 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Wed, 23 Apr 2025 16:02:39 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v12]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <MOiCp2suQVeXOYr3JiegvTznoWhIxpPaqAsvN4QDtig=.3ad60327-ef62-4ca5-bc4a-127958ad8133@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.
> 
>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
> 
> 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 ap...

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Use MutexLocker instead of lock/unlock in vmError.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/e89b916f..b9b975de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=10-11

  Stats: 20 lines in 1 file changed: 2 ins; 2 del; 16 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 lkorinth at openjdk.org  Wed Apr 23 16:02:40 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 23 Apr 2025 16:02:40 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v11]
In-Reply-To: <FoXAWU_R9kbAXYMVKyg8ZhAYgNiqMass4EMIiQKupZA=.d8961437-039f-4fea-826b-338fe6304c54@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <FoXAWU_R9kbAXYMVKyg8ZhAYgNiqMass4EMIiQKupZA=.d8961437-039f-4fea-826b-338fe6304c54@github.com>
Message-ID: <c-aq_t6MRq2GhbV66uDgZC6wx2B3d7VzIlqrS969EbE=.65420b20-3725-4a6c-9dc4-759ddbbdc021@github.com>

On Tue, 22 Apr 2025 15:05:08 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.
>> 
>>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
>> 
>> 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* argu...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use FormatBuffer instead of local char buf

src/hotspot/share/utilities/vmError.cpp line 1395:

> 1393:   // Take heap lock over both heap and GC printing so that information is
> 1394:   // consistent.
> 1395:   Heap_lock->lock();

I would prefer using `MutexLocker` even though it changes indentation (of the source code).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2056384316

From lkorinth at openjdk.org  Wed Apr 23 16:35:59 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 23 Apr 2025 16:35:59 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v11]
In-Reply-To: <FoXAWU_R9kbAXYMVKyg8ZhAYgNiqMass4EMIiQKupZA=.d8961437-039f-4fea-826b-338fe6304c54@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <FoXAWU_R9kbAXYMVKyg8ZhAYgNiqMass4EMIiQKupZA=.d8961437-039f-4fea-826b-338fe6304c54@github.com>
Message-ID: <1LetmrR7P0aNn-68DtV_k0BnHDnd7LGVGnkxAKDsgCI=.e2e9678b-862c-4ff6-81c5-4d684f263ac1@github.com>

On Tue, 22 Apr 2025 15:05:08 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.
>> 
>>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
>> 
>> 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* argu...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use FormatBuffer instead of local char buf

src/hotspot/share/utilities/ostream.hpp line 190:

> 188: };
> 189: 
> 190: class StreamAutoIndentor : public streamIndentor {

Just a note, not a request for change: I would personally have used composition instead of inheritance here (of `streamIndentor`).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2056458328

From wkemper at openjdk.org  Wed Apr 23 16:50:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 16:50:50 GMT
Subject: RFR: 8355336: GenShen: Resume Old GC even with back-to-back Young
 GC triggers
In-Reply-To: <Szc4G3tgDn8HMc4fAWx1nc3TDB60Mwru4PMS337zE6g=.b633bef0-f770-40f7-9794-9b2a0224d255@github.com>
References: <Szc4G3tgDn8HMc4fAWx1nc3TDB60Mwru4PMS337zE6g=.b633bef0-f770-40f7-9794-9b2a0224d255@github.com>
Message-ID: <BAWUAWgVSCpNgOMKvZU41tDJKJgW3jQuLkM6A5RLI_g=.b109af81-f30c-4f2f-8cb8-f4752d1c4b66@github.com>

On Wed, 23 Apr 2025 00:57:53 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Allow old-gen concurrent marking cycles to get their full time slice even when young-gc is triggered back-to-back.

I'm okay with this, but it will have the regulator thread give higher priority to the old generation when the collector is idle. Have we looked closely at performance results?

src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 80:

> 78:           _old_heuristics->cancel_trigger_request();
> 79:         } else if (start_young_cycle()) {
> 80:             log_debug(gc)("Heuristics request for young collection accepted");

Indentation looks a little off here.

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

Changes requested by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24810#pullrequestreview-2788071594
PR Review Comment: https://git.openjdk.org/jdk/pull/24810#discussion_r2056487435

From lkorinth at openjdk.org  Wed Apr 23 17:32:43 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 23 Apr 2025 17:32:43 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v12]
In-Reply-To: <MOiCp2suQVeXOYr3JiegvTznoWhIxpPaqAsvN4QDtig=.3ad60327-ef62-4ca5-bc4a-127958ad8133@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <MOiCp2suQVeXOYr3JiegvTznoWhIxpPaqAsvN4QDtig=.3ad60327-ef62-4ca5-bc4a-127958ad8133@github.com>
Message-ID: <yo4QzwVOa-jJ6AXQX_T25yylrMbNlM2yUzTJomeO1h8=.b870c4df-a89c-4ffb-88a9-e637a80af692@github.com>

On Wed, 23 Apr 2025 16:02: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.
>> 
>>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
>> 
>> 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* argu...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use MutexLocker instead of lock/unlock in vmError.cpp

I think this looks great. Thank you.

You might want to run a bit more internal testing; it is too easy to write a test that looks for specific formatting in the logs. 

Mostly unrelated to this change: I think that `outputStream` probably should have a version of `fill_to` that guarantees a separating space so that a trailing space does not need to be put before the call (it ought to be by *far* the most common case). That is clearly out of scope for this change however.

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

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24593#pullrequestreview-2788195879

From wkemper at openjdk.org  Wed Apr 23 20:27:53 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 20:27:53 GMT
Subject: RFR: 8353596: GenShen: Test TestClone.java#generational-no-coops
 intermittent timed out
Message-ID: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>

We've identified another scenario that could result in intermittent timeout failures in jtreg tests. If the cause of the gc cycle is `GCCause::_codecache_GC_threshold`, the thread requesting the GC will not be notified.

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

Commit messages:
 - Notify gc waiter and alloc failure waiters when a gc completes successfully

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

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

From kdnilsen at openjdk.org  Wed Apr 23 20:27:53 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 23 Apr 2025 20:27:53 GMT
Subject: RFR: 8353596: GenShen: Test TestClone.java#generational-no-coops
 intermittent timed out
In-Reply-To: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>
References: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>
Message-ID: <z89gnLYt4lxCpuKorK7LCaMzMa8uUwwT-b6JYM2Siw8=.ee534c5f-d8f5-45af-930a-b52c870557b8@github.com>

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

> We've identified another scenario that could result in intermittent timeout failures in jtreg tests. If the cause of the gc cycle is `GCCause::_codecache_GC_threshold`, the thread requesting the GC will not be notified.

Thanks for quick turnaround.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24834#pullrequestreview-2788605951

From kdnilsen at openjdk.org  Wed Apr 23 22:10:25 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 23 Apr 2025 22:10:25 GMT
Subject: RFR: 8350898: Shenandoah: Eliminate final roots safepoint [v2]
In-Reply-To: <e0x03Xhr8BJI1f3TtXqoWTb5RoFpnH3806CUpq8UqjE=.c2ce3fa0-a24c-4f14-9d2a-ecb796beb14e@github.com>
References: <-L8jOYm9KnsXdTN8eILrxA_2Zp87GjoK5EAulnMvg30=.779e75b6-bcf5-497b-8c15-6f7684ac2278@github.com>
 <e0x03Xhr8BJI1f3TtXqoWTb5RoFpnH3806CUpq8UqjE=.c2ce3fa0-a24c-4f14-9d2a-ecb796beb14e@github.com>
Message-ID: <v2Y5aBBKBhxZ8sbPV031HqhPPNkn2bFoYHN4jMCFpxQ=.8142fd8a-ecd2-450d-ba48-fdca534a5f20@github.com>

On Mon, 21 Apr 2025 20:08:50 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Not clean. Conflicts with oop closure refactoring (8342588).
>
> 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 two additional commits since the last revision:
> 
>  - Merge branch 'shenandoah-jdk21u-master' into backport-shenandoah-jdk21u-8350898
>  - 8350898: Shenandoah: Eliminate final roots safepoint
>    
>    Reviewed-by: rkennke, kdnilsen, cslucas

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/179#pullrequestreview-2788775604

From wkemper at openjdk.org  Wed Apr 23 22:29:21 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 22:29:21 GMT
Subject: Integrated: 8350898: Shenandoah: Eliminate final roots safepoint
In-Reply-To: <-L8jOYm9KnsXdTN8eILrxA_2Zp87GjoK5EAulnMvg30=.779e75b6-bcf5-497b-8c15-6f7684ac2278@github.com>
References: <-L8jOYm9KnsXdTN8eILrxA_2Zp87GjoK5EAulnMvg30=.779e75b6-bcf5-497b-8c15-6f7684ac2278@github.com>
Message-ID: <eT0wn93kN3K9JH1ZSptgKghB2aUaV_fclj5QVkwnAgY=.f0ad4674-b491-490f-af7d-2c8ebc053cb1@github.com>

On Tue, 15 Apr 2025 00:14:22 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean. Conflicts with oop closure refactoring (8342588).

This pull request has now been integrated.

Changeset: f63dd7e0
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/f63dd7e0b87235e7d6512aefae524b9f6487c359
Stats:     296 lines in 14 files changed: 199 ins; 47 del; 50 mod

8350898: Shenandoah: Eliminate final roots safepoint

Reviewed-by: kdnilsen
Backport-of: 8a1c85eaa902500d49ca82c67b6838d39cb5b24f

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

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

From ysr at openjdk.org  Wed Apr 23 22:50:55 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 23 Apr 2025 22:50:55 GMT
Subject: RFR: 8353596: GenShen: Test TestClone.java#generational-no-coops
 intermittent timed out
In-Reply-To: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>
References: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>
Message-ID: <10EkhLGZbkBYjscXFuo2u7doVzGuBfJ0W1z_LQf8SRQ=.a963a760-21ba-4841-be67-76335acbe6b9@github.com>

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

> We've identified another scenario that could result in intermittent timeout failures in jtreg tests. If the cause of the gc cycle is `GCCause::_codecache_GC_threshold`, the thread requesting the GC will not be notified.

This is a safe change. Did you check if there were any other spots that might have this issue? In particular, I see `ShenandoahControlThread::run_service()` which notifies whenever a GC has been requested (which is, I assume, morally equivalent to what's being done here), except we do this whenever we don't cancel the GC -- it could be unnecessary in some cases, I guess, which the original code for Shenandoah was trying to avoid. Not a big deal, but to the extent we can keep the logic similar in both (or shared as much as possible), the fewer such divergence in behavior between the two for the common cases.

It would be good to document more completely this method of `ShenandoahGenerationalControlThread` in terms of who it must notify and when.


  // Executes one GC cycle
  void run_gc_cycle(const ShenandoahGCRequest& request);

(For example, an equally valid change may have been to change the condition for the cause tested at line 277 to include the code cache induced gc cause.)

Change looks good and safe modulo those more general comments. No changes are needed in this PR, but something for us to keep in mind to make this code more robust and maintainable.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24834#pullrequestreview-2788826245

From wkemper at openjdk.org  Wed Apr 23 23:02:54 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 23:02:54 GMT
Subject: RFR: 8353596: GenShen: Test TestClone.java#generational-no-coops
 intermittent timed out
In-Reply-To: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>
References: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>
Message-ID: <4B_A_HEoSHsN63co339n9DX4drOcOyXE4rydAoYxilM=.ef92a95f-a67f-4e60-aec7-c6afe0779b18@github.com>

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

> We've identified another scenario that could result in intermittent timeout failures in jtreg tests. If the cause of the gc cycle is `GCCause::_codecache_GC_threshold`, the thread requesting the GC will not be notified.

That's a good call out. I don't believe `ShenandoahControlThread` is affected by this same issue because it will notify if `_gc_requested` is set, and doesn't care about the _cause_ of the gc. I did also consider adding `_codecache_GC_threshold` as a cause for explicit gc, except I'm not sure it really is (in the sense that the user did not explicitly request it). Also, it felt like a losing game because the next time a new gc cause is added, we'd need to evaluate whether or not it was `explicit`.

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

PR Comment: https://git.openjdk.org/jdk/pull/24834#issuecomment-2825691769

From wkemper at openjdk.org  Wed Apr 23 23:02:54 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 23:02:54 GMT
Subject: Integrated: 8353596: GenShen: Test
 TestClone.java#generational-no-coops intermittent timed out
In-Reply-To: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>
References: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>
Message-ID: <LuyYc4WccwACIiZCrH6YuO-FRArkDzOzYNJWzm46tfw=.ce11fc6a-e568-4d89-b9ec-7112c6f42f01@github.com>

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

> We've identified another scenario that could result in intermittent timeout failures in jtreg tests. If the cause of the gc cycle is `GCCause::_codecache_GC_threshold`, the thread requesting the GC will not be notified.

This pull request has now been integrated.

Changeset: ac17449b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac17449bdb946d98cb65c8eae9c9671f527a79cb
Stats:     7 lines in 1 file changed: 1 ins; 5 del; 1 mod

8353596: GenShen: Test TestClone.java#generational-no-coops intermittent timed out

Reviewed-by: kdnilsen, ysr

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

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

From ysr at openjdk.org  Wed Apr 23 23:06:45 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 23 Apr 2025 23:06:45 GMT
Subject: RFR: 8353596: GenShen: Test TestClone.java#generational-no-coops
 intermittent timed out
In-Reply-To: <4B_A_HEoSHsN63co339n9DX4drOcOyXE4rydAoYxilM=.ef92a95f-a67f-4e60-aec7-c6afe0779b18@github.com>
References: <QXs508O_lGxd2CxH_7adzyyd04WiJYx8GfDVbZtRZPk=.a2020bee-55e3-4375-bcc9-a65f74177a03@github.com>
 <4B_A_HEoSHsN63co339n9DX4drOcOyXE4rydAoYxilM=.ef92a95f-a67f-4e60-aec7-c6afe0779b18@github.com>
Message-ID: <VRxLQl7IaS-0HAbnsNUPxgvoiEZXnVBoMv_xrUQfA28=.7c4b5498-a023-4d36-ace7-eb19550ee2ff@github.com>

On Wed, 23 Apr 2025 22:57:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> That's a good call out. I don't believe `ShenandoahControlThread` is affected by this same issue because it will notify if `_gc_requested` is set, and doesn't care about the _cause_ of the gc.

Correct.

> I did also consider adding `_codecache_GC_threshold` as a cause for explicit gc, except I'm not sure it really is (in the sense that the user did not explicitly request it). Also, it felt like a losing game because the next time a new gc cause is added, we'd need to evaluate whether or not it was `explicit`.

I agree that this works better as it notifies gc waiters in all cases.

One question is where `_gc_requested` is reset and whether to keep the two controllers' logic similar, if an identical condition were used here (or an identical condition were used in the case of non-generational controller), and if not why it would not work (perhaps because the requests are handled differently). But, yes, such a clean-up is for another day, not this PR.

?

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

PR Comment: https://git.openjdk.org/jdk/pull/24834#issuecomment-2825719660

From wkemper at openjdk.org  Wed Apr 23 23:40:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 23:40:42 GMT
Subject: RFR: 8352588: GenShen: Enabling JFR asserts when getting GCId
Message-ID: <CuGfoB-QX7hyp6Bo3mF8pkA-h0ej2HSvvZHlaAIMVwA=.4cd1ac0f-84de-47bf-9aff-ad950cea8339@github.com>

Clean backport, possibly related to https://bugs.openjdk.org/browse/JDK-8354431

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

Commit messages:
 - Backport a2a64dac1680e97dd9eb511ead951bf1be8121c6

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

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

From wkemper at openjdk.org  Wed Apr 23 23:41:56 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 23:41:56 GMT
Subject: RFR: 8353596: GenShen: Test TestClone.java#generational-no-coops
 intermittent timed out
Message-ID: <zDzvr88U8Yr5NEDjCWdW2nP9sIWr-8E7ZzpVZA-aozw=.4ba63c45-5c60-4027-a275-1ec1e816fdeb@github.com>

Clean backport. Fixes stuck thread issue.

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

Commit messages:
 - Backport ac17449bdb946d98cb65c8eae9c9671f527a79cb

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

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

From wkemper at openjdk.org  Wed Apr 23 23:45:55 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 23:45:55 GMT
Subject: Integrated: 8353596: GenShen: Test
 TestClone.java#generational-no-coops intermittent timed out
In-Reply-To: <zDzvr88U8Yr5NEDjCWdW2nP9sIWr-8E7ZzpVZA-aozw=.4ba63c45-5c60-4027-a275-1ec1e816fdeb@github.com>
References: <zDzvr88U8Yr5NEDjCWdW2nP9sIWr-8E7ZzpVZA-aozw=.4ba63c45-5c60-4027-a275-1ec1e816fdeb@github.com>
Message-ID: <uqR8tvf4wtiKMwDBzsXSVnSD7gtA6Bs4wbA6h45n8cs=.585682f2-b036-4b9c-a26a-1847f403d1dd@github.com>

On Wed, 23 Apr 2025 23:36:55 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport. Fixes stuck thread issue.

This pull request has now been integrated.

Changeset: 0eb4b6fe
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/0eb4b6fe540b9fbb5fc0f009347cc5233f0a2e92
Stats:     7 lines in 1 file changed: 1 ins; 5 del; 1 mod

8353596: GenShen: Test TestClone.java#generational-no-coops intermittent timed out

Backport-of: ac17449bdb946d98cb65c8eae9c9671f527a79cb

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

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

From wkemper at openjdk.org  Wed Apr 23 23:47:06 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 23:47:06 GMT
Subject: Integrated: 8352588: GenShen: Enabling JFR asserts when getting GCId
In-Reply-To: <CuGfoB-QX7hyp6Bo3mF8pkA-h0ej2HSvvZHlaAIMVwA=.4cd1ac0f-84de-47bf-9aff-ad950cea8339@github.com>
References: <CuGfoB-QX7hyp6Bo3mF8pkA-h0ej2HSvvZHlaAIMVwA=.4cd1ac0f-84de-47bf-9aff-ad950cea8339@github.com>
Message-ID: <yhHc35FH6rrxnFArEtZQqBxCswu_tTE3OZru9hkbg-U=.01a2e10c-9180-4341-9e45-732d2f0a2bdf@github.com>

On Wed, 23 Apr 2025 23:35:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport, possibly related to https://bugs.openjdk.org/browse/JDK-8354431

This pull request has now been integrated.

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

8352588: GenShen: Enabling JFR asserts when getting GCId

Backport-of: a2a64dac1680e97dd9eb511ead951bf1be8121c6

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

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

From wkemper at openjdk.org  Wed Apr 23 23:47:41 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 23 Apr 2025 23:47:41 GMT
Subject: RFR: 8348400: GenShen:
 assert(ShenandoahHeap::heap()->is_full_gc_in_progress() ||
 (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity
 #
Message-ID: <7mis3faNstlnIBrm12WrdwXQx3IRqAJj9IBXA1c2xqI=.ce0830d0-1f19-4d95-9f23-9a01b0c1a2ec@github.com>

Conflict caused by `SIZE_FORMAT -> %zu` change.

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

Commit messages:
 - Backport 5672a934fa1b0b42ae9bb39b31579a27e3332c28

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

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

From stefank at openjdk.org  Thu Apr 24 12:46:49 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Apr 2025 12:46:49 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v12]
In-Reply-To: <MOiCp2suQVeXOYr3JiegvTznoWhIxpPaqAsvN4QDtig=.3ad60327-ef62-4ca5-bc4a-127958ad8133@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <MOiCp2suQVeXOYr3JiegvTznoWhIxpPaqAsvN4QDtig=.3ad60327-ef62-4ca5-bc4a-127958ad8133@github.com>
Message-ID: <fpLiquKCRGNlnpk76Dg5GV6aGEc2Jqe95wXuT2TORUo=.3df0e199-1014-4314-908d-1797ae888e0b@github.com>

On Wed, 23 Apr 2025 16:02: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.
>> 
>>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
>> 
>> 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* argu...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use MutexLocker instead of lock/unlock in vmError.cpp

Looks good.

One suggestion:

src/hotspot/share/gc/shared/collectedHeap.hpp line 442:

> 440: 
> 441:   // Print additional information about the GC that is not included in print_heap_on().
> 442:   // Generally used for printing information in case of a fatal error.

Given that this is also used in VM.info I think it would be better to skip this comment.
Suggestion:

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24593#pullrequestreview-2790903684
PR Review Comment: https://git.openjdk.org/jdk/pull/24593#discussion_r2058263736

From jsikstro at openjdk.org  Thu Apr 24 14:03:17 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 24 Apr 2025 14:03:17 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v13]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <HSq2msvR6saT6PawWoio4gju2tUmtG0Tc4qsel4rIvU=.3369152a-a7b1-4fdc-92eb-6c6796f309b7@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.
> 
>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
> 
> 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 ap...

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/gc/shared/collectedHeap.hpp
  
  Co-authored-by: Stefan Karlsson <stefan.karlsson at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/b9b975de..a9dc76a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 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 24 14:07:04 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 24 Apr 2025 14:07:04 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v14]
In-Reply-To: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
Message-ID: <vBt8FxBcZAiCOWNXR1VSx6mqkO8r9esHF2NgT56Ln_E=.519cd929-56f5-49c1-ab20-2f5df707cbc9@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.
> 
>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
> 
> 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 ap...

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  Copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24593/files
  - new: https://git.openjdk.org/jdk/pull/24593/files/a9dc76a3..daf58f9d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24593&range=12-13

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 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 24 14:11:46 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 24 Apr 2025 14:11:46 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v14]
In-Reply-To: <vBt8FxBcZAiCOWNXR1VSx6mqkO8r9esHF2NgT56Ln_E=.519cd929-56f5-49c1-ab20-2f5df707cbc9@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <vBt8FxBcZAiCOWNXR1VSx6mqkO8r9esHF2NgT56Ln_E=.519cd929-56f5-49c1-ab20-2f5df707cbc9@github.com>
Message-ID: <dULKJn0FdXJBbexK9dOlknSuvDYbhEhpQBcVRESMyUg=.65f42689-25d3-4e02-bf4c-68c9311201a8@github.com>

On Thu, 24 Apr 2025 14:07:04 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.
>> 
>>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
>> 
>> 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* argu...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24593#pullrequestreview-2791359217

From lkorinth at openjdk.org  Thu Apr 24 14:11:45 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 24 Apr 2025 14:11:45 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v14]
In-Reply-To: <vBt8FxBcZAiCOWNXR1VSx6mqkO8r9esHF2NgT56Ln_E=.519cd929-56f5-49c1-ab20-2f5df707cbc9@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <vBt8FxBcZAiCOWNXR1VSx6mqkO8r9esHF2NgT56Ln_E=.519cd929-56f5-49c1-ab20-2f5df707cbc9@github.com>
Message-ID: <PUMqNzJjk_ckGPtnEIFTIMt5HewwofQhAM5PHweHqFA=.d7741a45-daed-462c-93b4-611144e4cc5b@github.com>

On Thu, 24 Apr 2025 14:07:04 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.
>> 
>>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
>> 
>> 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* argu...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

lgtm

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

Marked as reviewed by lkorinth (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24593#pullrequestreview-2791351835

From jsikstro at openjdk.org  Thu Apr 24 14:17:24 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 24 Apr 2025 14:17:24 GMT
Subject: RFR: 8354362: Use automatic indentation in CollectedHeap printing
 [v14]
In-Reply-To: <vBt8FxBcZAiCOWNXR1VSx6mqkO8r9esHF2NgT56Ln_E=.519cd929-56f5-49c1-ab20-2f5df707cbc9@github.com>
References: <trRgUzwlMfA7bkOqLETIJmAp4LUBlNgzw9aLFyTJumE=.27a26e4b-97c7-4288-a012-aa0f14305085@github.com>
 <vBt8FxBcZAiCOWNXR1VSx6mqkO8r9esHF2NgT56Ln_E=.519cd929-56f5-49c1-ab20-2f5df707cbc9@github.com>
Message-ID: <Grk-epgSc3PR2S1gqP49j48hP6VEM5cF1S17IQ6STEg=.d8277cd5-c63a-4240-8724-80e40068d402@github.com>

On Thu, 24 Apr 2025 14:07:04 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.
>> 
>>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
>> 
>> 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* argu...
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright years

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24593#issuecomment-2827774330

From jsikstro at openjdk.org  Thu Apr 24 14:17:24 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 24 Apr 2025 14:17:24 GMT
Subject: Integrated: 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: <zH4j4-fQwtt76AgQdIRvPDsxOoGW3z6u8s4zGqBk6TQ=.e5a4c51a-4213-4d12-af54-2b2f4530d479@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.
> 
>> Update: 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 where they're called. With this I've also renamed other instances of print_on_error to better reflect their purpose. Printing heap information and printing gc information is now two distinct steps in vmError.cpp.
> 
> 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 ap...

This pull request has now been integrated.

Changeset: cf96b107
Author:    Joel Sikstr?m <jsikstro at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cf96b107d57182ad6ab47125939423dd5286aa88
Stats:     363 lines in 46 files changed: 104 ins; 93 del; 166 mod

8354362: Use automatic indentation in CollectedHeap printing

Reviewed-by: stefank, lkorinth, stuefe

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

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

From kdnilsen at openjdk.org  Thu Apr 24 15:57:49 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 24 Apr 2025 15:57:49 GMT
Subject: RFR: 8355340: GenShen: Remove unneeded log messages related to
 remembered set write table
Message-ID: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>

Remove unneeded log messages related to processing of the remembered set write card table.

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

Commit messages:
 - Remove one additional log message
 - Remove extraneous log messages
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - Merge branch 'openjdk:master' into master
 - ... and 25 more: https://git.openjdk.org/jdk/compare/83c7d3bb...c1f65632

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

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

From wkemper at openjdk.org  Thu Apr 24 18:31:23 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 24 Apr 2025 18:31:23 GMT
Subject: RFR: 8353218: Shenandoah: Out of date comment references Brooks
 pointers
Message-ID: <ron0BMLQ-eAUzbozW0H8H_FIFGun6ntpJeaLtDBvqUM=.9c46ba07-3baa-407b-a4b0-c2abbc24f958@github.com>

Clean backport, trivial change.

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

Commit messages:
 - Backport b4ab964b72c631632511e6f01cdd5a47fb2e31fa

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

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

From wkemper at openjdk.org  Thu Apr 24 18:48:32 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 24 Apr 2025 18:48:32 GMT
Subject: Integrated: 8353218: Shenandoah: Out of date comment references Brooks
 pointers
In-Reply-To: <ron0BMLQ-eAUzbozW0H8H_FIFGun6ntpJeaLtDBvqUM=.9c46ba07-3baa-407b-a4b0-c2abbc24f958@github.com>
References: <ron0BMLQ-eAUzbozW0H8H_FIFGun6ntpJeaLtDBvqUM=.9c46ba07-3baa-407b-a4b0-c2abbc24f958@github.com>
Message-ID: <sB-f0sBCF_bQ2TMbAtImCzlH8Dp-sRnDuyg8va2Qk7k=.6cc6b61f-3c6c-41b4-9ddc-2f19a99ce12f@github.com>

On Thu, 24 Apr 2025 18:00:16 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport, trivial change.

This pull request has now been integrated.

Changeset: 46192f28
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/46192f28a40dd2ab1b6ff9e2f9a534e232363a2a
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8353218: Shenandoah: Out of date comment references Brooks pointers

Backport-of: b4ab964b72c631632511e6f01cdd5a47fb2e31fa

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

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

From kdnilsen at openjdk.org  Thu Apr 24 19:37:23 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 24 Apr 2025 19:37:23 GMT
Subject: RFR: 8348400: GenShen:
 assert(ShenandoahHeap::heap()->is_full_gc_in_progress() ||
 (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity
 #
In-Reply-To: <7mis3faNstlnIBrm12WrdwXQx3IRqAJj9IBXA1c2xqI=.ce0830d0-1f19-4d95-9f23-9a01b0c1a2ec@github.com>
References: <7mis3faNstlnIBrm12WrdwXQx3IRqAJj9IBXA1c2xqI=.ce0830d0-1f19-4d95-9f23-9a01b0c1a2ec@github.com>
Message-ID: <3Pxb-mZ7rzIggb76XhirGN7botJj155bCdghndcFV9k=.a9ced454-f75e-47f2-8372-7b8b8f7213a7@github.com>

On Wed, 23 Apr 2025 23:41:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict caused by `SIZE_FORMAT -> %zu` change.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/184#pullrequestreview-2792291949

From gziemski at openjdk.org  Thu Apr 24 19:55:02 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 24 Apr 2025 19:55:02 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v8]
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: <FzWBAqkHv8s5fqJ81QLWK7jEe7jD7o4tVX2MrxP_2RU=.591a67e0-2885-4a37-bdbf-75b4d8e5df5f@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 nine additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - 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/bfec2cf3..dc030a20

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

  Stats: 21329 lines in 783 files changed: 14806 ins; 4805 del; 1718 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 xpeng at openjdk.org  Thu Apr 24 22:47:28 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 24 Apr 2025 22:47:28 GMT
Subject: RFR: 8354431: gc/logging/TestGCId fails on Shenandoah
Message-ID: <XZsYbrfIVILjrfmoOlS7soVxoFrSVCeEPmfeRBLvJR0=.6ddd8637-8a0f-488a-b980-27fda1eb5da1@github.com>

I can't reproduce the issue in Linux, but based on the gc log share in JBS bug and the related code, it is easy to find the root cause of it.


[0.133s][info][gc] GC(0) Concurrent reset after collect (unload classes) 0.033ms
[0.135s][info][gc] Trigger: Learning 2 of 5. Free (3958K) is below initial threshold (7167K)
[0.135s][info][gc] Failed to allocate Shared, 128K
[0.137s][info][gc] Trigger: Handle Allocation Failure
[0.148s][info][gc] GC(2) Degenerated GC upgrading to Full GC
[0.167s][info][gc] GC(2) Pause Degenerated GC (Outside of Cycle) 5M->1M(10M) 30.323ms


At 0.135s, a concurrent cycle was triggered: `[0.135s][info][gc] Trigger: Learning 2 of 5.`, meanwhile there was allocation failure causing degen: `[0.135s][info][gc] Failed to allocate Shared, 128K`.
In the implementation of ShenandoahControlThread::service_concurrent_normal_cycle, it checks if there degen or cancellation before starting the concurrent cycle and return w/o any gc log, which causes the missing GCID 1 in the GC log.

Since technically it is not a bug, to fix the potential failure of test `gc/logging/TestGCId` I'll add one line code to print GC log like "[0.135s][info][gc] GC(1) Cancelled"

### Test
- [x] gc/logging/TestGCId
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - 8354431: gc/logging/TestGCId fails on Shenandoah

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

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

From wkemper at openjdk.org  Thu Apr 24 22:59:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 24 Apr 2025 22:59:50 GMT
Subject: RFR: 8354431: gc/logging/TestGCId fails on Shenandoah
In-Reply-To: <XZsYbrfIVILjrfmoOlS7soVxoFrSVCeEPmfeRBLvJR0=.6ddd8637-8a0f-488a-b980-27fda1eb5da1@github.com>
References: <XZsYbrfIVILjrfmoOlS7soVxoFrSVCeEPmfeRBLvJR0=.6ddd8637-8a0f-488a-b980-27fda1eb5da1@github.com>
Message-ID: <YQJLz5ofkxd1D8a3zFMtzqJpGi-oVRWwhKbsP315i2s=.f0475fef-b477-498a-ab26-5adaa03726a6@github.com>

On Thu, 24 Apr 2025 17:41:52 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> I can't reproduce the issue in Linux, but based on the gc log share in JBS bug and the related code, it is easy to find the root cause of it.
> 
> 
> [0.133s][info][gc] GC(0) Concurrent reset after collect (unload classes) 0.033ms
> [0.135s][info][gc] Trigger: Learning 2 of 5. Free (3958K) is below initial threshold (7167K)
> [0.135s][info][gc] Failed to allocate Shared, 128K
> [0.137s][info][gc] Trigger: Handle Allocation Failure
> [0.148s][info][gc] GC(2) Degenerated GC upgrading to Full GC
> [0.167s][info][gc] GC(2) Pause Degenerated GC (Outside of Cycle) 5M->1M(10M) 30.323ms
> 
> 
> At 0.135s, a concurrent cycle was triggered: `[0.135s][info][gc] Trigger: Learning 2 of 5.`, meanwhile there was allocation failure causing degen: `[0.135s][info][gc] Failed to allocate Shared, 128K`.
> In the implementation of ShenandoahControlThread::service_concurrent_normal_cycle, it checks if there degen or cancellation before starting the concurrent cycle and return w/o any gc log, which causes the missing GCID 1 in the GC log.
> 
> Since technically it is not a bug, to fix the potential failure of test `gc/logging/TestGCId` I'll add one line code to print GC log like "[0.135s][info][gc] GC(1) Cancelled"
> 
> ### Test
> - [x] gc/logging/TestGCId
> - [x] hotspot_gc_shenandoah

Looks good to me. Thank you for the quick diagnosis and fix.

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

Marked as reviewed by wkemper (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24856#pullrequestreview-2792691440

From phh at openjdk.org  Thu Apr 24 23:26:55 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 24 Apr 2025 23:26:55 GMT
Subject: RFR: 8354431: gc/logging/TestGCId fails on Shenandoah
In-Reply-To: <XZsYbrfIVILjrfmoOlS7soVxoFrSVCeEPmfeRBLvJR0=.6ddd8637-8a0f-488a-b980-27fda1eb5da1@github.com>
References: <XZsYbrfIVILjrfmoOlS7soVxoFrSVCeEPmfeRBLvJR0=.6ddd8637-8a0f-488a-b980-27fda1eb5da1@github.com>
Message-ID: <7DwiLIqXphVlnHTCdhU43JiL-5Wz21yAzyxs-KH7X_M=.72eaad80-eea4-4a65-bc39-9e8b98e32af5@github.com>

On Thu, 24 Apr 2025 17:41:52 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> I can't reproduce the issue in Linux, but based on the gc log shared in JBS bug and the related code, it is easy to find the root cause of it.
> 
> 
> [0.133s][info][gc] GC(0) Concurrent reset after collect (unload classes) 0.033ms
> [0.135s][info][gc] Trigger: Learning 2 of 5. Free (3958K) is below initial threshold (7167K)
> [0.135s][info][gc] Failed to allocate Shared, 128K
> [0.137s][info][gc] Trigger: Handle Allocation Failure
> [0.148s][info][gc] GC(2) Degenerated GC upgrading to Full GC
> [0.167s][info][gc] GC(2) Pause Degenerated GC (Outside of Cycle) 5M->1M(10M) 30.323ms
> 
> 
> At 0.135s, a concurrent cycle was triggered: `[0.135s][info][gc] Trigger: Learning 2 of 5.`, meanwhile there was allocation failure causing degen: `[0.135s][info][gc] Failed to allocate Shared, 128K`.
> In the implementation of ShenandoahControlThread::service_concurrent_normal_cycle, it checks if there degen or cancellation before starting the concurrent cycle and return w/o any gc log, which causes the missing GCID 1 in the GC log.
> 
> Since technically it is not a bug, to fix the potential failure of test `gc/logging/TestGCId` I'll add one line code to print GC log like "[0.135s][info][gc] GC(1) Cancelled"
> 
> ### Test
> - [x] gc/logging/TestGCId
> - [x] hotspot_gc_shenandoah

Marked as reviewed by phh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24856#pullrequestreview-2792713348

From xpeng at openjdk.org  Thu Apr 24 23:26:56 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 24 Apr 2025 23:26:56 GMT
Subject: RFR: 8354431: gc/logging/TestGCId fails on Shenandoah
In-Reply-To: <XZsYbrfIVILjrfmoOlS7soVxoFrSVCeEPmfeRBLvJR0=.6ddd8637-8a0f-488a-b980-27fda1eb5da1@github.com>
References: <XZsYbrfIVILjrfmoOlS7soVxoFrSVCeEPmfeRBLvJR0=.6ddd8637-8a0f-488a-b980-27fda1eb5da1@github.com>
Message-ID: <RLouMGyZE0Bt12YXNY8GACm8l-dLdto2HJVtHI4037o=.9c7bfa87-5546-44d9-b71d-253c8eef59e5@github.com>

On Thu, 24 Apr 2025 17:41:52 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> I can't reproduce the issue in Linux, but based on the gc log shared in JBS bug and the related code, it is easy to find the root cause of it.
> 
> 
> [0.133s][info][gc] GC(0) Concurrent reset after collect (unload classes) 0.033ms
> [0.135s][info][gc] Trigger: Learning 2 of 5. Free (3958K) is below initial threshold (7167K)
> [0.135s][info][gc] Failed to allocate Shared, 128K
> [0.137s][info][gc] Trigger: Handle Allocation Failure
> [0.148s][info][gc] GC(2) Degenerated GC upgrading to Full GC
> [0.167s][info][gc] GC(2) Pause Degenerated GC (Outside of Cycle) 5M->1M(10M) 30.323ms
> 
> 
> At 0.135s, a concurrent cycle was triggered: `[0.135s][info][gc] Trigger: Learning 2 of 5.`, meanwhile there was allocation failure causing degen: `[0.135s][info][gc] Failed to allocate Shared, 128K`.
> In the implementation of ShenandoahControlThread::service_concurrent_normal_cycle, it checks if there degen or cancellation before starting the concurrent cycle and return w/o any gc log, which causes the missing GCID 1 in the GC log.
> 
> Since technically it is not a bug, to fix the potential failure of test `gc/logging/TestGCId` I'll add one line code to print GC log like "[0.135s][info][gc] GC(1) Cancelled"
> 
> ### Test
> - [x] gc/logging/TestGCId
> - [x] hotspot_gc_shenandoah

Thanks all for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24856#issuecomment-2829060545

From xpeng at openjdk.org  Thu Apr 24 23:26:56 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Thu, 24 Apr 2025 23:26:56 GMT
Subject: Integrated: 8354431: gc/logging/TestGCId fails on Shenandoah
In-Reply-To: <XZsYbrfIVILjrfmoOlS7soVxoFrSVCeEPmfeRBLvJR0=.6ddd8637-8a0f-488a-b980-27fda1eb5da1@github.com>
References: <XZsYbrfIVILjrfmoOlS7soVxoFrSVCeEPmfeRBLvJR0=.6ddd8637-8a0f-488a-b980-27fda1eb5da1@github.com>
Message-ID: <atErjd1NRocZi2N6RdTSMkdWTBWIzELWrOGxK2wsfAI=.fa6d8ee5-fafb-4b50-8b85-5c5add241f63@github.com>

On Thu, 24 Apr 2025 17:41:52 GMT, Xiaolong Peng <xpeng at openjdk.org> wrote:

> I can't reproduce the issue in Linux, but based on the gc log shared in JBS bug and the related code, it is easy to find the root cause of it.
> 
> 
> [0.133s][info][gc] GC(0) Concurrent reset after collect (unload classes) 0.033ms
> [0.135s][info][gc] Trigger: Learning 2 of 5. Free (3958K) is below initial threshold (7167K)
> [0.135s][info][gc] Failed to allocate Shared, 128K
> [0.137s][info][gc] Trigger: Handle Allocation Failure
> [0.148s][info][gc] GC(2) Degenerated GC upgrading to Full GC
> [0.167s][info][gc] GC(2) Pause Degenerated GC (Outside of Cycle) 5M->1M(10M) 30.323ms
> 
> 
> At 0.135s, a concurrent cycle was triggered: `[0.135s][info][gc] Trigger: Learning 2 of 5.`, meanwhile there was allocation failure causing degen: `[0.135s][info][gc] Failed to allocate Shared, 128K`.
> In the implementation of ShenandoahControlThread::service_concurrent_normal_cycle, it checks if there degen or cancellation before starting the concurrent cycle and return w/o any gc log, which causes the missing GCID 1 in the GC log.
> 
> Since technically it is not a bug, to fix the potential failure of test `gc/logging/TestGCId` I'll add one line code to print GC log like "[0.135s][info][gc] GC(1) Cancelled"
> 
> ### Test
> - [x] gc/logging/TestGCId
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 8a39f07d
Author:    Xiaolong Peng <xpeng at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a39f07d07f8c4e30dc29b14f28e33c9d8e2e65f
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8354431: gc/logging/TestGCId fails on Shenandoah

Reviewed-by: wkemper, phh

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

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

From ysr at openjdk.org  Fri Apr 25 00:37:15 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 25 Apr 2025 00:37:15 GMT
Subject: RFR: 8348400: GenShen:
 assert(ShenandoahHeap::heap()->is_full_gc_in_progress() ||
 (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity
 #
In-Reply-To: <7mis3faNstlnIBrm12WrdwXQx3IRqAJj9IBXA1c2xqI=.ce0830d0-1f19-4d95-9f23-9a01b0c1a2ec@github.com>
References: <7mis3faNstlnIBrm12WrdwXQx3IRqAJj9IBXA1c2xqI=.ce0830d0-1f19-4d95-9f23-9a01b0c1a2ec@github.com>
Message-ID: <1egMTu-HFjB_DWNXc_ZD2VxvSwL0IQ39UH7_xTZuWkE=.95a85912-83c5-4cec-849a-ffa0d9f33bd5@github.com>

On Wed, 23 Apr 2025 23:41:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict caused by `SIZE_FORMAT -> %zu` change.

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/184#pullrequestreview-2792768026

From shade at openjdk.org  Fri Apr 25 15:23:34 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 25 Apr 2025 15:23:34 GMT
Subject: RFR: 8355617: Remove historical debug_only macro in favor of
 DEBUG_ONLY
Message-ID: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>

I noticed in `macros.hpp`:


#ifdef ASSERT
#define DEBUG_ONLY(code) code
#define NOT_DEBUG(code)
#define NOT_DEBUG_RETURN /*next token must be ;*/
// Historical.
#define debug_only(code) code
#else // ASSERT


There are 350+ instances of `debug_only`, and 1600+ instances of `DEBUG_ONLY`. We can cleanup `debug_only` and rewrite all uses to "DEBUG_ONLY". 

I think we can do this in one shot. This was a mechanical rename. I have looked through the `grep -R debug_only src/ | nl`, and there are no hits anymore.

Additional testing:
 - [ ] GHA

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

Commit messages:
 - Fix

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

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

From wkemper at openjdk.org  Fri Apr 25 16:03:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 25 Apr 2025 16:03:11 GMT
Subject: Integrated: 8348400: GenShen:
 assert(ShenandoahHeap::heap()->is_full_gc_in_progress() ||
 (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity
 #
In-Reply-To: <7mis3faNstlnIBrm12WrdwXQx3IRqAJj9IBXA1c2xqI=.ce0830d0-1f19-4d95-9f23-9a01b0c1a2ec@github.com>
References: <7mis3faNstlnIBrm12WrdwXQx3IRqAJj9IBXA1c2xqI=.ce0830d0-1f19-4d95-9f23-9a01b0c1a2ec@github.com>
Message-ID: <uXsQlobwj7OWAzfRLKaQZAOA4n0kQK2Nbct_yaMeg-k=.8f893041-4bd3-454f-af7f-25c8d9decbfb@github.com>

On Wed, 23 Apr 2025 23:41:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict caused by `SIZE_FORMAT -> %zu` change.

This pull request has now been integrated.

Changeset: dd5a1d7a
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/dd5a1d7a0a72caf5680bad689580fb4b283c861c
Stats:     63 lines in 2 files changed: 48 ins; 3 del; 12 mod

8348400: GenShen: assert(ShenandoahHeap::heap()->is_full_gc_in_progress() || (used_regions_size() <= _max_capacity)) failed: Cannot use more than capacity #

Reviewed-by: kdnilsen, ysr
Backport-of: 5672a934fa1b0b42ae9bb39b31579a27e3332c28

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

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

From kdnilsen at openjdk.org  Fri Apr 25 16:55:54 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 25 Apr 2025 16:55:54 GMT
Subject: RFR: 8355340: GenShen: Remove unneeded log messages related to
 remembered set write table
In-Reply-To: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
References: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
Message-ID: <7p8Fu1-NV6DaANACeWuUkSA3efOPCihlHenFYGlGRbo=.0058e11f-bca1-4d71-9a55-c9a460a68f78@github.com>

On Wed, 23 Apr 2025 00:54:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Remove unneeded log messages related to processing of the remembered set write card table.

Wonder if I should have just changes these to log_debug?

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

PR Comment: https://git.openjdk.org/jdk/pull/24809#issuecomment-2830929313

From kdnilsen at openjdk.org  Fri Apr 25 17:22:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 25 Apr 2025 17:22:22 GMT
Subject: RFR: 8355336: GenShen: Resume Old GC even with back-to-back Young
 GC triggers [v2]
In-Reply-To: <Szc4G3tgDn8HMc4fAWx1nc3TDB60Mwru4PMS337zE6g=.b633bef0-f770-40f7-9794-9b2a0224d255@github.com>
References: <Szc4G3tgDn8HMc4fAWx1nc3TDB60Mwru4PMS337zE6g=.b633bef0-f770-40f7-9794-9b2a0224d255@github.com>
Message-ID: <J70j6r6gMn0sFND0Uu15EiCdDch-3Av-Z16bjUTxcMk=.81dae81d-9266-43ea-9383-5ffd0d51153e@github.com>

> Allow old-gen concurrent marking cycles to get their full time slice even when young-gc is triggered back-to-back.

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

  Fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24810/files
  - new: https://git.openjdk.org/jdk/pull/24810/files/322e2eca..eaeb4efc

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

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

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

From kdnilsen at openjdk.org  Fri Apr 25 17:22:22 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 25 Apr 2025 17:22:22 GMT
Subject: RFR: 8355336: GenShen: Resume Old GC even with back-to-back Young
 GC triggers [v2]
In-Reply-To: <BAWUAWgVSCpNgOMKvZU41tDJKJgW3jQuLkM6A5RLI_g=.b109af81-f30c-4f2f-8cb8-f4752d1c4b66@github.com>
References: <Szc4G3tgDn8HMc4fAWx1nc3TDB60Mwru4PMS337zE6g=.b633bef0-f770-40f7-9794-9b2a0224d255@github.com>
 <BAWUAWgVSCpNgOMKvZU41tDJKJgW3jQuLkM6A5RLI_g=.b109af81-f30c-4f2f-8cb8-f4752d1c4b66@github.com>
Message-ID: <53UTjjKs1cwqSvkgKOUakj8Rvubnv8_FsBsTXqf_ym0=.06a7ca11-f267-47fe-b2ab-90039addc3f4@github.com>

On Wed, 23 Apr 2025 16:45:24 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indentation
>
> src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp line 80:
> 
>> 78:           _old_heuristics->cancel_trigger_request();
>> 79:         } else if (start_young_cycle()) {
>> 80:             log_debug(gc)("Heuristics request for young collection accepted");
> 
> Indentation looks a little off here.

Thanks.  I've fixed this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24810#discussion_r2060618736

From stefank at openjdk.org  Fri Apr 25 17:22:49 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 25 Apr 2025 17:22:49 GMT
Subject: RFR: 8355617: Remove historical debug_only macro in favor of
 DEBUG_ONLY
In-Reply-To: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
References: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
Message-ID: <XezPZTsXx_0WFuiBcIurTws56N4g3WRBD8BQFqKkYz8=.8996f516-1f94-419e-a6e4-11a43e44cb81@github.com>

On Fri, 25 Apr 2025 15:17:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed in `macros.hpp`:
> 
> 
> #ifdef ASSERT
> #define DEBUG_ONLY(code) code
> #define NOT_DEBUG(code)
> #define NOT_DEBUG_RETURN /*next token must be ;*/
> // Historical.
> #define debug_only(code) code
> #else // ASSERT
> 
> 
> There are 350+ instances of `debug_only`, and 1600+ instances of `DEBUG_ONLY`. We can cleanup `debug_only` and rewrite all uses to `DEBUG_ONLY`. 
> 
> I think we can do this in one shot. This was a mechanical rename. I have looked through the `grep -R debug_only src/ | nl`, and there are no hits anymore.
> 
> Additional testing:
>  - [ ] GHA

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24879#pullrequestreview-2794815649

From kbarrett at openjdk.org  Fri Apr 25 18:06:14 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 25 Apr 2025 18:06:14 GMT
Subject: RFR: 8355617: Remove historical debug_only macro in favor of
 DEBUG_ONLY
In-Reply-To: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
References: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
Message-ID: <wDWeiSIaMtDE-vZf8EDEgW9L64dd3hBMtXQd0hkjBk4=.cd4289d3-a19e-4dc5-aa90-8113dee2ed09@github.com>

On Fri, 25 Apr 2025 15:17:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed in `macros.hpp`:
> 
> 
> #ifdef ASSERT
> #define DEBUG_ONLY(code) code
> #define NOT_DEBUG(code)
> #define NOT_DEBUG_RETURN /*next token must be ;*/
> // Historical.
> #define debug_only(code) code
> #else // ASSERT
> 
> 
> There are 350+ instances of `debug_only`, and 1600+ instances of `DEBUG_ONLY`. We can cleanup `debug_only` and rewrite all uses to `DEBUG_ONLY`. 
> 
> I think we can do this in one shot. This was a mechanical rename. I have looked through the `grep -R debug_only src/ | nl`, and there are no hits anymore.
> 
> Additional testing:
>  - [x] GHA

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24879#pullrequestreview-2794899494

From ysr at openjdk.org  Fri Apr 25 18:45:50 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 25 Apr 2025 18:45:50 GMT
Subject: RFR: 8355340: GenShen: Remove unneeded log messages related to
 remembered set write table
In-Reply-To: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
References: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
Message-ID: <1mUVuO7AJv3bl-GAOaiElHe86ioMwYFS9IP6CTCUn6c=.a3b3f2c4-e57b-46aa-8d67-4372eed5eabb@github.com>

On Wed, 23 Apr 2025 00:54:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Remove unneeded log messages related to processing of the remembered set write card table.

OK to remove. Alternatively, could make them debug or trace level. (Or whatever is the most verbose level: i always confuse myself between trace and debug.) Just looked it up: trace is finest; you could may be make it `log_trace(...)` in each case, if you want.

Whatever makes sense.

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24809#pullrequestreview-2794985272

From wkemper at openjdk.org  Fri Apr 25 19:19:51 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 25 Apr 2025 19:19:51 GMT
Subject: RFR: 8355340: GenShen: Remove unneeded log messages related to
 remembered set write table
In-Reply-To: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
References: <sVCLJRAgz0HMiPQxxLJdoN4yLP9DRO5DgEYuZ96owxA=.b0f01296-c1d4-4587-af0d-1d073c9453e3@github.com>
Message-ID: <mEsuK6eLp70Uq5D8DVFC5g4UCrYE2u1Dpb7BdCGs1Js=.a2a0d769-8eb6-4a37-8141-0afcb5b3ca4d@github.com>

On Wed, 23 Apr 2025 00:54:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Remove unneeded log messages related to processing of the remembered set write card table.

Do you want to keep these messages, but change `log_info` to `log_develop_debug`? `log_develop_debug` would remove them entirely from `product` builds.

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

PR Review: https://git.openjdk.org/jdk/pull/24809#pullrequestreview-2795059743

From wkemper at openjdk.org  Fri Apr 25 20:16:51 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 25 Apr 2025 20:16:51 GMT
Subject: RFR: 8355336: GenShen: Resume Old GC even with back-to-back Young
 GC triggers [v2]
In-Reply-To: <J70j6r6gMn0sFND0Uu15EiCdDch-3Av-Z16bjUTxcMk=.81dae81d-9266-43ea-9383-5ffd0d51153e@github.com>
References: <Szc4G3tgDn8HMc4fAWx1nc3TDB60Mwru4PMS337zE6g=.b633bef0-f770-40f7-9794-9b2a0224d255@github.com>
 <J70j6r6gMn0sFND0Uu15EiCdDch-3Av-Z16bjUTxcMk=.81dae81d-9266-43ea-9383-5ffd0d51153e@github.com>
Message-ID: <1nSaDMoIA3N7ijkIaglsp_7sNein5jKh3BMNUEwYM9g=.7e515645-99cc-456f-a6e1-1d9967de579e@github.com>

On Fri, 25 Apr 2025 17:22:22 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Allow old-gen concurrent marking cycles to get their full time slice even when young-gc is triggered back-to-back.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indentation

Marked as reviewed by wkemper (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24810#pullrequestreview-2795190699

From wkemper at openjdk.org  Fri Apr 25 20:33:42 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 25 Apr 2025 20:33:42 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card tables
Message-ID: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>

Conflict in risc-v code, trivial resolution.

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

Commit messages:
 - 8343468: GenShen: Enable relocation of remembered set card tables

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/186/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=186&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343468
  Stats: 320 lines in 25 files changed: 183 ins; 87 del; 50 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/186.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/186/head:pull/186

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

From wkemper at openjdk.org  Fri Apr 25 20:38:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 25 Apr 2025 20:38:39 GMT
Subject: Integrated: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
Message-ID: <RiLS3vGBfgoRcMiAd1KAtmmyzecP3xPVAV-09EmIbzQ=.0bbba6de-6efb-4a14-813f-cf379e6941f2@github.com>

Clean backport.

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

Commit messages:
 - Backport e8bcedb09b0e5eeb77bf1dc3a87bb61d7a5e8404

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/187/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=187&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/shenandoah-jdk21u/pull/187.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/187/head:pull/187

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

From wkemper at openjdk.org  Fri Apr 25 20:38:40 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 25 Apr 2025 20:38:40 GMT
Subject: Integrated: 8354452: Shenandoah: Enforce range checks on parameters
 controlling heuristic sleep times
In-Reply-To: <RiLS3vGBfgoRcMiAd1KAtmmyzecP3xPVAV-09EmIbzQ=.0bbba6de-6efb-4a14-813f-cf379e6941f2@github.com>
References: <RiLS3vGBfgoRcMiAd1KAtmmyzecP3xPVAV-09EmIbzQ=.0bbba6de-6efb-4a14-813f-cf379e6941f2@github.com>
Message-ID: <zsAeTVCzA5MIeekMuW2mQo9afQ_qVgO_TJ3-i2opV_o=.331b19f0-3b80-4760-b73d-06c404128214@github.com>

On Fri, 25 Apr 2025 20:30:48 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 9fafafaa
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/9fafafaac62045fb0b86a86c96adbea9912c42a8
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8354452: Shenandoah: Enforce range checks on parameters controlling heuristic sleep times

Backport-of: e8bcedb09b0e5eeb77bf1dc3a87bb61d7a5e8404

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

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

From wkemper at openjdk.org  Fri Apr 25 20:45:22 2025
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 25 Apr 2025 20:45:22 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
Message-ID: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>

Add a test case for `-XX:+UseCompactObjectHeaders`, increase pressure on old generation. I ran the test (which includes a compact object headers case now) fifty times without failure.

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

Commit messages:
 - Add test case for compact object headers, increase pressure on old generation

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

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

From ysr at openjdk.org  Fri Apr 25 23:50:51 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 25 Apr 2025 23:50:51 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
Message-ID: <U1dFLlNRVAxMscj38GpvCOX2oW0nEK08ZnjYN5-OSDA=.db21b6f3-cecc-4740-b4a6-c9189748be3b@github.com>

On Fri, 25 Apr 2025 20:40:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Add a test case for `-XX:+UseCompactObjectHeaders`, increase pressure on old generation. I ran the test (which includes a compact object headers case now) fifty times without failure.

Looks fine but left some thoughts, although you probably don't want to change anything if this setting is working to induce the behavior you want to test.

A whitebox test may be better in the future rather than having to tweak test settings to induce the right behavior to trigger old growth.

test/hotspot/jtreg/gc/shenandoah/generational/TestOldGrowthTriggers.java line 60:

> 58:                 int replaceIndex = r.nextInt(ArraySize);
> 59:                 int deriveIndex = r.nextInt(ArraySize);
> 60:                 switch (i & 0x3) {

...otherwise could you just do (i & 0x1) here and change cases 2 & 3 to cases 0 & 1?

test/hotspot/jtreg/gc/shenandoah/generational/TestOldGrowthTriggers.java line 68:

> 66:                         // 50% chance of creating garbage
> 67:                         array[replaceIndex] = array[replaceIndex].min(array[deriveIndex]);
> 68:                         break;

Could you have left this in place & reduced the heap size of the UseCompactHeaders test to half the current setting to induce the trigger?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24888#pullrequestreview-2795532213
PR Review Comment: https://git.openjdk.org/jdk/pull/24888#discussion_r2061035944
PR Review Comment: https://git.openjdk.org/jdk/pull/24888#discussion_r2061034174

From gziemski at openjdk.org  Sat Apr 26 12:42:59 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Sat, 26 Apr 2025 12:42:59 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v9]
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: <ZoEe7_pJFmuzqdzLYLfp8cNtU6O-n2GnFIR_rKXIcEY=.eb2ad70d-db4d-485f-a1ec-e92ae0f8eb32@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 incrementally with one additional commit since the last revision:

  after merge fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24634/files
  - new: https://git.openjdk.org/jdk/pull/24634/files/dc030a20..a86ef29b

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

  Stats: 2 lines in 1 file 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 jwaters at openjdk.org  Sun Apr 27 15:06:46 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 27 Apr 2025 15:06:46 GMT
Subject: RFR: 8355617: Remove historical debug_only macro in favor of
 DEBUG_ONLY
In-Reply-To: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
References: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
Message-ID: <rRsxGwPdTfrXcYAL6MtoCdnIxy2kQjUY1f67lFZLqIM=.2115b0a8-ff1d-461c-b961-071e09c15b0a@github.com>

On Fri, 25 Apr 2025 15:17:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed in `macros.hpp`:
> 
> 
> #ifdef ASSERT
> #define DEBUG_ONLY(code) code
> #define NOT_DEBUG(code)
> #define NOT_DEBUG_RETURN /*next token must be ;*/
> // Historical.
> #define debug_only(code) code
> #else // ASSERT
> 
> 
> There are 350+ instances of `debug_only`, and 1600+ instances of `DEBUG_ONLY`. We can cleanup `debug_only` and rewrite all uses to `DEBUG_ONLY`. 
> 
> I think we can do this in one shot. This was a mechanical rename. I have looked through the `grep -R debug_only src/ | nl`, and there are no hits anymore.
> 
> Additional testing:
>  - [x] GHA

Looks good

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24879#pullrequestreview-2797664795

From kdnilsen at openjdk.org  Sun Apr 27 20:12:54 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 27 Apr 2025 20:12:54 GMT
Subject: Integrated: 8355336: GenShen: Resume Old GC even with back-to-back
 Young GC triggers
In-Reply-To: <Szc4G3tgDn8HMc4fAWx1nc3TDB60Mwru4PMS337zE6g=.b633bef0-f770-40f7-9794-9b2a0224d255@github.com>
References: <Szc4G3tgDn8HMc4fAWx1nc3TDB60Mwru4PMS337zE6g=.b633bef0-f770-40f7-9794-9b2a0224d255@github.com>
Message-ID: <KcoY9ojH2jcOXb1P5SLv-YUA9y16OIXuIcC66D3nKZ8=.e74b460e-a479-4257-b593-daf266f62fa6@github.com>

On Wed, 23 Apr 2025 00:57:53 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Allow old-gen concurrent marking cycles to get their full time slice even when young-gc is triggered back-to-back.

This pull request has now been integrated.

Changeset: cd6f0d19
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd6f0d19d5da03eafde68142528c0f85d783cbea
Stats:     26 lines in 3 files changed: 8 ins; 14 del; 4 mod

8355336: GenShen: Resume Old GC even with back-to-back Young GC triggers

Reviewed-by: wkemper

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

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

From mbaesken at openjdk.org  Mon Apr 28 07:06:56 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 28 Apr 2025 07:06:56 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
Message-ID: <oMr-Paz-5DJfUgBU7M_PbFFFbVMA2jUzs63eJDNJ_3Q=.17c865ab-6ab5-412d-80f7-4da5543f15a3@github.com>

On Fri, 25 Apr 2025 20:40:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Add a test case for `-XX:+UseCompactObjectHeaders`, increase pressure on old generation. I ran the test (which includes a compact object headers case now) fifty times without failure.

Hi @earthling-amzn  I added your PR to our build/test queue, let's see if the issues we observed go away on all platforms!

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

PR Comment: https://git.openjdk.org/jdk/pull/24888#issuecomment-2834179698

From shade at openjdk.org  Mon Apr 28 08:46:10 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Apr 2025 08:46:10 GMT
Subject: RFR: 8355617: Remove historical debug_only macro in favor of
 DEBUG_ONLY
In-Reply-To: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
References: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
Message-ID: <-qi-IEW4FBKxla0_NspwEjOUc5F-nxGbVMPhFSA0IyQ=.01d6456f-0c73-437a-a860-5b9dbca2c1d5@github.com>

On Fri, 25 Apr 2025 15:17:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed in `macros.hpp`:
> 
> 
> #ifdef ASSERT
> #define DEBUG_ONLY(code) code
> #define NOT_DEBUG(code)
> #define NOT_DEBUG_RETURN /*next token must be ;*/
> // Historical.
> #define debug_only(code) code
> #else // ASSERT
> 
> 
> There are 350+ instances of `debug_only`, and 1600+ instances of `DEBUG_ONLY`. We can cleanup `debug_only` and rewrite all uses to `DEBUG_ONLY`. 
> 
> I think we can do this in one shot. This was a mechanical rename. I have looked through the `grep -R debug_only src/ | nl`, and there are no hits anymore.
> 
> Additional testing:
>  - [x] GHA

Thanks for reviews! I re-merged with current master locally. There were no conflicts, and no backsliding of `debug_only` either. Light testing (`hotspot:tier1`) still passes. So I think we are good to go. Here goes:

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

PR Comment: https://git.openjdk.org/jdk/pull/24879#issuecomment-2834467628

From shade at openjdk.org  Mon Apr 28 08:46:11 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 28 Apr 2025 08:46:11 GMT
Subject: Integrated: 8355617: Remove historical debug_only macro in favor of
 DEBUG_ONLY
In-Reply-To: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
References: <acJbSWcTjQljuni0fKwChHkSCMz9JL5514TBRxZ0k88=.45fcac20-02d9-4943-85e9-7d39b8a04b38@github.com>
Message-ID: <QtqqVFaDBk-3v3MQobhcjvmmhzEEh5vBn8SoLVzmBV0=.799bd086-c339-4f81-b582-6489df642a98@github.com>

On Fri, 25 Apr 2025 15:17:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I noticed in `macros.hpp`:
> 
> 
> #ifdef ASSERT
> #define DEBUG_ONLY(code) code
> #define NOT_DEBUG(code)
> #define NOT_DEBUG_RETURN /*next token must be ;*/
> // Historical.
> #define debug_only(code) code
> #else // ASSERT
> 
> 
> There are 350+ instances of `debug_only`, and 1600+ instances of `DEBUG_ONLY`. We can cleanup `debug_only` and rewrite all uses to `DEBUG_ONLY`. 
> 
> I think we can do this in one shot. This was a mechanical rename. I have looked through the `grep -R debug_only src/ | nl`, and there are no hits anymore.
> 
> Additional testing:
>  - [x] GHA

This pull request has now been integrated.

Changeset: db6fa592
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db6fa5923cd0394dfb44c7e46c3e7ccc102a933a
Stats:     371 lines in 119 files changed: 0 ins; 3 del; 368 mod

8355617: Remove historical debug_only macro in favor of DEBUG_ONLY

Reviewed-by: stefank, kbarrett, jwaters

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

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

From stefank at openjdk.org  Mon Apr 28 11:21:48 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 28 Apr 2025 11:21:48 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v9]
In-Reply-To: <ZoEe7_pJFmuzqdzLYLfp8cNtU6O-n2GnFIR_rKXIcEY=.eb2ad70d-db4d-485f-a1ec-e92ae0f8eb32@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <ZoEe7_pJFmuzqdzLYLfp8cNtU6O-n2GnFIR_rKXIcEY=.eb2ad70d-db4d-485f-a1ec-e92ae0f8eb32@github.com>
Message-ID: <Nq0nbDTUj3VzCylshK4-8Of0Tf8OLZE1f-cEhAhADMM=.7c2b6aaf-6cdc-46b9-8ff4-c134c9187b41@github.com>

On Sat, 26 Apr 2025 12:42:59 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:
> 
>   after merge fixes

You add a the unnecessary false / ExecMem argument again, thought at this point I just want to get this pushed, so consider this reviewed.

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

Marked as reviewed by stefank (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24634#pullrequestreview-2798952947

From kdnilsen at openjdk.org  Mon Apr 28 13:28:47 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 28 Apr 2025 13:28:47 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
Message-ID: <FG2iEoETxkaoyk8VEl1Jaj6cltlId4S2WoTMpD8SC2s=.2608e6ea-91a9-49f8-bc92-b55af0f2056a@github.com>

On Fri, 25 Apr 2025 20:40:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Add a test case for `-XX:+UseCompactObjectHeaders`, increase pressure on old generation. I ran the test (which includes a compact object headers case now) fifty times without failure.

Changes look good to me.

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24888#pullrequestreview-2799301235

From gziemski at openjdk.org  Mon Apr 28 14:40:13 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 28 Apr 2025 14:40:13 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v10]
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: <-_qbKLmyeKkHIkIEWrtP5GIdiAHGdeRTJyumso-yuWU=.8324abfb-89c1-45fe-b6ab-a153e09c2313@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 11 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - after merge fixes
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - remove last default argument (found by Stefan)
 - fix build break
 - fix build break
 - ... and 1 more: https://git.openjdk.org/jdk/compare/f3ecba2c...979f26ff

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24634/files
  - new: https://git.openjdk.org/jdk/pull/24634/files/a86ef29b..979f26ff

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

  Stats: 10020 lines in 297 files changed: 7151 ins; 1271 del; 1598 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 28 14:40:14 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Mon, 28 Apr 2025 14:40:14 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v10]
In-Reply-To: <Nq0nbDTUj3VzCylshK4-8Of0Tf8OLZE1f-cEhAhADMM=.7c2b6aaf-6cdc-46b9-8ff4-c134c9187b41@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <ZoEe7_pJFmuzqdzLYLfp8cNtU6O-n2GnFIR_rKXIcEY=.eb2ad70d-db4d-485f-a1ec-e92ae0f8eb32@github.com>
 <Nq0nbDTUj3VzCylshK4-8Of0Tf8OLZE1f-cEhAhADMM=.7c2b6aaf-6cdc-46b9-8ff4-c134c9187b41@github.com>
Message-ID: <IuBONknbFpDhcqrn22fqdHlH3tq-5UIlXm3dXbbJJHI=.e82f0937-80e1-44e8-b747-b2005228db10@github.com>

On Mon, 28 Apr 2025 11:19:02 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> You add a the unnecessary false / ExecMem argument again, thought at this point I just want to get this pushed, so consider this reviewed.

Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/24634#issuecomment-2835461110

From wkemper at openjdk.org  Mon Apr 28 21:20:47 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 28 Apr 2025 21:20:47 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <oMr-Paz-5DJfUgBU7M_PbFFFbVMA2jUzs63eJDNJ_3Q=.17c865ab-6ab5-412d-80f7-4da5543f15a3@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
 <oMr-Paz-5DJfUgBU7M_PbFFFbVMA2jUzs63eJDNJ_3Q=.17c865ab-6ab5-412d-80f7-4da5543f15a3@github.com>
Message-ID: <h_1YUYgXsb1u2CKLQWG_U146mQI8JhKGGmCKW8v79uA=.cbb612ba-1162-408f-810f-354c1e111014@github.com>

On Mon, 28 Apr 2025 07:04:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Add a test case for `-XX:+UseCompactObjectHeaders`, increase pressure on old generation. I ran the test (which includes a compact object headers case now) fifty times without failure.
>
> Hi @earthling-amzn  I added your PR to our build/test queue, let's see if the issues we observed go away on all platforms!

@MBaesken - thank you! Please let us know how it goes. 

@ysramakrishna - I wanted to increase pressure specifically on the old generation. I'm not sure reducing the heap size alone would do that. As you point out, the cases in the switch statement do look a bit silly now. I'll make the change you suggested.

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

PR Comment: https://git.openjdk.org/jdk/pull/24888#issuecomment-2836708777

From wkemper at openjdk.org  Mon Apr 28 21:42:24 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 28 Apr 2025 21:42:24 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v2]
In-Reply-To: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
References: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
Message-ID: <i5aebXrp1_uJQW7TKzMXk2dpi1u8rF14agvQ-Foz5bY=.feafea06-c6cb-464e-aba4-e0c46f4ac8ef@github.com>

> Conflict in risc-v code, trivial resolution.

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

  8351456: Build failure with --disable-jvm-feature-shenandoahgc after 8343468
  
  Reviewed-by: kvn, syan

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/186/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/186/files/83032cba..4fefb753

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

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

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

From wkemper at openjdk.org  Mon Apr 28 22:24:15 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 28 Apr 2025 22:24:15 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v3]
In-Reply-To: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
References: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
Message-ID: <krOoBkLf5LPsSaHML71X2oaDAXkXJTM2VoZpC2a-xsg=.097ae6c0-9287-4c9f-9a50-41f895cd63ee@github.com>

> Conflict in risc-v code, trivial resolution.

William Kemper has updated the pull request incrementally with two additional commits since the last revision:

 - Fix risc-v build (missing some parts for genshen in 21 backport)
 - Fix 32-bit build

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/186/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/186/files/4fefb753..04bd7778

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

  Stats: 39 lines in 3 files changed: 17 ins; 8 del; 14 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/186.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/186/head:pull/186

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

From wkemper at openjdk.org  Mon Apr 28 22:26:00 2025
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 28 Apr 2025 22:26:00 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled [v2]
In-Reply-To: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
Message-ID: <BKYu3n1UV4MwRi2TzJgtHFJFDqgtLVX15C7awvI50YY=.b6b24e3f-1a9e-427f-b991-dc5fc0158614@github.com>

> Add a test case for `-XX:+UseCompactObjectHeaders`, increase pressure on old generation. I ran the test (which includes a compact object headers case now) fifty times without failure.

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

  Clarify cases with comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24888/files
  - new: https://git.openjdk.org/jdk/pull/24888/files/9c991cfa..70b36ac5

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

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

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

From wkemper at openjdk.org  Tue Apr 29 00:02:20 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 29 Apr 2025 00:02:20 GMT
Subject: RFR: 8355789: GenShen: assert(_degen_point ==
 ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of
 Cycle
Message-ID: <eldRj6x8c_ZOWmXXtfHUozFy3rtBVf7zGM_3zfnOlAE=.ab42ee08-632d-4c50-848f-f65a6027e63d@github.com>

When old generation marking is cancelled to run a young collection. we still set a `_degen_point ` for reasons that became vestigial after [JDK-8349094](https://bugs.openjdk.org/browse/JDK-8349094). When old marking is cancelled, the `_degen_point` should only be set if the marking was cancelled because of an allocation failure (and it should still only be set to "outside of cycle"). The following sequence could lead to this assertion failure:
1. Control thread is marking old
2. Young GC preempts it
3. Control thread sets the degen point because the old GC was "cancelled"
4. The concurrent young GC fails and attempts to set a degenerated point
5. This trips the assert because we already (incorrectly) set the degen point in `3`.

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

Commit messages:
 - Only set degeneration point for allocation failures during old marking

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

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

From wkemper at openjdk.org  Tue Apr 29 00:03:52 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 29 Apr 2025 00:03:52 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v4]
In-Reply-To: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
References: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
Message-ID: <JkqgaXVo3UXNL81WvIvpHYWvT7UnaYhMu7UH5JXwXTs=.92bc38ae-1edb-4025-a334-9de352f83272@github.com>

> Conflict in risc-v code, trivial resolution.

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

  Revert references to method that hasn't been backported

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk21u/pull/186/files
  - new: https://git.openjdk.org/shenandoah-jdk21u/pull/186/files/04bd7778..56565017

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

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

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

From mbaesken at openjdk.org  Tue Apr 29 07:41:47 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Apr 2025 07:41:47 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <h_1YUYgXsb1u2CKLQWG_U146mQI8JhKGGmCKW8v79uA=.cbb612ba-1162-408f-810f-354c1e111014@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
 <oMr-Paz-5DJfUgBU7M_PbFFFbVMA2jUzs63eJDNJ_3Q=.17c865ab-6ab5-412d-80f7-4da5543f15a3@github.com>
 <h_1YUYgXsb1u2CKLQWG_U146mQI8JhKGGmCKW8v79uA=.cbb612ba-1162-408f-810f-354c1e111014@github.com>
Message-ID: <A7uJv2S_xHnx2RWajqZ79drsBKIsEHwGLOuPVS-QFMY=.7914d187-ca22-4532-b7b3-9a900cb4b032@github.com>

On Mon, 28 Apr 2025 21:18:31 GMT, William Kemper <wkemper at openjdk.org> wrote:

> thank you! Please let us know how it goes.

Unfortunately, not so good .
On darwin x86_64  fastdebug,  

gc/shenandoah/generational/TestOldGrowthTriggers.java

triggers now this crash/assert  


#  Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-macos_x86_64-dbg/jdk/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp:607), pid=58469, tid=18179
#  assert(_degen_point == ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of Cycle

Stack: [0x000070000fc5b000,0x000070000fd5b000],  sp=0x000070000fd5aae0,  free space=1022k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.dylib+0x1576749]  VMError::report(outputStream*, bool)+0x1ef9  (shenandoahGenerationalControlThread.cpp:607)
V  [libjvm.dylib+0x157a65b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x60b
V  [libjvm.dylib+0x72bd08]  report_vm_error(char const*, int, char const*, char const*, ...)+0xd8
V  [libjvm.dylib+0x121e75a]  ShenandoahGenerationalControlThread::check_cancellation_or_degen(ShenandoahGC::ShenandoahDegenPoint)+0x14a
V  [libjvm.dylib+0x121e455]  ShenandoahGenerationalControlThread::service_concurrent_cycle(ShenandoahGeneration*, GCCause::Cause, bool)+0x165
V  [libjvm.dylib+0x121cd72]  ShenandoahGenerationalControlThread::run_gc_cycle(ShenandoahGenerationalControlThread::ShenandoahGCRequest const&)+0x1a2
V  [libjvm.dylib+0x121c8b2]  ShenandoahGenerationalControlThread::run_service()+0x142
V  [libjvm.dylib+0x6a798b]  ConcurrentGCThread::run()+0x1b
V  [libjvm.dylib+0x14bfa5c]  Thread::call_run()+0xbc
V  [libjvm.dylib+0x1060ff7]  thread_native_entry(Thread*)+0x137
C  [libsystem_pthread.dylib+0x618b]  _pthread_start+0x63
C  [libsystem_pthread.dylib+0x1ae3]  thread_start+0xf

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

PR Comment: https://git.openjdk.org/jdk/pull/24888#issuecomment-2837812285

From mbaesken at openjdk.org  Tue Apr 29 14:29:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 29 Apr 2025 14:29:49 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <A7uJv2S_xHnx2RWajqZ79drsBKIsEHwGLOuPVS-QFMY=.7914d187-ca22-4532-b7b3-9a900cb4b032@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
 <oMr-Paz-5DJfUgBU7M_PbFFFbVMA2jUzs63eJDNJ_3Q=.17c865ab-6ab5-412d-80f7-4da5543f15a3@github.com>
 <h_1YUYgXsb1u2CKLQWG_U146mQI8JhKGGmCKW8v79uA=.cbb612ba-1162-408f-810f-354c1e111014@github.com>
 <A7uJv2S_xHnx2RWajqZ79drsBKIsEHwGLOuPVS-QFMY=.7914d187-ca22-4532-b7b3-9a900cb4b032@github.com>
Message-ID: <_6MD1OrkbiBPcjVkKGXvlH4xGplX11i7L_FAYKXZls8=.1a8d7276-7eac-443c-aa74-a45a3ef65e17@github.com>

On Tue, 29 Apr 2025 07:39:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>Unfortunately, not so good .
>On darwin x86_64 fastdebug,
>
>gc/shenandoah/generational/TestOldGrowthTriggers.java
>
>triggers now this crash/assert

Seems we have for this already
https://bugs.openjdk.org/browse/JDK-8355789
JDK-8355789: GenShen: assert(_degen_point == ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of Cycle

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

PR Comment: https://git.openjdk.org/jdk/pull/24888#issuecomment-2839141827

From gziemski at openjdk.org  Tue Apr 29 16:08:09 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Tue, 29 Apr 2025 16:08:09 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v11]
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: <AumF_58ZTjGP0CSqbGg8sy90TEhbkCdhZQ4oyutXSaw=.baa8a1a7-9a8a-4445-9199-51d14879178f@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 12 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - after merge fixes
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - remove last default argument (found by Stefan)
 - fix build break
 - ... and 2 more: https://git.openjdk.org/jdk/compare/0c27ca4f...6196f061

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24634/files
  - new: https://git.openjdk.org/jdk/pull/24634/files/979f26ff..6196f061

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24634&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24634&range=09-10

  Stats: 1565 lines in 66 files changed: 932 ins; 312 del; 321 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 wkemper at openjdk.org  Tue Apr 29 17:35:45 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 29 Apr 2025 17:35:45 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <_6MD1OrkbiBPcjVkKGXvlH4xGplX11i7L_FAYKXZls8=.1a8d7276-7eac-443c-aa74-a45a3ef65e17@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
 <oMr-Paz-5DJfUgBU7M_PbFFFbVMA2jUzs63eJDNJ_3Q=.17c865ab-6ab5-412d-80f7-4da5543f15a3@github.com>
 <h_1YUYgXsb1u2CKLQWG_U146mQI8JhKGGmCKW8v79uA=.cbb612ba-1162-408f-810f-354c1e111014@github.com>
 <A7uJv2S_xHnx2RWajqZ79drsBKIsEHwGLOuPVS-QFMY=.7914d187-ca22-4532-b7b3-9a900cb4b032@github.com>
 <_6MD1OrkbiBPcjVkKGXvlH4xGplX11i7L_FAYKXZls8=.1a8d7276-7eac-443c-aa74-a45a3ef65e17@github.com>
Message-ID: <grHLK1jUtT8uYjbI61wSN9rmAM_DxP30DwSQi83Dgoc=.c8860e3d-fed9-45e6-9cdf-00de876476c0@github.com>

On Tue, 29 Apr 2025 14:26:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> thank you! Please let us know how it goes.
>> 
>> Unfortunately, not so good .
>> On darwin x86_64  fastdebug,  
>> 
>> gc/shenandoah/generational/TestOldGrowthTriggers.java
>> 
>> triggers now this crash/assert  
>> 
>> 
>> #  Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-macos_x86_64-dbg/jdk/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp:607), pid=58469, tid=18179
>> #  assert(_degen_point == ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of Cycle
>> 
>> Stack: [0x000070000fc5b000,0x000070000fd5b000],  sp=0x000070000fd5aae0,  free space=1022k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.dylib+0x1576749]  VMError::report(outputStream*, bool)+0x1ef9  (shenandoahGenerationalControlThread.cpp:607)
>> V  [libjvm.dylib+0x157a65b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x60b
>> V  [libjvm.dylib+0x72bd08]  report_vm_error(char const*, int, char const*, char const*, ...)+0xd8
>> V  [libjvm.dylib+0x121e75a]  ShenandoahGenerationalControlThread::check_cancellation_or_degen(ShenandoahGC::ShenandoahDegenPoint)+0x14a
>> V  [libjvm.dylib+0x121e455]  ShenandoahGenerationalControlThread::service_concurrent_cycle(ShenandoahGeneration*, GCCause::Cause, bool)+0x165
>> V  [libjvm.dylib+0x121cd72]  ShenandoahGenerationalControlThread::run_gc_cycle(ShenandoahGenerationalControlThread::ShenandoahGCRequest const&)+0x1a2
>> V  [libjvm.dylib+0x121c8b2]  ShenandoahGenerationalControlThread::run_service()+0x142
>> V  [libjvm.dylib+0x6a798b]  ConcurrentGCThread::run()+0x1b
>> V  [libjvm.dylib+0x14bfa5c]  Thread::call_run()+0xbc
>> V  [libjvm.dylib+0x1060ff7]  thread_native_entry(Thread*)+0x137
>> C  [libsystem_pthread.dylib+0x618b]  _pthread_start+0x63
>> C  [libsystem_pthread.dylib+0x1ae3]  thread_start+0xf
>
>>Unfortunately, not so good .
>>On darwin x86_64 fastdebug,
>>
>>gc/shenandoah/generational/TestOldGrowthTriggers.java
>>
>>triggers now this crash/assert
> 
> Seems we have for this already
> https://bugs.openjdk.org/browse/JDK-8355789
> JDK-8355789: GenShen: assert(_degen_point == ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of Cycle

@MBaesken - we have a PR for that assert under review: https://github.com/openjdk/jdk/pull/24940

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

PR Comment: https://git.openjdk.org/jdk/pull/24888#issuecomment-2839687949

From kdnilsen at openjdk.org  Tue Apr 29 17:38:47 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 29 Apr 2025 17:38:47 GMT
Subject: RFR: 8355789: GenShen: assert(_degen_point ==
 ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of
 Cycle
In-Reply-To: <eldRj6x8c_ZOWmXXtfHUozFy3rtBVf7zGM_3zfnOlAE=.ab42ee08-632d-4c50-848f-f65a6027e63d@github.com>
References: <eldRj6x8c_ZOWmXXtfHUozFy3rtBVf7zGM_3zfnOlAE=.ab42ee08-632d-4c50-848f-f65a6027e63d@github.com>
Message-ID: <nOJrICLcric2BLvr1KycchJd1Dk_5k01WBXBBOPxSqw=.8873aa59-d208-4ae7-b8f7-bdb23648c649@github.com>

On Mon, 28 Apr 2025 22:57:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When old generation marking is cancelled to run a young collection. we still set a `_degen_point ` for reasons that became vestigial after [JDK-8349094](https://bugs.openjdk.org/browse/JDK-8349094). When old marking is cancelled, the `_degen_point` should only be set if the marking was cancelled because of an allocation failure (and it should still only be set to "outside of cycle"). The following sequence could lead to this assertion failure:
> 1. Control thread is marking old
> 2. Young GC preempts it
> 3. Control thread sets the degen point because the old GC was "cancelled"
> 4. The concurrent young GC fails and attempts to set a degenerated point
> 5. This trips the assert because we already (incorrectly) set the degen point in `3`.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/24940#pullrequestreview-2804472540

From ysr at openjdk.org  Tue Apr 29 20:17:49 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 29 Apr 2025 20:17:49 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled [v2]
In-Reply-To: <BKYu3n1UV4MwRi2TzJgtHFJFDqgtLVX15C7awvI50YY=.b6b24e3f-1a9e-427f-b991-dc5fc0158614@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
 <BKYu3n1UV4MwRi2TzJgtHFJFDqgtLVX15C7awvI50YY=.b6b24e3f-1a9e-427f-b991-dc5fc0158614@github.com>
Message-ID: <t8Jl8T7tZZCOAUgrn70bMvyW0PSw8rxFdkTHVMs0XZs=.13d8f1c9-a96d-4c4b-8584-5fddcdfccbbd@github.com>

On Mon, 28 Apr 2025 22:26:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Add a test case for `-XX:+UseCompactObjectHeaders`, increase pressure on old generation. I ran the test (which includes a compact object headers case now) fifty times without failure.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify cases with comment

ok

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24888#pullrequestreview-2804940817

From ysr at openjdk.org  Tue Apr 29 21:18:44 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 29 Apr 2025 21:18:44 GMT
Subject: RFR: 8355789: GenShen: assert(_degen_point ==
 ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of
 Cycle
In-Reply-To: <eldRj6x8c_ZOWmXXtfHUozFy3rtBVf7zGM_3zfnOlAE=.ab42ee08-632d-4c50-848f-f65a6027e63d@github.com>
References: <eldRj6x8c_ZOWmXXtfHUozFy3rtBVf7zGM_3zfnOlAE=.ab42ee08-632d-4c50-848f-f65a6027e63d@github.com>
Message-ID: <U-JFVvhrniS6A7Syl8xnn7RvlgxIPLm6BPiRNpNRoW8=.b9e19078-9cb7-4e6e-97c7-5bd9fe5c3ac5@github.com>

On Mon, 28 Apr 2025 22:57:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When old generation marking is cancelled to run a young collection. we still set a `_degen_point ` for reasons that became vestigial after [JDK-8349094](https://bugs.openjdk.org/browse/JDK-8349094). When old marking is cancelled, the `_degen_point` should only be set if the marking was cancelled because of an allocation failure (and it should still only be set to "outside of cycle"). The following sequence could lead to this assertion failure:
> 1. Control thread is marking old
> 2. Young GC preempts it
> 3. Control thread sets the degen point because the old GC was "cancelled"
> 4. The concurrent young GC fails and attempts to set a degenerated point
> 5. This trips the assert because we already (incorrectly) set the degen point in `3`.

This looks fine, but it also leaves me with the feeling that we should sit down and review the interaction of the state machines for the young and old collections with the mutator allocations, and see if we can simplify the interaction protocol.

?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24940#pullrequestreview-2805105686

From kdnilsen at openjdk.org  Tue Apr 29 22:03:59 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 29 Apr 2025 22:03:59 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v4]
In-Reply-To: <JkqgaXVo3UXNL81WvIvpHYWvT7UnaYhMu7UH5JXwXTs=.92bc38ae-1edb-4025-a334-9de352f83272@github.com>
References: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
 <JkqgaXVo3UXNL81WvIvpHYWvT7UnaYhMu7UH5JXwXTs=.92bc38ae-1edb-4025-a334-9de352f83272@github.com>
Message-ID: <M4Hkif6TVsytACx5hxYOhAOXJYaUoNvdAzpkkTgj0kM=.8c1f7693-7200-4f74-aea3-86c78e0041a1@github.com>

On Tue, 29 Apr 2025 00:03:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Conflict in risc-v code, trivial resolution.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert references to method that hasn't been backported

Thanks for the backport

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

Marked as reviewed by kdnilsen (Committer).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/186#pullrequestreview-2805180335

From ysr at openjdk.org  Tue Apr 29 22:20:06 2025
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 29 Apr 2025 22:20:06 GMT
Subject: RFR: 8343468: GenShen: Enable relocation of remembered set card
 tables [v4]
In-Reply-To: <JkqgaXVo3UXNL81WvIvpHYWvT7UnaYhMu7UH5JXwXTs=.92bc38ae-1edb-4025-a334-9de352f83272@github.com>
References: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
 <JkqgaXVo3UXNL81WvIvpHYWvT7UnaYhMu7UH5JXwXTs=.92bc38ae-1edb-4025-a334-9de352f83272@github.com>
Message-ID: <lSYEeeDXt45JjUVxBcdOW-3mcs-uxjqwVm6BPci7CUk=.506dab0f-4a55-4aaf-9c80-1202adb00ab4@github.com>

On Tue, 29 Apr 2025 00:03:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Conflict in risc-v code, trivial resolution.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert references to method that hasn't been backported

Marked as reviewed by ysr (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/186#pullrequestreview-2805200574

From wkemper at openjdk.org  Tue Apr 29 22:32:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 29 Apr 2025 22:32:13 GMT
Subject: Integrated: 8343468: GenShen: Enable relocation of remembered set card
 tables
In-Reply-To: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
References: <uOD9xvplqJLVk92YaQsdQz6g2Y6ufdE99KTWAIfawyk=.a0f7050d-8592-4355-81bc-991b32609b64@github.com>
Message-ID: <eiCQ-oK0sJwsUuJqSCRAf6MkABoxN1cX8Af3vQ2zEC8=.0ba9759a-5330-4912-b631-ecdd836d78a8@github.com>

On Fri, 25 Apr 2025 20:29:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Conflict in risc-v code, trivial resolution.

This pull request has now been integrated.

Changeset: ef9d467b
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/ef9d467bec6b5e3c18ce89aac96599a7a530afd5
Stats:     356 lines in 26 files changed: 200 ins; 95 del; 61 mod

8343468: GenShen: Enable relocation of remembered set card tables
8351456: Build failure with --disable-jvm-feature-shenandoahgc after 8343468

Reviewed-by: kdnilsen, ysr
Backport-of: 4e1367e34be724a0f84069100854c38333610714

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

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

From wkemper at openjdk.org  Tue Apr 29 22:58:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 29 Apr 2025 22:58:50 GMT
Subject: Integrated: 8355789: GenShen: assert(_degen_point ==
 ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of
 Cycle
In-Reply-To: <eldRj6x8c_ZOWmXXtfHUozFy3rtBVf7zGM_3zfnOlAE=.ab42ee08-632d-4c50-848f-f65a6027e63d@github.com>
References: <eldRj6x8c_ZOWmXXtfHUozFy3rtBVf7zGM_3zfnOlAE=.ab42ee08-632d-4c50-848f-f65a6027e63d@github.com>
Message-ID: <SQKhncCzGoNXooOmAPYbYGon6OrCdgNV6JW0TWnycTo=.3e7cb257-ccac-44c6-888d-595ec1dabaa3@github.com>

On Mon, 28 Apr 2025 22:57:09 GMT, William Kemper <wkemper at openjdk.org> wrote:

> When old generation marking is cancelled to run a young collection. we still set a `_degen_point ` for reasons that became vestigial after [JDK-8349094](https://bugs.openjdk.org/browse/JDK-8349094). When old marking is cancelled, the `_degen_point` should only be set if the marking was cancelled because of an allocation failure (and it should still only be set to "outside of cycle"). The following sequence could lead to this assertion failure:
> 1. Control thread is marking old
> 2. Young GC preempts it
> 3. Control thread sets the degen point because the old GC was "cancelled"
> 4. The concurrent young GC fails and attempts to set a degenerated point
> 5. This trips the assert because we already (incorrectly) set the degen point in `3`.

This pull request has now been integrated.

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

8355789: GenShen: assert(_degen_point == ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of Cycle

Reviewed-by: kdnilsen, ysr

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

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

From wkemper at openjdk.org  Wed Apr 30 15:38:51 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 30 Apr 2025 15:38:51 GMT
Subject: RFR: 8355372: GenShen: Test
 gc/shenandoah/generational/TestOldGrowthTriggers.java fails with
 UseCompactObjectHeaders enabled
In-Reply-To: <_6MD1OrkbiBPcjVkKGXvlH4xGplX11i7L_FAYKXZls8=.1a8d7276-7eac-443c-aa74-a45a3ef65e17@github.com>
References: <GsE18YGCcu7d8l-mr3M8mE7_4sNEEG3iRgY0p7_1Mms=.0ed071ee-c96d-4536-a202-c983dd2123e0@github.com>
 <oMr-Paz-5DJfUgBU7M_PbFFFbVMA2jUzs63eJDNJ_3Q=.17c865ab-6ab5-412d-80f7-4da5543f15a3@github.com>
 <h_1YUYgXsb1u2CKLQWG_U146mQI8JhKGGmCKW8v79uA=.cbb612ba-1162-408f-810f-354c1e111014@github.com>
 <A7uJv2S_xHnx2RWajqZ79drsBKIsEHwGLOuPVS-QFMY=.7914d187-ca22-4532-b7b3-9a900cb4b032@github.com>
 <_6MD1OrkbiBPcjVkKGXvlH4xGplX11i7L_FAYKXZls8=.1a8d7276-7eac-443c-aa74-a45a3ef65e17@github.com>
Message-ID: <kq3_Hv_tGpZNkyD8H-mSRgzu3pIWQvTw32xE572p3C8=.eee51f5d-d598-47a3-a8d8-6be41c199edf@github.com>

On Tue, 29 Apr 2025 14:26:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>>> thank you! Please let us know how it goes.
>> 
>> Unfortunately, not so good .
>> On darwin x86_64  fastdebug,  
>> 
>> gc/shenandoah/generational/TestOldGrowthTriggers.java
>> 
>> triggers now this crash/assert  
>> 
>> 
>> #  Internal Error (/priv/jenkins/client-home/workspace/openjdk-jdk-dev-macos_x86_64-dbg/jdk/src/hotspot/share/gc/shenandoah/shenandoahGenerationalControlThread.cpp:607), pid=58469, tid=18179
>> #  assert(_degen_point == ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of Cycle
>> 
>> Stack: [0x000070000fc5b000,0x000070000fd5b000],  sp=0x000070000fd5aae0,  free space=1022k
>> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
>> V  [libjvm.dylib+0x1576749]  VMError::report(outputStream*, bool)+0x1ef9  (shenandoahGenerationalControlThread.cpp:607)
>> V  [libjvm.dylib+0x157a65b]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void const*, void const*, char const*, int, unsigned long)+0x60b
>> V  [libjvm.dylib+0x72bd08]  report_vm_error(char const*, int, char const*, char const*, ...)+0xd8
>> V  [libjvm.dylib+0x121e75a]  ShenandoahGenerationalControlThread::check_cancellation_or_degen(ShenandoahGC::ShenandoahDegenPoint)+0x14a
>> V  [libjvm.dylib+0x121e455]  ShenandoahGenerationalControlThread::service_concurrent_cycle(ShenandoahGeneration*, GCCause::Cause, bool)+0x165
>> V  [libjvm.dylib+0x121cd72]  ShenandoahGenerationalControlThread::run_gc_cycle(ShenandoahGenerationalControlThread::ShenandoahGCRequest const&)+0x1a2
>> V  [libjvm.dylib+0x121c8b2]  ShenandoahGenerationalControlThread::run_service()+0x142
>> V  [libjvm.dylib+0x6a798b]  ConcurrentGCThread::run()+0x1b
>> V  [libjvm.dylib+0x14bfa5c]  Thread::call_run()+0xbc
>> V  [libjvm.dylib+0x1060ff7]  thread_native_entry(Thread*)+0x137
>> C  [libsystem_pthread.dylib+0x618b]  _pthread_start+0x63
>> C  [libsystem_pthread.dylib+0x1ae3]  thread_start+0xf
>
>>Unfortunately, not so good .
>>On darwin x86_64 fastdebug,
>>
>>gc/shenandoah/generational/TestOldGrowthTriggers.java
>>
>>triggers now this crash/assert
> 
> Seems we have for this already
> https://bugs.openjdk.org/browse/JDK-8355789
> JDK-8355789: GenShen: assert(_degen_point == ShenandoahGC::_degenerated_unset) failed: Should not be set yet: Outside of Cycle

@MBaesken , have you had a chance to retest after PR#24940 was integrated?

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

PR Comment: https://git.openjdk.org/jdk/pull/24888#issuecomment-2842405876

From wkemper at openjdk.org  Wed Apr 30 15:49:39 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 30 Apr 2025 15:49:39 GMT
Subject: RFR: 8352185: Shenandoah: Invalid logic for remembered set
 verification
Message-ID: <gan6IIgXrzqDYPO-WiOxVt0r847MAazcMEY8o1X4L_k=.b06f74b4-545c-498d-b92f-5fdd830bbb4e@github.com>

Clean backport.

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

Commit messages:
 - Backport 4d1de46cb882bade5781255b646f623b55d7180f

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/188/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=188&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352185
  Stats: 51 lines in 4 files changed: 27 ins; 16 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/188.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/188/head:pull/188

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

From gziemski at openjdk.org  Wed Apr 30 15:53:13 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 30 Apr 2025 15:53:13 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v12]
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: <Ag6w5eRVGpb5qmAo336Ev06S6hWrYiy0x-v6CL7VUdY=.d0e52e5b-eefb-4a75-a6e8-a0f18b9626b7@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 13 additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - after merge fixes
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - Merge remote-tracking branch 'upstream/master' into JDK-8354547
 - remove last default argument (found by Stefan)
 - ... and 3 more: https://git.openjdk.org/jdk/compare/ff219180...7ca990ff

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24634/files
  - new: https://git.openjdk.org/jdk/pull/24634/files/6196f061..7ca990ff

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24634&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24634&range=10-11

  Stats: 2764 lines in 55 files changed: 2048 ins; 287 del; 429 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  Wed Apr 30 16:12:52 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 30 Apr 2025 16:12:52 GMT
Subject: RFR: 8354547: REDO: Force clients to explicitly pass mem_tag
 value, even if it is mtNone [v12]
In-Reply-To: <Ag6w5eRVGpb5qmAo336Ev06S6hWrYiy0x-v6CL7VUdY=.d0e52e5b-eefb-4a75-a6e8-a0f18b9626b7@github.com>
References: <a2Rz-ABkVE4-RjxbAqDz2kLRvqSI0Cz7qhY47F6FlIU=.fafa3d81-b542-4adb-9d2c-947d5f75cdd3@github.com>
 <Ag6w5eRVGpb5qmAo336Ev06S6hWrYiy0x-v6CL7VUdY=.d0e52e5b-eefb-4a75-a6e8-a0f18b9626b7@github.com>
Message-ID: <VW3IDr8udfvw6hj1DcWtfYXt_GiD0efu3nMBCyVRxck=.a59ab2d9-c8c5-4060-b781-db21df17431e@github.com>

On Wed, 30 Apr 2025 15:53:13 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 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 13 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - after merge fixes
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - Merge remote-tracking branch 'upstream/master' into JDK-8354547
>  - remove last default argument (found by Stefan)
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/08f4670b...7ca990ff

Mdash looks good. Just merged and ran tier1 locally on macOS. I ran tier1-3 yesterday (1 unrelated failure), so as soon as the checks here are done, I plan on integrating.

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

PR Comment: https://git.openjdk.org/jdk/pull/24634#issuecomment-2842509900

From wkemper at openjdk.org  Wed Apr 30 17:43:13 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 30 Apr 2025 17:43:13 GMT
Subject: Integrated: 8352185: Shenandoah: Invalid logic for remembered set
 verification
In-Reply-To: <gan6IIgXrzqDYPO-WiOxVt0r847MAazcMEY8o1X4L_k=.b06f74b4-545c-498d-b92f-5fdd830bbb4e@github.com>
References: <gan6IIgXrzqDYPO-WiOxVt0r847MAazcMEY8o1X4L_k=.b06f74b4-545c-498d-b92f-5fdd830bbb4e@github.com>
Message-ID: <2V7A-COjdcnwk8oD6iOtgSwQvuOTszcKiOzl_ERhg14=.7c05b11a-33db-4fbb-aa99-8793767f3e35@github.com>

On Wed, 30 Apr 2025 15:43:20 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Clean backport.

This pull request has now been integrated.

Changeset: 51256d9d
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/51256d9de02ecfedc01830678fa5434a9735ce3d
Stats:     51 lines in 4 files changed: 27 ins; 16 del; 8 mod

8352185: Shenandoah: Invalid logic for remembered set verification
8345399: GenShen: Error: Verify init-mark remembered set violation; clean card should be dirty

Backport-of: 4d1de46cb882bade5781255b646f623b55d7180f

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

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

From gziemski at openjdk.org  Wed Apr 30 17:59:51 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Wed, 30 Apr 2025 17:59:51 GMT
Subject: Integrated: 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: <ixLMUnbpRECr7lNAiRtoQDCD_4KxQJXhcGVp1k65_xU=.68704f04-37df-4f8d-bab6-f0d4e79b91fd@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 tier1 locally on my mac, Mach5 tier1-5 in progress

This pull request has now been integrated.

Changeset: 9a2a2c5b
Author:    Gerard Ziemski <gziemski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a2a2c5bb17d052574f7e6cd712672151e1b193f
Stats:     148 lines in 48 files changed: 18 ins; 1 del; 129 mod

8354547: REDO: 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, coleenp, jsjolen

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

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

From wkemper at openjdk.org  Wed Apr 30 19:04:50 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 30 Apr 2025 19:04:50 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is not
 accurately maintained
Message-ID: <F-1GJWklAP5yxEFPHS9mssTzYluPeHwVbZBAsqRpF50=.60175c59-4831-4702-a567-d546429a87ea@github.com>

Not clean - trivial conflicts with `SIZE_FORMAT/%zu` changes.

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

Commit messages:
 - Backport aec1fe0a17fa6801e26a517d4d21656353409f7c

Changes: https://git.openjdk.org/shenandoah-jdk21u/pull/190/files
  Webrev: https://webrevs.openjdk.org/?repo=shenandoah-jdk21u&pr=190&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8351091
  Stats: 70 lines in 17 files changed: 7 ins; 34 del; 29 mod
  Patch: https://git.openjdk.org/shenandoah-jdk21u/pull/190.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk21u.git pull/190/head:pull/190

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

From xpeng at openjdk.org  Wed Apr 30 19:49:06 2025
From: xpeng at openjdk.org (Xiaolong Peng)
Date: Wed, 30 Apr 2025 19:49:06 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained
In-Reply-To: <F-1GJWklAP5yxEFPHS9mssTzYluPeHwVbZBAsqRpF50=.60175c59-4831-4702-a567-d546429a87ea@github.com>
References: <F-1GJWklAP5yxEFPHS9mssTzYluPeHwVbZBAsqRpF50=.60175c59-4831-4702-a567-d546429a87ea@github.com>
Message-ID: <vyNJ_ZNo3H5EVxdlSzmTDVwhLqGrg8YOPhwSpvW7MRk=.d28fa15f-e038-4f60-a72d-a2cea0b62da0@github.com>

On Wed, 30 Apr 2025 18:58:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean - trivial conflicts with `SIZE_FORMAT/%zu` changes.

Thanks, it looks good to me.

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

Marked as reviewed by xpeng (no project role).

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/190#pullrequestreview-2808233393

From kdnilsen at openjdk.org  Wed Apr 30 19:55:05 2025
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 30 Apr 2025 19:55:05 GMT
Subject: RFR: 8351091: Shenandoah: global marking context completeness is
 not accurately maintained
In-Reply-To: <F-1GJWklAP5yxEFPHS9mssTzYluPeHwVbZBAsqRpF50=.60175c59-4831-4702-a567-d546429a87ea@github.com>
References: <F-1GJWklAP5yxEFPHS9mssTzYluPeHwVbZBAsqRpF50=.60175c59-4831-4702-a567-d546429a87ea@github.com>
Message-ID: <M3JERyVucuK9OjxvnBtK3dwAfmJ0Ce_4JKFbT97ZyF4=.ed3848d0-d19e-4bc8-9098-0529bb0b29ba@github.com>

On Wed, 30 Apr 2025 18:58:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean - trivial conflicts with `SIZE_FORMAT/%zu` changes.

Marked as reviewed by kdnilsen (Committer).

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

PR Review: https://git.openjdk.org/shenandoah-jdk21u/pull/190#pullrequestreview-2808257965

From wkemper at openjdk.org  Wed Apr 30 20:06:11 2025
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 30 Apr 2025 20:06:11 GMT
Subject: Integrated: 8351091: Shenandoah: global marking context completeness
 is  not accurately maintained
In-Reply-To: <F-1GJWklAP5yxEFPHS9mssTzYluPeHwVbZBAsqRpF50=.60175c59-4831-4702-a567-d546429a87ea@github.com>
References: <F-1GJWklAP5yxEFPHS9mssTzYluPeHwVbZBAsqRpF50=.60175c59-4831-4702-a567-d546429a87ea@github.com>
Message-ID: <nG_O6DzgM_f1gnFTEYSIONhjZjYreKT9cmMOl0ufqpM=.484c6c62-8786-4293-bf7b-aa04f7953830@github.com>

On Wed, 30 Apr 2025 18:58:59 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Not clean - trivial conflicts with `SIZE_FORMAT/%zu` changes.

This pull request has now been integrated.

Changeset: 82b11cb4
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk21u/commit/82b11cb49a9f6509959a6476d0d1d91c81fcfd02
Stats:     70 lines in 17 files changed: 7 ins; 34 del; 29 mod

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

Reviewed-by: xpeng, kdnilsen
Backport-of: aec1fe0a17fa6801e26a517d4d21656353409f7c

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

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