From kbarrett at openjdk.org  Sun Apr  2 05:12:31 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 2 Apr 2023 05:12:31 GMT
Subject: RFR: 8305370: Inconsistent use of for_young_only_phase parameter
 in G1 predictions
In-Reply-To: <5kDZEtKFbNyHIg5CkIq9w6BmSKtEZQdR3LCDI8IkCmY=.924c6c12-1c1b-4fa3-8033-dd8fde358402@github.com>
References: <5kDZEtKFbNyHIg5CkIq9w6BmSKtEZQdR3LCDI8IkCmY=.924c6c12-1c1b-4fa3-8033-dd8fde358402@github.com>
Message-ID: <Zv62u0VUg7TLn0VWg6xD_nS3EywF1oFV66Uy0jHgD3E=.401c4ddb-b53e-47aa-8d1f-ee67ec291c9f@github.com>

On Fri, 31 Mar 2023 11:19:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to fix some inconsistent use of `for_young_only_phase`: some methods that require it are not passed that parameter, and some methods, although getting passed that parameter partially re-load that value from collector state.
> 
> Fwiw, I am aware that `G1Policy::predict_region_total_time_ms` only ever gets passed `false` as this parameter. I would have changed that as well if some [upcoming change](https://github.com/openjdk/jdk/commit/6c2f18eba29ad9f6e4e5ed28f1521037fdc49398) did not use other values as well. We can always remove it later if not necessary, but if somebody insists on doing so I will do that as well (probably separately).
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13267#pullrequestreview-1368020314

From duke at openjdk.org  Sun Apr  2 07:25:18 2023
From: duke at openjdk.org (M4ximumPizza)
Date: Sun, 2 Apr 2023 07:25:18 GMT
Subject: RFR: 8305368: G1 remset chunk claiming may use relaxed memory
 ordering
In-Reply-To: <ZOybe4ia50aFTYvaiSH1rFPJzPUHnCTzeb76uigMfMg=.94aa7379-9265-48c5-bd44-92bca7246380@github.com>
References: <ZOybe4ia50aFTYvaiSH1rFPJzPUHnCTzeb76uigMfMg=.94aa7379-9265-48c5-bd44-92bca7246380@github.com>
Message-ID: <G5rEZnra1D0hHOY-6yNlZeTjLx1whcdlcXcM0IsCSz4=.3e7edcb4-0ef9-4ce9-be0b-b8a65b8ac18e@github.com>

On Fri, 31 Mar 2023 11:15:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this minor change that changes the atomic increment for claiming chunks during scanning remembered sets to use relaxed memory ordering.
> Nothing depends on that, and nothing should. No particular performance improvements (expected; on x86 all atomics are "conservative" anyway).
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by M4ximumPizza at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/13266#pullrequestreview-1368033611

From iwalulya at openjdk.org  Mon Apr  3 09:18:38 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 3 Apr 2023 09:18:38 GMT
Subject: RFR: 8305368: G1 remset chunk claiming may use relaxed memory
 ordering
In-Reply-To: <ZOybe4ia50aFTYvaiSH1rFPJzPUHnCTzeb76uigMfMg=.94aa7379-9265-48c5-bd44-92bca7246380@github.com>
References: <ZOybe4ia50aFTYvaiSH1rFPJzPUHnCTzeb76uigMfMg=.94aa7379-9265-48c5-bd44-92bca7246380@github.com>
Message-ID: <Qgiw0_gTEpzOtK-3hcIO6N40P2QTVQ8uDbaLybGh7eg=.811f7ecf-4efd-4a96-b448-caf45843f272@github.com>

On Fri, 31 Mar 2023 11:15:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this minor change that changes the atomic increment for claiming chunks during scanning remembered sets to use relaxed memory ordering.
> Nothing depends on that, and nothing should. No particular performance improvements (expected; on x86 all atomics are "conservative" anyway).
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13266#pullrequestreview-1368597325

From iwalulya at openjdk.org  Mon Apr  3 15:28:58 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 3 Apr 2023 15:28:58 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v4]
In-Reply-To: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
Message-ID: <rFa1iMDrYusC6zj9ivLTp2yGRtW8nMVmqW2WmGrB9NY=.9a3c99e9-8965-421a-a970-94fbe5c59276@github.com>

> Hi All,
> 
> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
> 
> The change should also handle the issues reported in JDK-8299276.
> 
> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
> 
> Testing: Tier 1-5.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Albert review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13191/files
  - new: https://git.openjdk.org/jdk/pull/13191/files/2bd6d5fa..7352deed

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

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

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

From wkemper at openjdk.org  Mon Apr  3 22:46:15 2023
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 3 Apr 2023 22:46:15 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
Message-ID: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>

Shenandoah evacuation workers may deadlock if a safepoint begins during concurrent evacuation _and_ a GC worker thread experiences an out of memory error during the evacuation.

This situation occurs because some of the workers have set the cancelled state to `NOT_CANCELLED` and then yielded to the suspendible thread set because a safepoint is starting. Other workers who then experience an OOM during evacuation attempt to transition the heap from `CANCELLABLE` to `CANCELLED` in a CAS loop that will never succeed (because the cancelled state is `NOT_CANCELLED`). These workers are unable to join the suspendible thread set, so the threads which have yielded are unable to resume and reset the heap to `CANCELLABLE`. The VM thread cannot enter the safepoint and eventually all of the mutator threads block when they are unable to allocate.

The changes here remove the `NOT_CANCELLED` state and remove the CAS loop used to transition from `CANCELLABLE` to `CANCELLED`. Additionally, worker threads that need to suspend no longer put the heap in the `NOT_CANCELLED` state before suspending.

In order to test this, the behavior of the diagnostic flag was modified to provoke this scenario:

diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
index 4158f4bee22..e261dd3a81b 100644
--- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
+++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
@@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
   HeapWord* copy = nullptr;
 
 #ifdef ASSERT
-  if (ShenandoahOOMDuringEvacALot &&
-      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
+  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
         copy = nullptr;
   } else {
 #endif


This applies the failure only to worker threads and only when they are expected to suspend and only with a 1/1000 chance of failing for each evacuation. Without these fixes, the modification to `ShenandoahOOMDuringEvacALot` causes a deadlock in under two minutes of execution on [the extremem benchmark](https://github.com/corretto/heapothesys/tree/master/Extremem) with these additional diagnostic flags:

-XX:+SafepointALot -XX:+ShenandoahOOMDuringEvacALot -XX:ConcGCThreads=12 -XX:GuaranteedSafepointInterval=50

After these changes, the benchmark no longer deadlocks.

Additional testing includes jtreg `test/hotspot/jtreg:hotspot_gc_shenandoah`, the Dacapo benchmark suite, HyperAlloc and specjbb 2015.

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

Commit messages:
 - Enable suspendible workers by default
 - Don't suspend if GC is already cancelled
 - Do not prevent cancellations before yielding to STS. Simplify cancellation states

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

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

From kdnilsen at openjdk.org  Mon Apr  3 23:14:08 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 3 Apr 2023 23:14:08 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
Message-ID: <45m2fsS2wK9nep_UCyCXZzxJcK703ShFSXQpsB81_ys=.546f74a2-42c3-4956-b933-517206707888@github.com>

On Mon, 3 Apr 2023 21:45:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah evacuation workers may deadlock if a safepoint begins during concurrent evacuation _and_ a GC worker thread experiences an out of memory error during the evacuation.
> 
> This situation occurs because some of the workers have set the cancelled state to `NOT_CANCELLED` and then yielded to the suspendible thread set because a safepoint is starting. Other workers who then experience an OOM during evacuation attempt to transition the heap from `CANCELLABLE` to `CANCELLED` in a CAS loop that will never succeed (because the cancelled state is `NOT_CANCELLED`). These workers are unable to join the suspendible thread set, so the threads which have yielded are unable to resume and reset the heap to `CANCELLABLE`. The VM thread cannot enter the safepoint and eventually all of the mutator threads block when they are unable to allocate.
> 
> The changes here remove the `NOT_CANCELLED` state and remove the CAS loop used to transition from `CANCELLABLE` to `CANCELLED`. Additionally, worker threads that need to suspend no longer put the heap in the `NOT_CANCELLED` state before suspending.
> 
> In order to test this, the behavior of the diagnostic flag was modified to provoke this scenario:
> 
> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> index 4158f4bee22..e261dd3a81b 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> @@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
>    HeapWord* copy = nullptr;
>  
>  #ifdef ASSERT
> -  if (ShenandoahOOMDuringEvacALot &&
> -      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
> +  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
>          copy = nullptr;
>    } else {
>  #endif
> 
> 
> This applies the failure only to worker threads and only when they are expected to suspend and only with a 1/1000 chance of failing for each evacuation. Without these fixes, the modification to `ShenandoahOOMDuringEvacALot` causes a deadlock in under two minutes of execution on [the extremem benchmark](https://github.com/corretto/heapothesys/tree/master/Extremem) with these additional diagnostic flags:
> 
> -XX:+SafepointALot -XX:+ShenandoahOOMDuringEvacALot -XX:ConcGCThreads=12 -XX:GuaranteedSafepointInterval=50
> 
> After these changes, the benchmark no longer deadlocks.
> 
> Additional testing includes jtreg `test/hotspot/jtreg:hotspot_gc_shenandoah`, the Dacapo benchmark suite, HyperAlloc and specjbb 2015.

Changes requested by kdnilsen (no project role).

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 337:

> 335:           "end of concurrent marking.")                                     \
> 336:                                                                             \
> 337:   product(bool, ShenandoahSuspendibleWorkers, true, EXPERIMENTAL,           \

Can we provide some more information under help as to why workers should or should not be suspendible?

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

PR Review: https://git.openjdk.org/jdk/pull/13309#pullrequestreview-1369911617
PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1156533968

From wkemper at openjdk.org  Tue Apr  4 00:03:07 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 4 Apr 2023 00:03:07 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <45m2fsS2wK9nep_UCyCXZzxJcK703ShFSXQpsB81_ys=.546f74a2-42c3-4956-b933-517206707888@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
 <45m2fsS2wK9nep_UCyCXZzxJcK703ShFSXQpsB81_ys=.546f74a2-42c3-4956-b933-517206707888@github.com>
Message-ID: <a7NSpvOPe4a6UY9V2oMUegFB0bFksfoPv3iFCkXxrNs=.359d7e32-e623-4ab7-96d9-9bfbb0a8d7a0@github.com>

On Mon, 3 Apr 2023 23:11:30 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Shenandoah evacuation workers may deadlock if a safepoint begins during concurrent evacuation _and_ a GC worker thread experiences an out of memory error during the evacuation.
>> 
>> This situation occurs because some of the workers have set the cancelled state to `NOT_CANCELLED` and then yielded to the suspendible thread set because a safepoint is starting. Other workers who then experience an OOM during evacuation attempt to transition the heap from `CANCELLABLE` to `CANCELLED` in a CAS loop that will never succeed (because the cancelled state is `NOT_CANCELLED`). These workers are unable to join the suspendible thread set, so the threads which have yielded are unable to resume and reset the heap to `CANCELLABLE`. The VM thread cannot enter the safepoint and eventually all of the mutator threads block when they are unable to allocate.
>> 
>> The changes here remove the `NOT_CANCELLED` state and remove the CAS loop used to transition from `CANCELLABLE` to `CANCELLED`. Additionally, worker threads that need to suspend no longer put the heap in the `NOT_CANCELLED` state before suspending.
>> 
>> In order to test this, the behavior of the diagnostic flag was modified to provoke this scenario:
>> 
>> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
>> index 4158f4bee22..e261dd3a81b 100644
>> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
>> @@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
>>    HeapWord* copy = nullptr;
>>  
>>  #ifdef ASSERT
>> -  if (ShenandoahOOMDuringEvacALot &&
>> -      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
>> +  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
>>          copy = nullptr;
>>    } else {
>>  #endif
>> 
>> 
>> This applies the failure only to worker threads and only when they are expected to suspend and only with a 1/1000 chance of failing for each evacuation. Without these fixes, the modification to `ShenandoahOOMDuringEvacALot` causes a deadlock in under two minutes of execution on [the extremem benchmark](https://github.com/corretto/heapothesys/tree/master/Extremem) with these additional diagnostic flags:
>> 
>> -XX:+SafepointALot -XX:+ShenandoahOOMDuringEvacALot -XX:ConcGCThreads=12 -XX:GuaranteedSafepointInterval=50
>> 
>> After these changes, the benchmark no longer deadlocks.
>> 
>> Additional testing includes jtreg `test/hotspot/jtreg:hotspot_gc_shenandoah`, the Dacapo benchmark suite, HyperAlloc and specjbb 2015.
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 337:
> 
>> 335:           "end of concurrent marking.")                                     \
>> 336:                                                                             \
>> 337:   product(bool, ShenandoahSuspendibleWorkers, true, EXPERIMENTAL,           \
> 
> Can we provide some more information under help as to why workers should or should not be suspendible?

I would like to know this myself ;) There are phases of class unloading that unconditionally suspend the control and worker threads. It's not clear to me why marking or evacuation threads would need to suspend.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1156564586

From asotona at openjdk.org  Tue Apr  4 07:52:08 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 4 Apr 2023 07:52:08 GMT
Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces classes
 with invalid field descriptors
Message-ID: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>

CommandProcessor command "dumpclass" produces classes with invalid field descriptors. 

Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`.

Added condition to  `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes.

Please review.

Thank you,
Adam

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

Commit messages:
 - added test condition
 - 8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors

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

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

From ayang at openjdk.org  Tue Apr  4 10:19:13 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 4 Apr 2023 10:19:13 GMT
Subject: RFR: 8305192: serial GC fails
 "assert(Universe::on_page_boundary(bottom) && Universe::on_page_boundary(end))
 failed: invalid space boundaries"
Message-ID: <IX3fc0tcEVcRV0nfzm7xb9Bq_76rGYXPSedOVGfBMj8=.b5b7fa3c-31f1-42ac-8820-79e640d0fcfb@github.com>

Fix to ensure survivor-space is properly aligned.

(I tried to reproduce the failure on master but to no avail.)

Test: tier1-6

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

Commit messages:
 - s1-eden-align

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

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

From ayang at openjdk.org  Tue Apr  4 10:19:58 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 4 Apr 2023 10:19:58 GMT
Subject: RFR: 8305233: G1: Refactor G1ClearCardTableTask [v2]
In-Reply-To: <84PkR6zsKATa8OU1r0DC4Yf_i97MBIQDKPISuWOLeAA=.07203beb-294c-424d-8fa0-f6a56ad4fbf0@github.com>
References: <84PkR6zsKATa8OU1r0DC4Yf_i97MBIQDKPISuWOLeAA=.07203beb-294c-424d-8fa0-f6a56ad4fbf0@github.com>
Message-ID: <YAm4XWhr9H2Wn7e9aZlXA8Z5mH3f1tuPf4_bJVdrNac=.797e9d5c-fde0-4ab7-b180-b56688bc1a8a@github.com>

> Simple refactoring for better encapsulation.
> 
> Test: hotspot_gc

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/gc/g1/g1RemSet.cpp
  
  Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13242/files
  - new: https://git.openjdk.org/jdk/pull/13242/files/50ef70c5..93aa290d

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

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

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

From cjplummer at openjdk.org  Tue Apr  4 17:45:06 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 4 Apr 2023 17:45:06 GMT
Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces
 classes with invalid field descriptors
In-Reply-To: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>
References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>
Message-ID: <HkAREN147XJMOls2IOkS3brmQmXcOE5IrC4vd3rZSmE=.c5fe71fc-02ff-4f57-9d60-d3370d21176c@github.com>

On Tue, 4 Apr 2023 07:44:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> CommandProcessor command "dumpclass" produces classes with invalid field descriptors. 
> 
> Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`.
> 
> Added condition to  `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes.
> 
> Please review.
> 
> Thank you,
> Adam

The test needs a copyright update. Otherwise the changes look good.

I assume the reason you caught this failure is because the [JDK-8294969](https://bugs.openjdk.org/browse/JDK-8294969) changes include making javap return a non-zero exit code if there are any error. If that's the case, I guess technically the test change is not needed, but probably good to have in place anyway.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13321#pullrequestreview-1371480017

From fparain at openjdk.org  Tue Apr  4 17:57:07 2023
From: fparain at openjdk.org (Frederic Parain)
Date: Tue, 4 Apr 2023 17:57:07 GMT
Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces
 classes with invalid field descriptors
In-Reply-To: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>
References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>
Message-ID: <CEe59ZZA9LmDQy56yjM0DhTR7ZqOIUgy-rkVQKlBxGY=.2603ddb9-ed0b-4ddb-9139-37fbd97bafa8@github.com>

On Tue, 4 Apr 2023 07:44:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> CommandProcessor command "dumpclass" produces classes with invalid field descriptors. 
> 
> Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`.
> 
> Added condition to  `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes.
> 
> Please review.
> 
> Thank you,
> Adam

Looks good to me.
Thank you for fixing this.

Fred

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

Marked as reviewed by fparain (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13321#pullrequestreview-1371500110

From asotona at openjdk.org  Wed Apr  5 06:30:51 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Apr 2023 06:30:51 GMT
Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces
 classes with invalid field descriptors [v2]
In-Reply-To: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>
References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>
Message-ID: <nw_WQKprLWLggZD-6X_bBiTih_zXAmJxGU4w0aMfGxE=.478fb358-87f3-48e3-8ad4-95dc03876f82@github.com>

> CommandProcessor command "dumpclass" produces classes with invalid field descriptors. 
> 
> Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`.
> 
> Added condition to  `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes.
> 
> Please review.
> 
> Thank you,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13321/files
  - new: https://git.openjdk.org/jdk/pull/13321/files/ff0b4c99..9077e2eb

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

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

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

From asotona at openjdk.org  Wed Apr  5 06:36:06 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Apr 2023 06:36:06 GMT
Subject: RFR: 8305490: CommandProcessor command "dumpclass" produces
 classes with invalid field descriptors [v2]
In-Reply-To: <nw_WQKprLWLggZD-6X_bBiTih_zXAmJxGU4w0aMfGxE=.478fb358-87f3-48e3-8ad4-95dc03876f82@github.com>
References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>
 <nw_WQKprLWLggZD-6X_bBiTih_zXAmJxGU4w0aMfGxE=.478fb358-87f3-48e3-8ad4-95dc03876f82@github.com>
Message-ID: <dfq2Csz0GMRoFMgvA2GEwgdNi2X6YTxrN8zWBAXqQc0=.25950b12-bab2-4dc6-9b1a-8b70558d80bc@github.com>

On Wed, 5 Apr 2023 06:30:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> CommandProcessor command "dumpclass" produces classes with invalid field descriptors. 
>> 
>> Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`.
>> 
>> Added condition to  `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright header

Thank you, I've updated test copyright header.

Yes, it was identified when working on [JDK-8294969](https://bugs.openjdk.org/browse/JDK-8294969), however it is still work in progress.

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

PR Comment: https://git.openjdk.org/jdk/pull/13321#issuecomment-1496987115

From asotona at openjdk.org  Wed Apr  5 13:23:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 5 Apr 2023 13:23:26 GMT
Subject: Integrated: 8305490: CommandProcessor command "dumpclass" produces
 classes with invalid field descriptors
In-Reply-To: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>
References: <8e2AC4JawGrdgbWH5PyuYPDNf2cYUPMIZ202DM-ujzA=.cf9602e1-d653-41b4-af4b-e4ef58606fcf@github.com>
Message-ID: <KP0UYkAhzdkv98FD9TBwEQER_sjTY3e0Lpp5hQAy0-4=.1f6c6af5-8bb2-483b-b6a3-3c65a4bf71ac@github.com>

On Tue, 4 Apr 2023 07:44:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> CommandProcessor command "dumpclass" produces classes with invalid field descriptors. 
> 
> Proposed patch fixes `sun.jvm.hotspot.oops.InstanceKlass::getFieldSignatureIndex` to return correct `getSignatureIndex` instead of invalid `getGenericSignatureIndex`.
> 
> Added condition to  `ClhsdbDumpclass` test assures no errors are reported by `javap` in the dumped classes.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 78ff454f
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78ff454f1986abdb9b72d3c6c5b1f3bbab823540
Stats:     3 lines in 2 files changed: 1 ins; 0 del; 2 mod

8305490: CommandProcessor command "dumpclass" produces classes with invalid field descriptors

Reviewed-by: cjplummer, fparain

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

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

From dcubed at openjdk.org  Wed Apr  5 21:29:20 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 5 Apr 2023 21:29:20 GMT
Subject: Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java
 on windows-x64 in Xcomp
Message-ID: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>

Trivial fixes to ProblemList a couple of tests:
[JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
[JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC

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

Commit messages:
 - 8305679: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC
 - 8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp

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

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

From mikael at openjdk.org  Wed Apr  5 21:29:20 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 5 Apr 2023 21:29:20 GMT
Subject: Integrated: 8305678: ProblemList
 serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
In-Reply-To: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
References: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
Message-ID: <FztW3oqLyzZMMsKMPZfTpaC744xRqdvUgv6OqDADSC0=.e43203ba-5683-45c2-9948-12779d418c3c@github.com>

On Wed, 5 Apr 2023 21:12:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList a couple of tests:
> [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
> [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC

Marked as reviewed by mikael (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13365#pullrequestreview-1373708430

From dcubed at openjdk.org  Wed Apr  5 21:29:21 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 5 Apr 2023 21:29:21 GMT
Subject: Integrated: 8305678: ProblemList
 serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
In-Reply-To: <FztW3oqLyzZMMsKMPZfTpaC744xRqdvUgv6OqDADSC0=.e43203ba-5683-45c2-9948-12779d418c3c@github.com>
References: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
 <FztW3oqLyzZMMsKMPZfTpaC744xRqdvUgv6OqDADSC0=.e43203ba-5683-45c2-9948-12779d418c3c@github.com>
Message-ID: <ilwkLHU3To0UHC-9zuH_FiJUXkN4ApaUYN92hqUHZt0=.a4c22c1f-7bcb-4c75-b613-c5371d05c5ec@github.com>

On Wed, 5 Apr 2023 21:18:28 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Trivial fixes to ProblemList a couple of tests:
>> [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
>> [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC
>
> Marked as reviewed by mikael (Reviewer).

@vidmik - Thanks for the fast review!

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

PR Comment: https://git.openjdk.org/jdk/pull/13365#issuecomment-1498180191

From dcubed at openjdk.org  Wed Apr  5 21:29:22 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 5 Apr 2023 21:29:22 GMT
Subject: Integrated: 8305678: ProblemList serviceability/sa/ClhsdbInspect.java
 on windows-x64 in Xcomp
In-Reply-To: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
References: <K2KonNWkIE9AOO0JRVyvjlRyVqQ4qpPKqGU80uwCh90=.e378c1e2-9648-4225-87bd-5cda880ce088@github.com>
Message-ID: <fNP8w6E0DR5Buf_w72VxtxGMWnhYi7m1Fz0sRYoZjxc=.4bb8daee-1099-4de0-933b-a4f2c198e3da@github.com>

On Wed, 5 Apr 2023 21:12:14 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList a couple of tests:
> [JDK-8305678](https://bugs.openjdk.org/browse/JDK-8305678) ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
> [JDK-8305679](https://bugs.openjdk.org/browse/JDK-8305679) ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC

This pull request has now been integrated.

Changeset: b5d204c3
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5d204c3a4274c2e4604390eba436d42b5f5e9c9
Stats:     3 lines in 2 files changed: 2 ins; 0 del; 1 mod

8305678: ProblemList serviceability/sa/ClhsdbInspect.java on windows-x64 in Xcomp
8305679: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-aarch64 with ZGC

Reviewed-by: mikael

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

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

From avoitylov at openjdk.org  Thu Apr  6 07:02:12 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Thu, 6 Apr 2023 07:02:12 GMT
Subject: RFR: 8305663: Wrong iteration order of pause array in g1MMUTracker
Message-ID: <3xa4tOTw8niU_BSOBRdFN-1U_XGFSkDpxq2XWdumJjg=.e28f2808-99a6-467e-825d-be7b40f6d6b9@github.com>

G1 pause _array is iterated from oldest pause to newer pause in order to calculate the pause budget, but it should be iterated in the opposite direction (newest to oldest).

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

Commit messages:
 - JDK-8305663

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

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

From ayang at openjdk.org  Thu Apr  6 10:09:17 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 6 Apr 2023 10:09:17 GMT
Subject: RFR: 8305663: Wrong iteration order of pause array in g1MMUTracker
In-Reply-To: <3xa4tOTw8niU_BSOBRdFN-1U_XGFSkDpxq2XWdumJjg=.e28f2808-99a6-467e-825d-be7b40f6d6b9@github.com>
References: <3xa4tOTw8niU_BSOBRdFN-1U_XGFSkDpxq2XWdumJjg=.e28f2808-99a6-467e-825d-be7b40f6d6b9@github.com>
Message-ID: <Gsd4Qu_7XEdWg77gpCU0AYrtFbCQUIdgXX1lDLTufuk=.4e0ce77a-e929-4b61-ac06-caad4ba3db04@github.com>

On Thu, 6 Apr 2023 06:55:04 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> G1 pause _array is iterated from oldest pause to newer pause in order to calculate the pause budget, but it should be iterated in the opposite direction (newest to oldest).

Thank you for finding this.

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13370#pullrequestreview-1374513988

From wkemper at openjdk.org  Thu Apr  6 18:26:03 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 6 Apr 2023 18:26:03 GMT
Subject: RFR: 8305716: Enhancements for printing age tables
Message-ID: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>

In order to reduce the number of changes for the upcoming PR for the generational mode for Shenandoah we are opening separate PRs for the changes in common code. Shenandoah will be using this `AgeTable` class. There are two changes here:
* `AgeTables` created with global=false will no longer SEGV when printing
* A method was added to allow the `AgeTable` to print to an existing output stream

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

Commit messages:
 - Enhancements for printing the age table

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

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

From rkennke at openjdk.org  Fri Apr  7 20:07:46 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 7 Apr 2023 20:07:46 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
Message-ID: <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>

On Mon, 3 Apr 2023 21:45:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah evacuation workers may deadlock if a safepoint begins during concurrent evacuation _and_ a GC worker thread experiences an out of memory error during the evacuation.
> 
> This situation occurs because some of the workers have set the cancelled state to `NOT_CANCELLED` and then yielded to the suspendible thread set because a safepoint is starting. Other workers who then experience an OOM during evacuation attempt to transition the heap from `CANCELLABLE` to `CANCELLED` in a CAS loop that will never succeed (because the cancelled state is `NOT_CANCELLED`). These workers are unable to join the suspendible thread set, so the threads which have yielded are unable to resume and reset the heap to `CANCELLABLE`. The VM thread cannot enter the safepoint and eventually all of the mutator threads block when they are unable to allocate.
> 
> The changes here remove the `NOT_CANCELLED` state and remove the CAS loop used to transition from `CANCELLABLE` to `CANCELLED`. Additionally, worker threads that need to suspend no longer put the heap in the `NOT_CANCELLED` state before suspending.
> 
> In order to test this, the behavior of the diagnostic flag was modified to provoke this scenario:
> 
> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> index 4158f4bee22..e261dd3a81b 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> @@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
>    HeapWord* copy = nullptr;
>  
>  #ifdef ASSERT
> -  if (ShenandoahOOMDuringEvacALot &&
> -      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
> +  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
>          copy = nullptr;
>    } else {
>  #endif
> 
> 
> This applies the failure only to worker threads and only when they are expected to suspend and only with a 1/1000 chance of failing for each evacuation. Without these fixes, the modification to `ShenandoahOOMDuringEvacALot` causes a deadlock in under two minutes of execution on [the extremem benchmark](https://github.com/corretto/heapothesys/tree/master/Extremem) with these additional diagnostic flags:
> 
> -XX:+SafepointALot -XX:+ShenandoahOOMDuringEvacALot -XX:ConcGCThreads=12 -XX:GuaranteedSafepointInterval=50
> 
> After these changes, the benchmark no longer deadlocks.
> 
> Additional testing includes jtreg `test/hotspot/jtreg:hotspot_gc_shenandoah`, the Dacapo benchmark suite, HyperAlloc and specjbb 2015.

Given that I can't remember why we (I) did the complex transition in the first place, let's get rid of it and see what explodes (if anything). There's good chances that the original reasons are no longer relevant. We might even consider a more aggressive approach, see my comments (your call).

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1743:

> 1741: 
> 1742: bool ShenandoahHeap::try_cancel_gc() {
> 1743:   jbyte prev = _cancelled_gc.cmpxchg(CANCELLED, CANCELLABLE);

Is there even a need to CAS here? The transition here can only go from CANCELLABLE to CANCELLED, is that correct? If that is so, then the CAS would only fail if another thread made that transition before us. Is that a relevant scenario that we must know about, or could we simply store CANCELLED?

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 337:

> 335:           "end of concurrent marking.")                                     \
> 336:                                                                             \
> 337:   product(bool, ShenandoahSuspendibleWorkers, true, EXPERIMENTAL,           \

Given that turning this off would most likely result in correctness issues, or certainly will in the future when Lilliput arrives, we should consider removing this option altogether.

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

Marked as reviewed by rkennke (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13309#pullrequestreview-1376540055
PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1160933835
PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1160934484

From wkemper at openjdk.org  Fri Apr  7 22:02:44 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 7 Apr 2023 22:02:44 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
 <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>
Message-ID: <Qa6uDzVvv7uoKU1kLhKA1nHD7EWPuYhx-cg0CbawPKI=.e23dc615-280d-4db7-89da-9f3c17795faf@github.com>

On Fri, 7 Apr 2023 20:01:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Shenandoah evacuation workers may deadlock if a safepoint begins during concurrent evacuation _and_ a GC worker thread experiences an out of memory error during the evacuation.
>> 
>> This situation occurs because some of the workers have set the cancelled state to `NOT_CANCELLED` and then yielded to the suspendible thread set because a safepoint is starting. Other workers who then experience an OOM during evacuation attempt to transition the heap from `CANCELLABLE` to `CANCELLED` in a CAS loop that will never succeed (because the cancelled state is `NOT_CANCELLED`). These workers are unable to join the suspendible thread set, so the threads which have yielded are unable to resume and reset the heap to `CANCELLABLE`. The VM thread cannot enter the safepoint and eventually all of the mutator threads block when they are unable to allocate.
>> 
>> The changes here remove the `NOT_CANCELLED` state and remove the CAS loop used to transition from `CANCELLABLE` to `CANCELLED`. Additionally, worker threads that need to suspend no longer put the heap in the `NOT_CANCELLED` state before suspending.
>> 
>> In order to test this, the behavior of the diagnostic flag was modified to provoke this scenario:
>> 
>> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
>> index 4158f4bee22..e261dd3a81b 100644
>> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
>> @@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
>>    HeapWord* copy = nullptr;
>>  
>>  #ifdef ASSERT
>> -  if (ShenandoahOOMDuringEvacALot &&
>> -      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
>> +  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
>>          copy = nullptr;
>>    } else {
>>  #endif
>> 
>> 
>> This applies the failure only to worker threads and only when they are expected to suspend and only with a 1/1000 chance of failing for each evacuation. Without these fixes, the modification to `ShenandoahOOMDuringEvacALot` causes a deadlock in under two minutes of execution on [the extremem benchmark](https://github.com/corretto/heapothesys/tree/master/Extremem) with these additional diagnostic flags:
>> 
>> -XX:+SafepointALot -XX:+ShenandoahOOMDuringEvacALot -XX:ConcGCThreads=12 -XX:GuaranteedSafepointInterval=50
>> 
>> After these changes, the benchmark no longer deadlocks.
>> 
>> Additional testing includes jtreg `test/hotspot/jtreg:hotspot_gc_shenandoah`, the Dacapo benchmark suite, HyperAlloc and specjbb 2015.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1743:
> 
>> 1741: 
>> 1742: bool ShenandoahHeap::try_cancel_gc() {
>> 1743:   jbyte prev = _cancelled_gc.cmpxchg(CANCELLED, CANCELLABLE);
> 
> Is there even a need to CAS here? The transition here can only go from CANCELLABLE to CANCELLED, is that correct? If that is so, then the CAS would only fail if another thread made that transition before us. Is that a relevant scenario that we must know about, or could we simply store CANCELLED?

The boolean result of this method is used to have only one thread log the cancellation, create an entry in the event log and start the timer for tracking how long the cancellation takes. I think this is okay how it is. We could consider just CAS'ing a boolean instead of the enum, but the enum is arguably more readable.

> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 337:
> 
>> 335:           "end of concurrent marking.")                                     \
>> 336:                                                                             \
>> 337:   product(bool, ShenandoahSuspendibleWorkers, true, EXPERIMENTAL,           \
> 
> Given that turning this off would most likely result in correctness issues, or certainly will in the future when Lilliput arrives, we should consider removing this option altogether.

I agree - should be a separate PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1160989260
PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1160989917

From zgu at openjdk.org  Sat Apr  8 02:07:43 2023
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sat, 8 Apr 2023 02:07:43 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
 <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>
Message-ID: <SJVvacucQv5aQD7v1z4IZ9uApv-rN2m6u7YLHOl-2mY=.fc14e574-a4fd-497b-9b7c-4ac4fa44577a@github.com>

On Fri, 7 Apr 2023 20:05:14 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Given that I can't remember why we (I) did the complex transition in the first place, let's get rid of it and see what explodes (if anything). There's good chances that the original reasons are no longer relevant. We might even consider a more aggressive approach, see my comments (your call).

I did not follow the recent development closely. IIRC, the original reason for this complicated dance is that, if a thread encounters evacuation OOM and enters here, it needs to wait all other threads to exit EVAC OOM critical sections, before it can proceed, since another thread may evacuate the same oop successfully, therefore, this thread has to read forwarding pointer on its way out.

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

PR Comment: https://git.openjdk.org/jdk/pull/13309#issuecomment-1500762399

From avoitylov at openjdk.org  Mon Apr 10 09:00:43 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Mon, 10 Apr 2023 09:00:43 GMT
Subject: RFR: 8305663: Wrong iteration order of pause array in g1MMUTracker
In-Reply-To: <Gsd4Qu_7XEdWg77gpCU0AYrtFbCQUIdgXX1lDLTufuk=.4e0ce77a-e929-4b61-ac06-caad4ba3db04@github.com>
References: <3xa4tOTw8niU_BSOBRdFN-1U_XGFSkDpxq2XWdumJjg=.e28f2808-99a6-467e-825d-be7b40f6d6b9@github.com>
 <Gsd4Qu_7XEdWg77gpCU0AYrtFbCQUIdgXX1lDLTufuk=.4e0ce77a-e929-4b61-ac06-caad4ba3db04@github.com>
Message-ID: <JTB8HnvvJz2qWdanOiTvQHvfkpTOIyZiQZ3Oym0P8Z0=.278c0574-31d8-4e76-a48b-36936c2e3885@github.com>

On Thu, 6 Apr 2023 10:06:28 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> G1 pause _array is iterated from oldest pause to newer pause in order to calculate the pause budget, but it should be iterated in the opposite direction (newest to oldest).
>
> Thank you for finding this.

@albertnetymk could you sponsor this change? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/13370#issuecomment-1501573776

From ayang at openjdk.org  Tue Apr 11 09:57:44 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 11 Apr 2023 09:57:44 GMT
Subject: RFR: 8305060: G1: Refactor
 G1ScanHRForRegionClosure::scan_heap_roots [v2]
In-Reply-To: <CJTdUCoVlik-0IMU9xyouaiq7o1WM5pd2w_sZDUCP-A=.9baf5223-10fe-4f5c-bc8b-df4ef9c9ee94@github.com>
References: <CJTdUCoVlik-0IMU9xyouaiq7o1WM5pd2w_sZDUCP-A=.9baf5223-10fe-4f5c-bc8b-df4ef9c9ee94@github.com>
Message-ID: <rBKddEprv5V9fkLzIn7wj7PJ-_1d4LfXhYBFmJlIvhg=.5ad7846a-4831-46e6-80cc-81f273570fb2@github.com>

> Simple refactoring to separate out dirty-cards iteration logic from dirty-cards processing.
> 
> Test: tier1-6

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - review
 - g1-scan-card

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

Changes: https://git.openjdk.org/jdk/pull/13205/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13205&range=01
  Stats: 245 lines in 3 files changed: 99 ins; 121 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/13205.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13205/head:pull/13205

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

From tschatzl at openjdk.org  Tue Apr 11 16:03:40 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 11 Apr 2023 16:03:40 GMT
Subject: RFR: 8305663: Wrong iteration order of pause array in g1MMUTracker
In-Reply-To: <3xa4tOTw8niU_BSOBRdFN-1U_XGFSkDpxq2XWdumJjg=.e28f2808-99a6-467e-825d-be7b40f6d6b9@github.com>
References: <3xa4tOTw8niU_BSOBRdFN-1U_XGFSkDpxq2XWdumJjg=.e28f2808-99a6-467e-825d-be7b40f6d6b9@github.com>
Message-ID: <_I95ExLM30vHziQSPiJtHlSKTawb7i4zQWq8k7o2m5g=.e8484f24-080c-4fb6-a3ec-27bcb47ed21b@github.com>

On Thu, 6 Apr 2023 06:55:04 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> G1 pause _array is iterated from oldest pause to newer pause in order to calculate the pause budget, but it should be iterated in the opposite direction (newest to oldest).

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13370#pullrequestreview-1379627079

From tschatzl at openjdk.org  Tue Apr 11 16:06:41 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 11 Apr 2023 16:06:41 GMT
Subject: RFR: 8305368: G1 remset chunk claiming may use relaxed memory
 ordering
In-Reply-To: <ZOybe4ia50aFTYvaiSH1rFPJzPUHnCTzeb76uigMfMg=.94aa7379-9265-48c5-bd44-92bca7246380@github.com>
References: <ZOybe4ia50aFTYvaiSH1rFPJzPUHnCTzeb76uigMfMg=.94aa7379-9265-48c5-bd44-92bca7246380@github.com>
Message-ID: <PyuaoE4-I6RILyk7i7f6uQWmgqepTBflmpIJ5kEJAWk=.6780aa9e-0f3c-4fc2-85de-e2a50516f1e6@github.com>

On Fri, 31 Mar 2023 11:15:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this minor change that changes the atomic increment for claiming chunks during scanning remembered sets to use relaxed memory ordering.
> Nothing depends on that, and nothing should. No particular performance improvements (expected; on x86 all atomics are "conservative" anyway).
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Thanks for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/13266#issuecomment-1503681170

From avoitylov at openjdk.org  Tue Apr 11 16:06:54 2023
From: avoitylov at openjdk.org (Aleksei Voitylov)
Date: Tue, 11 Apr 2023 16:06:54 GMT
Subject: Integrated: 8305663: Wrong iteration order of pause array in
 g1MMUTracker
In-Reply-To: <3xa4tOTw8niU_BSOBRdFN-1U_XGFSkDpxq2XWdumJjg=.e28f2808-99a6-467e-825d-be7b40f6d6b9@github.com>
References: <3xa4tOTw8niU_BSOBRdFN-1U_XGFSkDpxq2XWdumJjg=.e28f2808-99a6-467e-825d-be7b40f6d6b9@github.com>
Message-ID: <tkFv8PdpFPi58l8rJ1ySoy1X0ejn8j1RGXGK_4vPhh0=.02c8c814-c7d3-4246-a272-2f99aa35de63@github.com>

On Thu, 6 Apr 2023 06:55:04 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> G1 pause _array is iterated from oldest pause to newer pause in order to calculate the pause budget, but it should be iterated in the opposite direction (newest to oldest).

This pull request has now been integrated.

Changeset: c6d7cf6b
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6d7cf6b4850db26db71f333fa00c4280d7b91f6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8305663: Wrong iteration order of pause array in g1MMUTracker

Reviewed-by: ayang, tschatzl

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

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

From tschatzl at openjdk.org  Tue Apr 11 16:07:55 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 11 Apr 2023 16:07:55 GMT
Subject: RFR: 8305370: Inconsistent use of for_young_only_phase parameter
 in G1 predictions
In-Reply-To: <I07nsaeAr8nCuXtYqxKQ85pxbeT-1lKL71PsJIx4fqU=.6c6f8dd9-5f21-4e23-93fe-92e35450cdf2@github.com>
References: <5kDZEtKFbNyHIg5CkIq9w6BmSKtEZQdR3LCDI8IkCmY=.924c6c12-1c1b-4fa3-8033-dd8fde358402@github.com>
 <I07nsaeAr8nCuXtYqxKQ85pxbeT-1lKL71PsJIx4fqU=.6c6f8dd9-5f21-4e23-93fe-92e35450cdf2@github.com>
Message-ID: <RDz9z5yoQ2KJC26ewDsB_yuAoOV-hCsZLFAn1MeFigw=.ccdcea0a-9525-419c-b23d-f2ba13bb9eef@github.com>

On Fri, 31 Mar 2023 14:55:33 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change to fix some inconsistent use of `for_young_only_phase`: some methods that require it are not passed that parameter, and some methods, although getting passed that parameter partially re-load that value from collector state.
>> 
>> Fwiw, I am aware that `G1Policy::predict_region_total_time_ms` only ever gets passed `false` as this parameter. I would have changed that as well if some [upcoming change](https://github.com/openjdk/jdk/commit/6c2f18eba29ad9f6e4e5ed28f1521037fdc49398) did not use other values as well. We can always remove it later if not necessary, but if somebody insists on doing so I will do that as well (probably separately).
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Lgtm!

Thanks @walulyai @kimbarrett for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/13267#issuecomment-1503678190

From tschatzl at openjdk.org  Tue Apr 11 16:07:57 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 11 Apr 2023 16:07:57 GMT
Subject: Integrated: 8305370: Inconsistent use of for_young_only_phase
 parameter in G1 predictions
In-Reply-To: <5kDZEtKFbNyHIg5CkIq9w6BmSKtEZQdR3LCDI8IkCmY=.924c6c12-1c1b-4fa3-8033-dd8fde358402@github.com>
References: <5kDZEtKFbNyHIg5CkIq9w6BmSKtEZQdR3LCDI8IkCmY=.924c6c12-1c1b-4fa3-8033-dd8fde358402@github.com>
Message-ID: <HPgZEFkfPIsfSCctHKag_CZerLIldJtH00lc-YM2SXE=.18e511e7-2eef-412b-b6fd-6d2eba83c8c9@github.com>

On Fri, 31 Mar 2023 11:19:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change to fix some inconsistent use of `for_young_only_phase`: some methods that require it are not passed that parameter, and some methods, although getting passed that parameter partially re-load that value from collector state.
> 
> Fwiw, I am aware that `G1Policy::predict_region_total_time_ms` only ever gets passed `false` as this parameter. I would have changed that as well if some [upcoming change](https://github.com/openjdk/jdk/commit/6c2f18eba29ad9f6e4e5ed28f1521037fdc49398) did not use other values as well. We can always remove it later if not necessary, but if somebody insists on doing so I will do that as well (probably separately).
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: c789d240
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c789d240390ce5436fdbc4adbc36f19551635944
Stats:     9 lines in 2 files changed: 2 ins; 0 del; 7 mod

8305370: Inconsistent use of for_young_only_phase parameter in G1 predictions

Reviewed-by: iwalulya, kbarrett

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

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

From tschatzl at openjdk.org  Tue Apr 11 16:09:45 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 11 Apr 2023 16:09:45 GMT
Subject: Integrated: 8305368: G1 remset chunk claiming may use relaxed memory
 ordering
In-Reply-To: <ZOybe4ia50aFTYvaiSH1rFPJzPUHnCTzeb76uigMfMg=.94aa7379-9265-48c5-bd44-92bca7246380@github.com>
References: <ZOybe4ia50aFTYvaiSH1rFPJzPUHnCTzeb76uigMfMg=.94aa7379-9265-48c5-bd44-92bca7246380@github.com>
Message-ID: <swUlUSMsBOtrl9CnGKQ7mtR06S9OIOBS1k-15L0gXZk=.599bc24d-478e-4372-90c8-73457c42784d@github.com>

On Fri, 31 Mar 2023 11:15:48 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this minor change that changes the atomic increment for claiming chunks during scanning remembered sets to use relaxed memory ordering.
> Nothing depends on that, and nothing should. No particular performance improvements (expected; on x86 all atomics are "conservative" anyway).
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: d9db9063
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d9db90636f246488bb9c10fd37daed024ce56267
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8305368: G1 remset chunk claiming may use relaxed memory ordering

Reviewed-by: ayang, iwalulya

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

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

From ayang at openjdk.org  Wed Apr 12 09:18:37 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 12 Apr 2023 09:18:37 GMT
Subject: RFR: 8305892: G1: Fix G1MMUTracker::when_sec documentation
Message-ID: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>

Trivial comment-only change.

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

Commit messages:
 - g1-mmu-doc

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

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

From kdnilsen at openjdk.org  Thu Apr 13 00:07:33 2023
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 13 Apr 2023 00:07:33 GMT
Subject: RFR: 8305716: Enhancements for printing age tables
In-Reply-To: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
References: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
Message-ID: <ukpbqrOqERYuR0FvWpo51Qq5usFgUaKZyBhiPpWfj5I=.99422b94-bf88-4ebb-a368-42451e32a7b4@github.com>

On Thu, 6 Apr 2023 18:18:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In order to reduce the number of changes for the upcoming PR for the generational mode for Shenandoah we are opening separate PRs for the changes in common code. Shenandoah will be using this `AgeTable` class. There are two changes here:
> * `AgeTables` created with global=false will no longer SEGV when printing
> * A method was added to allow the `AgeTable` to print to an existing output stream

Thanks for improved generality.

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

Marked as reviewed by kdnilsen (no project role).

PR Review: https://git.openjdk.org/jdk/pull/13377#pullrequestreview-1382302957

From wkemper at openjdk.org  Thu Apr 13 17:07:40 2023
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 13 Apr 2023 17:07:40 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <SJVvacucQv5aQD7v1z4IZ9uApv-rN2m6u7YLHOl-2mY=.fc14e574-a4fd-497b-9b7c-4ac4fa44577a@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
 <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>
 <SJVvacucQv5aQD7v1z4IZ9uApv-rN2m6u7YLHOl-2mY=.fc14e574-a4fd-497b-9b7c-4ac4fa44577a@github.com>
Message-ID: <g7btiHC85wlKDwdFgssUsDvScXCOrn6mHWJ7jOjRHx4=.b6cf7af5-ee73-43e0-833b-c0f50131be6d@github.com>

On Sat, 8 Apr 2023 02:04:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Given that I can't remember why we (I) did the complex transition in the first place, let's get rid of it and see what explodes (if anything). There's good chances that the original reasons are no longer relevant. We might even consider a more aggressive approach, see my comments (your call).
>
>> Given that I can't remember why we (I) did the complex transition in the first place, let's get rid of it and see what explodes (if anything). There's good chances that the original reasons are no longer relevant. We might even consider a more aggressive approach, see my comments (your call).
> 
> I did not follow the recent development closely. IIRC, the original reason for this complicated dance is that, if a thread encounters evacuation OOM and enters here, it needs to wait all other threads to exit EVAC OOM critical sections, before it can proceed, since another thread may evacuate the same oop successfully, therefore, this thread has to read forwarding pointer on its way out.

@zhengyu123 - The code that is meant to suspend threads when they oom-during-evac is still there. That protocol would take over _after_ the evacuating thread has cancelled the GC.

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

PR Comment: https://git.openjdk.org/jdk/pull/13309#issuecomment-1507306165

From ysr at openjdk.org  Fri Apr 14 18:09:34 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 14 Apr 2023 18:09:34 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
Message-ID: <Lq5ZeXAUklNX1qsB5TNmcGhJjTZcVYOyBZRCIJ_Vnig=.b47fbb9f-4a22-46d6-888f-8017e3144dda@github.com>

On Mon, 3 Apr 2023 21:45:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah evacuation workers may deadlock if a safepoint begins during concurrent evacuation _and_ a GC worker thread experiences an out of memory error during the evacuation.
> 
> This situation occurs because some of the workers have set the cancelled state to `NOT_CANCELLED` and then yielded to the suspendible thread set because a safepoint is starting. Other workers who then experience an OOM during evacuation attempt to transition the heap from `CANCELLABLE` to `CANCELLED` in a CAS loop that will never succeed (because the cancelled state is `NOT_CANCELLED`). These workers are unable to join the suspendible thread set, so the threads which have yielded are unable to resume and reset the heap to `CANCELLABLE`. The VM thread cannot enter the safepoint and eventually all of the mutator threads block when they are unable to allocate.
> 
> The changes here remove the `NOT_CANCELLED` state and remove the CAS loop used to transition from `CANCELLABLE` to `CANCELLED`. Additionally, worker threads that need to suspend no longer put the heap in the `NOT_CANCELLED` state before suspending.
> 
> In order to test this, the behavior of the diagnostic flag was modified to provoke this scenario:
> 
> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> index 4158f4bee22..e261dd3a81b 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> @@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
>    HeapWord* copy = nullptr;
>  
>  #ifdef ASSERT
> -  if (ShenandoahOOMDuringEvacALot &&
> -      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
> +  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
>          copy = nullptr;
>    } else {
>  #endif
> 
> 
> This applies the failure only to worker threads and only when they are expected to suspend and only with a 1/1000 chance of failing for each evacuation. Without these fixes, the modification to `ShenandoahOOMDuringEvacALot` causes a deadlock in under two minutes of execution on [the extremem benchmark](https://github.com/corretto/heapothesys/tree/master/Extremem) with these additional diagnostic flags:
> 
> -XX:+SafepointALot -XX:+ShenandoahOOMDuringEvacALot -XX:ConcGCThreads=12 -XX:GuaranteedSafepointInterval=50
> 
> After these changes, the benchmark no longer deadlocks.
> 
> Additional testing includes jtreg `test/hotspot/jtreg:hotspot_gc_shenandoah`, the Dacapo benchmark suite, HyperAlloc and specjbb 2015.

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13309#pullrequestreview-1385971522

From ysr at openjdk.org  Fri Apr 14 18:09:36 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 14 Apr 2023 18:09:36 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <g7btiHC85wlKDwdFgssUsDvScXCOrn6mHWJ7jOjRHx4=.b6cf7af5-ee73-43e0-833b-c0f50131be6d@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
 <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>
 <SJVvacucQv5aQD7v1z4IZ9uApv-rN2m6u7YLHOl-2mY=.fc14e574-a4fd-497b-9b7c-4ac4fa44577a@github.com>
 <g7btiHC85wlKDwdFgssUsDvScXCOrn6mHWJ7jOjRHx4=.b6cf7af5-ee73-43e0-833b-c0f50131be6d@github.com>
Message-ID: <k5sxvL9yEKs92KpOfV0dZE62TqrmRpbpNAssxLmjDMw=.f6f6a21d-50d1-4a1d-9bc0-9ee3f7b5ee41@github.com>

On Thu, 13 Apr 2023 17:03:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>>> Given that I can't remember why we (I) did the complex transition in the first place, let's get rid of it and see what explodes (if anything). There's good chances that the original reasons are no longer relevant. We might even consider a more aggressive approach, see my comments (your call).
>> 
>> I did not follow the recent development closely. IIRC, the original reason for this complicated dance is that, if a thread encounters evacuation OOM and enters here, it needs to wait all other threads to exit EVAC OOM critical sections, before it can proceed, since another thread may evacuate the same oop successfully, therefore, this thread has to read forwarding pointer on its way out.
>
> @zhengyu123 - The code that is meant to suspend threads when they oom-during-evac is still there. That protocol would take over _after_ the evacuating thread has cancelled the GC.

@earthling-amzn : The changes look fine to me. Is there a reason why this piece of code tat aided testing isn't in the PR:


diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
index 4158f4bee22..e261dd3a81b 100644
--- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
+++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
@@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
   HeapWord* copy = nullptr;
 
 #ifdef ASSERT
-  if (ShenandoahOOMDuringEvacALot &&
-      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
+  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
         copy = nullptr;
   } else {
 #endif



I'd change it to a general probability number specified via command-line rather than fixing it at 0.5.

Can you talk about stress- or soak-tests with the fix in place?

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

PR Comment: https://git.openjdk.org/jdk/pull/13309#issuecomment-1509035530

From ysr at openjdk.org  Fri Apr 14 18:09:38 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 14 Apr 2023 18:09:38 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <Qa6uDzVvv7uoKU1kLhKA1nHD7EWPuYhx-cg0CbawPKI=.e23dc615-280d-4db7-89da-9f3c17795faf@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
 <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>
 <Qa6uDzVvv7uoKU1kLhKA1nHD7EWPuYhx-cg0CbawPKI=.e23dc615-280d-4db7-89da-9f3c17795faf@github.com>
Message-ID: <BKHTme5lKrtouWhFfSZfbfcqrz9XMMS71Gqj6oFVhPI=.646cc116-dd5a-4873-8dd9-4c201bcbb2c3@github.com>

On Fri, 7 Apr 2023 22:00:05 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 337:
>> 
>>> 335:           "end of concurrent marking.")                                     \
>>> 336:                                                                             \
>>> 337:   product(bool, ShenandoahSuspendibleWorkers, true, EXPERIMENTAL,           \
>> 
>> Given that turning this off would most likely result in correctness issues, or certainly will in the future when Lilliput arrives, we should consider removing this option altogether.
>
> I agree - should be a separate PR?

I agree that removing the flag is a good idea. Anyone recall why it was put there in the first place?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1167147858

From ysr at openjdk.org  Fri Apr 14 18:15:34 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 14 Apr 2023 18:15:34 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
 <WxMoKT7KKTLUAwRurV8UiQww4J22zpb8I4G-hwFSbbY=.625f4a1e-4448-4914-8c50-6c9136ae8009@github.com>
Message-ID: <H8gYyW9JxwJHQ5EEiwqcnW3K03jL1za91lfIEf6pRag=.55688397-a048-4288-b07a-2a08df2fdfb3@github.com>

On Fri, 7 Apr 2023 20:03:22 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Shenandoah evacuation workers may deadlock if a safepoint begins during concurrent evacuation _and_ a GC worker thread experiences an out of memory error during the evacuation.
>> 
>> This situation occurs because some of the workers have set the cancelled state to `NOT_CANCELLED` and then yielded to the suspendible thread set because a safepoint is starting. Other workers who then experience an OOM during evacuation attempt to transition the heap from `CANCELLABLE` to `CANCELLED` in a CAS loop that will never succeed (because the cancelled state is `NOT_CANCELLED`). These workers are unable to join the suspendible thread set, so the threads which have yielded are unable to resume and reset the heap to `CANCELLABLE`. The VM thread cannot enter the safepoint and eventually all of the mutator threads block when they are unable to allocate.
>> 
>> The changes here remove the `NOT_CANCELLED` state and remove the CAS loop used to transition from `CANCELLABLE` to `CANCELLED`. Additionally, worker threads that need to suspend no longer put the heap in the `NOT_CANCELLED` state before suspending.
>> 
>> In order to test this, the behavior of the diagnostic flag was modified to provoke this scenario:
>> 
>> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
>> index 4158f4bee22..e261dd3a81b 100644
>> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
>> @@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
>>    HeapWord* copy = nullptr;
>>  
>>  #ifdef ASSERT
>> -  if (ShenandoahOOMDuringEvacALot &&
>> -      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
>> +  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
>>          copy = nullptr;
>>    } else {
>>  #endif
>> 
>> 
>> This applies the failure only to worker threads and only when they are expected to suspend and only with a 1/1000 chance of failing for each evacuation. Without these fixes, the modification to `ShenandoahOOMDuringEvacALot` causes a deadlock in under two minutes of execution on [the extremem benchmark](https://github.com/corretto/heapothesys/tree/master/Extremem) with these additional diagnostic flags:
>> 
>> -XX:+SafepointALot -XX:+ShenandoahOOMDuringEvacALot -XX:ConcGCThreads=12 -XX:GuaranteedSafepointInterval=50
>> 
>> After these changes, the benchmark no longer deadlocks.
>> 
>> Additional testing includes jtreg `test/hotspot/jtreg:hotspot_gc_shenandoah`, the Dacapo benchmark suite, HyperAlloc and specjbb 2015.
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 337:
> 
>> 335:           "end of concurrent marking.")                                     \
>> 336:                                                                             \
>> 337:   product(bool, ShenandoahSuspendibleWorkers, true, EXPERIMENTAL,           \
> 
> Given that turning this off would most likely result in correctness issues, or certainly will in the future when Lilliput arrives, we should consider removing this option altogether.

Separate PR would be preferred. At that time soak-test with value "off" to peek inside the pandora's box (which might be empty for all we know). Perhaps repeat the same experiment with Lilliput to see if it reveals the issues that @rkennke alludes to?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1167152925

From wkemper at openjdk.org  Fri Apr 14 18:48:38 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 14 Apr 2023 18:48:38 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
Message-ID: <6rD3UWxPAhPNzUHj-0ynHfdIIBVC2gq462ftPuj35gk=.215befc2-3993-4af4-89b4-2023355d996f@github.com>

On Mon, 3 Apr 2023 21:45:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah evacuation workers may deadlock if a safepoint begins during concurrent evacuation _and_ a GC worker thread experiences an out of memory error during the evacuation.
> 
> This situation occurs because some of the workers have set the cancelled state to `NOT_CANCELLED` and then yielded to the suspendible thread set because a safepoint is starting. Other workers who then experience an OOM during evacuation attempt to transition the heap from `CANCELLABLE` to `CANCELLED` in a CAS loop that will never succeed (because the cancelled state is `NOT_CANCELLED`). These workers are unable to join the suspendible thread set, so the threads which have yielded are unable to resume and reset the heap to `CANCELLABLE`. The VM thread cannot enter the safepoint and eventually all of the mutator threads block when they are unable to allocate.
> 
> The changes here remove the `NOT_CANCELLED` state and remove the CAS loop used to transition from `CANCELLABLE` to `CANCELLED`. Additionally, worker threads that need to suspend no longer put the heap in the `NOT_CANCELLED` state before suspending.
> 
> In order to test this, the behavior of the diagnostic flag was modified to provoke this scenario:
> 
> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> index 4158f4bee22..e261dd3a81b 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> @@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
>    HeapWord* copy = nullptr;
>  
>  #ifdef ASSERT
> -  if (ShenandoahOOMDuringEvacALot &&
> -      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
> +  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
>          copy = nullptr;
>    } else {
>  #endif
> 
> 
> This applies the failure only to worker threads and only when they are expected to suspend and only with a 1/1000 chance of failing for each evacuation. Without these fixes, the modification to `ShenandoahOOMDuringEvacALot` causes a deadlock in under two minutes of execution on [the extremem benchmark](https://github.com/corretto/heapothesys/tree/master/Extremem) with these additional diagnostic flags:
> 
> -XX:+SafepointALot -XX:+ShenandoahOOMDuringEvacALot -XX:ConcGCThreads=12 -XX:GuaranteedSafepointInterval=50
> 
> After these changes, the benchmark no longer deadlocks.
> 
> Additional testing includes jtreg `test/hotspot/jtreg:hotspot_gc_shenandoah`, the Dacapo benchmark suite, HyperAlloc and specjbb 2015.

>  Is there a reason why this piece of code that aided testing isn't in the PR

I felt it was too specific (only targeted worker threads that should suspend). I can add it to the PR. I would also like to change the `AllocFailALot` and `OOMDuringEvacALot` flags to express a percentage, but that would be a separate PR. (And might need a CSR?)

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

PR Comment: https://git.openjdk.org/jdk/pull/13309#issuecomment-1509075428

From wkemper at openjdk.org  Fri Apr 14 18:57:33 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 14 Apr 2023 18:57:33 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <a7NSpvOPe4a6UY9V2oMUegFB0bFksfoPv3iFCkXxrNs=.359d7e32-e623-4ab7-96d9-9bfbb0a8d7a0@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
 <45m2fsS2wK9nep_UCyCXZzxJcK703ShFSXQpsB81_ys=.546f74a2-42c3-4956-b933-517206707888@github.com>
 <a7NSpvOPe4a6UY9V2oMUegFB0bFksfoPv3iFCkXxrNs=.359d7e32-e623-4ab7-96d9-9bfbb0a8d7a0@github.com>
Message-ID: <qMIsk5TRzJMeI9HwCkf6Uoc_4PrixmWIHqF9EWNzokY=.58e3848d-fe3c-4938-9eb7-9a36c9aa1632@github.com>

On Mon, 3 Apr 2023 23:59:53 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 337:
>> 
>>> 335:           "end of concurrent marking.")                                     \
>>> 336:                                                                             \
>>> 337:   product(bool, ShenandoahSuspendibleWorkers, true, EXPERIMENTAL,           \
>> 
>> Can we provide some more information under help as to why workers should or should not be suspendible?
>
> I would like to know this myself ;) There are phases of class unloading that unconditionally suspend the control and worker threads. It's not clear to me why marking or evacuation threads would need to suspend.

There is a discussion of this feature in the archives: https://mail.openjdk.org/pipermail/shenandoah-dev/2017-May/002559.html

It seems that suspending worker threads is intended to avoid interfering with other safepoint operations that might not behave well if objects are being moved around the heap. I believe the flag was enabled by mistake when concurrent class unloading was implemented (concurrent class unloading unconditionally participates in STS and does not read this flag). That being said, this has been the default behavior for many years and - apart from this deadlock - I can see no reason for turning it off. That discussion is many years old now and many changes around full GC and code cache scanning/sweeping have transpired. As @rkennke said:

> There's good chances that the original reasons are no longer relevant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13309#discussion_r1167185840

From wkemper at openjdk.org  Fri Apr 14 20:40:42 2023
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 14 Apr 2023 20:40:42 GMT
Subject: Integrated: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
Message-ID: <YlAZBpNRwVrWUAJ4bzr6OpnhFNjW0uT0JYTO39xmcUA=.c71d9393-8431-492f-acd9-1e19ef4e9caa@github.com>

On Mon, 3 Apr 2023 21:45:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Shenandoah evacuation workers may deadlock if a safepoint begins during concurrent evacuation _and_ a GC worker thread experiences an out of memory error during the evacuation.
> 
> This situation occurs because some of the workers have set the cancelled state to `NOT_CANCELLED` and then yielded to the suspendible thread set because a safepoint is starting. Other workers who then experience an OOM during evacuation attempt to transition the heap from `CANCELLABLE` to `CANCELLED` in a CAS loop that will never succeed (because the cancelled state is `NOT_CANCELLED`). These workers are unable to join the suspendible thread set, so the threads which have yielded are unable to resume and reset the heap to `CANCELLABLE`. The VM thread cannot enter the safepoint and eventually all of the mutator threads block when they are unable to allocate.
> 
> The changes here remove the `NOT_CANCELLED` state and remove the CAS loop used to transition from `CANCELLABLE` to `CANCELLED`. Additionally, worker threads that need to suspend no longer put the heap in the `NOT_CANCELLED` state before suspending.
> 
> In order to test this, the behavior of the diagnostic flag was modified to provoke this scenario:
> 
> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> index 4158f4bee22..e261dd3a81b 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
> @@ -292,8 +292,7 @@ inline oop ShenandoahHeap::evacuate_object(oop p, Thread* thread) {
>    HeapWord* copy = nullptr;
>  
>  #ifdef ASSERT
> -  if (ShenandoahOOMDuringEvacALot &&
> -      (os::random() & 1) == 0) { // Simulate OOM every ~2nd slow-path call
> +  if (ShenandoahOOMDuringEvacALot && thread->is_Worker_thread() && SuspendibleThreadSet::should_yield() && uint(os::random()) % 1000 < 1) {
>          copy = nullptr;
>    } else {
>  #endif
> 
> 
> This applies the failure only to worker threads and only when they are expected to suspend and only with a 1/1000 chance of failing for each evacuation. Without these fixes, the modification to `ShenandoahOOMDuringEvacALot` causes a deadlock in under two minutes of execution on [the extremem benchmark](https://github.com/corretto/heapothesys/tree/master/Extremem) with these additional diagnostic flags:
> 
> -XX:+SafepointALot -XX:+ShenandoahOOMDuringEvacALot -XX:ConcGCThreads=12 -XX:GuaranteedSafepointInterval=50
> 
> After these changes, the benchmark no longer deadlocks.
> 
> Additional testing includes jtreg `test/hotspot/jtreg:hotspot_gc_shenandoah`, the Dacapo benchmark suite, HyperAlloc and specjbb 2015.

This pull request has now been integrated.

Changeset: 793da60e
Author:    William Kemper <wkemper at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/793da60ee833d09db0f6f14b50a7cbd7f4549e3b
Stats:     39 lines in 6 files changed: 1 ins; 33 del; 5 mod

8305403: Shenandoah evacuation workers may deadlock

Reviewed-by: rkennke, ysr

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

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

From ysr at openjdk.org  Fri Apr 14 20:58:45 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 14 Apr 2023 20:58:45 GMT
Subject: RFR: 8305403: Shenandoah evacuation workers may deadlock
In-Reply-To: <6rD3UWxPAhPNzUHj-0ynHfdIIBVC2gq462ftPuj35gk=.215befc2-3993-4af4-89b4-2023355d996f@github.com>
References: <vwvgq7Kwd4oF57yRdkO1OkFEgj0PddeucifgupMh8fM=.96f0935d-ff5f-4d4e-9173-6b02d9ebebd6@github.com>
 <6rD3UWxPAhPNzUHj-0ynHfdIIBVC2gq462ftPuj35gk=.215befc2-3993-4af4-89b4-2023355d996f@github.com>
Message-ID: <nWfiUgPe366hQvtu8uCMzUgsMLjyryGKpHW6T7cDEt8=.230076f4-c3cf-4566-bcfc-f3079ec36b75@github.com>

On Fri, 14 Apr 2023 18:45:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> I felt it was too specific (only targeted worker threads that should suspend). I can add it to the PR. I would also like to change the `AllocFailALot` and `OOMDuringEvacALot` flags to express a percentage, but that would be a separate PR. (And might need a CSR?)

Yes, a separate PR makes sense. These are all diagnostic, as would the probability option you would introduce, so I can't imagine it should need a CSR. But I could be wrong.

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

PR Comment: https://git.openjdk.org/jdk/pull/13309#issuecomment-1509250934

From ysr at openjdk.org  Sat Apr 15 00:36:31 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 15 Apr 2023 00:36:31 GMT
Subject: RFR: 8305716: Enhancements for printing age tables
In-Reply-To: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
References: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
Message-ID: <JZJj2FOFb2-mbKHsL1q_rZPRKhflPhziqTpn1z-w9C0=.01ca212f-e380-4e0d-977b-65673d9372d4@github.com>

On Thu, 6 Apr 2023 18:18:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In order to reduce the number of changes for the upcoming PR for the generational mode for Shenandoah we are opening separate PRs for the changes in common code. Shenandoah will be using this `AgeTable` class. There are two changes here:
> * `AgeTables` created with global=false will no longer SEGV when printing
> * A method was added to allow the `AgeTable` to print to an existing output stream

LGTM ... ?

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

Marked as reviewed by ysr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13377#pullrequestreview-1386278302

From iwalulya at openjdk.org  Mon Apr 17 08:43:46 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 17 Apr 2023 08:43:46 GMT
Subject: RFR: 8305060: G1: Refactor
 G1ScanHRForRegionClosure::scan_heap_roots [v2]
In-Reply-To: <rBKddEprv5V9fkLzIn7wj7PJ-_1d4LfXhYBFmJlIvhg=.5ad7846a-4831-46e6-80cc-81f273570fb2@github.com>
References: <CJTdUCoVlik-0IMU9xyouaiq7o1WM5pd2w_sZDUCP-A=.9baf5223-10fe-4f5c-bc8b-df4ef9c9ee94@github.com>
 <rBKddEprv5V9fkLzIn7wj7PJ-_1d4LfXhYBFmJlIvhg=.5ad7846a-4831-46e6-80cc-81f273570fb2@github.com>
Message-ID: <ZEANRRyPTdJy-rd8uhSOjg4LilwFZsjucUi8WIDz01o=.18143a22-2b52-40ad-9c5d-ff39c73b320a@github.com>

On Tue, 11 Apr 2023 09:57:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to separate out dirty-cards iteration logic from dirty-cards processing.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - review
>  - g1-scan-card

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13205#pullrequestreview-1387554723

From iwalulya at openjdk.org  Mon Apr 17 09:10:18 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 17 Apr 2023 09:10:18 GMT
Subject: RFR: 8305233: G1: Refactor G1ClearCardTableTask [v2]
In-Reply-To: <YAm4XWhr9H2Wn7e9aZlXA8Z5mH3f1tuPf4_bJVdrNac=.797e9d5c-fde0-4ab7-b180-b56688bc1a8a@github.com>
References: <84PkR6zsKATa8OU1r0DC4Yf_i97MBIQDKPISuWOLeAA=.07203beb-294c-424d-8fa0-f6a56ad4fbf0@github.com>
 <YAm4XWhr9H2Wn7e9aZlXA8Z5mH3f1tuPf4_bJVdrNac=.797e9d5c-fde0-4ab7-b180-b56688bc1a8a@github.com>
Message-ID: <IOh7qja15ltm9sJZlueaJ_5Xt89vIsiRUsz_HgXVx3o=.44ca802e-cfb3-49e0-80ef-5753b7494eec@github.com>

On Tue, 4 Apr 2023 10:19:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring for better encapsulation.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1RemSet.cpp
>   
>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13242#pullrequestreview-1387601079

From iwalulya at openjdk.org  Mon Apr 17 10:03:31 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 17 Apr 2023 10:03:31 GMT
Subject: RFR: 8305892: G1: Fix G1MMUTracker::when_sec documentation
In-Reply-To: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
References: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
Message-ID: <DhGh9FS7pYZ7uWPW6fQ4dtMYuwq8S2o-tyPM9-CtZIs=.3637518d-ef51-4fe0-ad8b-797b9ffbba88@github.com>

On Wed, 12 Apr 2023 09:11:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial comment-only change.

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13441#pullrequestreview-1387694693

From iwalulya at openjdk.org  Mon Apr 17 10:03:40 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 17 Apr 2023 10:03:40 GMT
Subject: RFR: 8305192: serial GC fails
 "assert(Universe::on_page_boundary(bottom) && Universe::on_page_boundary(end))
 failed: invalid space boundaries"
In-Reply-To: <IX3fc0tcEVcRV0nfzm7xb9Bq_76rGYXPSedOVGfBMj8=.b5b7fa3c-31f1-42ac-8820-79e640d0fcfb@github.com>
References: <IX3fc0tcEVcRV0nfzm7xb9Bq_76rGYXPSedOVGfBMj8=.b5b7fa3c-31f1-42ac-8820-79e640d0fcfb@github.com>
Message-ID: <yxKf9CwTKStd7O3ViHYQUSmNUPiehn5O9ecFYPIkBFs=.d3260365-af1f-47c3-91f4-4e73934d5ea1@github.com>

On Tue, 4 Apr 2023 10:11:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Fix to ensure survivor-space is properly aligned.
> 
> (I tried to reproduce the failure on master but to no avail.)
> 
> Test: tier1-6

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13323#pullrequestreview-1387693729

From tschatzl at openjdk.org  Mon Apr 17 10:30:33 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 10:30:33 GMT
Subject: RFR: 8305892: G1: Fix G1MMUTracker::when_sec documentation
In-Reply-To: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
References: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
Message-ID: <GBG5u-bDZSYnTr7OmTaDkUtt22M-nCdWT11I79D4g6k=.92ae0baf-818e-410a-8b24-f70af1827396@github.com>

On Wed, 12 Apr 2023 09:11:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial comment-only change.

Lgtm and trivial. Fwiw I fixed one additional typo.

src/hotspot/share/gc/g1/g1MMUTracker.cpp line 137:

> 135: // Next, return `balance_timestamp - limit`.
> 136: //
> 137: // When there are no enough GC events, i.e. we have a surplus budget, a new GC

Suggestion:

// When there are not enough GC events, i.e. we have a surplus budget, a new GC

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13441#pullrequestreview-1387736814
PR Review Comment: https://git.openjdk.org/jdk/pull/13441#discussion_r1168486471

From tschatzl at openjdk.org  Mon Apr 17 10:32:33 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 10:32:33 GMT
Subject: RFR: 8305716: Enhancements for printing age tables
In-Reply-To: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
References: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
Message-ID: <Ah4G56DwC7KeG9g7LBElQ6zgsRpRg5jmraQB8TmRujE=.5e9bf587-d187-40a0-8174-c2b97b52ac99@github.com>

On Thu, 6 Apr 2023 18:18:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In order to reduce the number of changes for the upcoming PR for the generational mode for Shenandoah we are opening separate PRs for the changes in common code. Shenandoah will be using this `AgeTable` class. There are two changes here:
> * `AgeTables` created with global=false will no longer SEGV when printing
> * A method was added to allow the `AgeTable` to print to an existing output stream

src/hotspot/share/gc/shared/ageTable.cpp line 118:

> 116: void AgeTable::print_on(outputStream* st, uint tenuring_threshold) {
> 117:   st->print_cr("Age table with threshold %u (max threshold " UINTX_FORMAT ")",
> 118:            tenuring_threshold, MaxTenuringThreshold);

Suggestion:

  st->print_cr("Age table with threshold %u (max threshold " UINTX_FORMAT ")",
               tenuring_threshold, MaxTenuringThreshold);

arguments should be aligned after the bracket above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13377#discussion_r1168490409

From tschatzl at openjdk.org  Mon Apr 17 10:36:35 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 10:36:35 GMT
Subject: RFR: 8305716: Enhancements for printing age tables
In-Reply-To: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
References: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
Message-ID: <Hb9SOSbau0-RfMvzNlXxM7RbEz8W9m6JeeszDq-lNv8=.29898bd6-de08-4abd-ab0e-464c23297498@github.com>

On Thu, 6 Apr 2023 18:18:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In order to reduce the number of changes for the upcoming PR for the generational mode for Shenandoah we are opening separate PRs for the changes in common code. Shenandoah will be using this `AgeTable` class. There are two changes here:
> * `AgeTables` created with global=false will no longer SEGV when printing
> * A method was added to allow the `AgeTable` to print to an existing output stream

Lgtm.
Please fix that indentation issue before pushing.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13377#pullrequestreview-1387748113

From tschatzl at openjdk.org  Mon Apr 17 10:40:32 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 10:40:32 GMT
Subject: RFR: 8305192: serial GC fails
 "assert(Universe::on_page_boundary(bottom) && Universe::on_page_boundary(end))
 failed: invalid space boundaries"
In-Reply-To: <IX3fc0tcEVcRV0nfzm7xb9Bq_76rGYXPSedOVGfBMj8=.b5b7fa3c-31f1-42ac-8820-79e640d0fcfb@github.com>
References: <IX3fc0tcEVcRV0nfzm7xb9Bq_76rGYXPSedOVGfBMj8=.b5b7fa3c-31f1-42ac-8820-79e640d0fcfb@github.com>
Message-ID: <f0JmbiNhovnc3SaA4_Jxg_vD0vaw6aenLiPNsBBKOCQ=.4a026867-b56e-4e0d-ab8c-e51dc089dea4@github.com>

On Tue, 4 Apr 2023 10:11:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Fix to ensure survivor-space is properly aligned.
> 
> (I tried to reproduce the failure on master but to no avail.)
> 
> Test: tier1-6

Lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13323#pullrequestreview-1387754552

From tschatzl at openjdk.org  Mon Apr 17 11:42:40 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 11:42:40 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v4]
In-Reply-To: <rFa1iMDrYusC6zj9ivLTp2yGRtW8nMVmqW2WmGrB9NY=.9a3c99e9-8965-421a-a970-94fbe5c59276@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <rFa1iMDrYusC6zj9ivLTp2yGRtW8nMVmqW2WmGrB9NY=.9a3c99e9-8965-421a-a970-94fbe5c59276@github.com>
Message-ID: <b5xTq50nz5_a2-rb3olJfpKxvTxLxvaKnXflw3G2784=.0578e341-662d-46c1-bba7-6f331176e642@github.com>

On Mon, 3 Apr 2023 15:28:58 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi All,
>> 
>> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
>> 
>> The change should also handle the issues reported in JDK-8299276.
>> 
>> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
>> 
>> Testing: Tier 1-5.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review

Marked as reviewed by tschatzl (Reviewer).

src/hotspot/share/gc/parallel/psVMOperations.hpp line 48:

> 46:   virtual VMOp_Type type() const { return VMOp_ParallelGCSystemGC; }
> 47:   virtual void doit();
> 48:   bool full_gc_succeeded() const { return _full_gc_succeeded; }

Could we name this `gc_succeeded` like in g1?

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

PR Review: https://git.openjdk.org/jdk/pull/13191#pullrequestreview-1387778224
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1168514044

From tschatzl at openjdk.org  Mon Apr 17 11:42:41 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 11:42:41 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v3]
In-Reply-To: <K2WeZOH8UTdHOwVDScOwRyQdDzTPBJ7j9mM4lzgCpeI=.285717b8-33af-4033-a8f6-d7d2fc316507@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <jWUmmE9UYlyycfGkh2QTzoOMqNQ0VokFKsbaRInqMOg=.298383db-c212-484a-9504-436f28cd4f7c@github.com>
 <ym8xgm2ISYlC3jOnFi9SCSMhU8HIhf4-8nAMzqHk7uk=.b0fd532c-e6d6-44c1-be3f-571e702a48b6@github.com>
 <9zmgeFOR8j65eMJs1x5kukI6T8UlJz5aW31ySmluKWk=.48b62697-1ff0-4816-861e-3326d3392a20@github.com>
 <PAhB-hj-p_hpozkIA1wzz_KulqI-sK50Wc1Ge5nxTEA=.887f3ae2-d121-4b61-9261-992d14122677@github.com>
 <K2WeZOH8UTdHOwVDScOwRyQdDzTPBJ7j9mM4lzgCpeI=.285717b8-33af-4033-a8f6-d7d2fc316507@github.com>
Message-ID: <kGHOqbPuccDtLUcRk44C_xqo18M2eOyWmUCcLqtRPos=.a5d16c7a-c85a-4415-9f4d-bc9fde045ef4@github.com>

On Thu, 30 Mar 2023 13:43:42 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> True, but this is not a perf-critical method, be consistent (with other gcs) is more important, IMO.
>
> Only Serial doesn't have this early return, and only reason I didn't add it is because PR was getting too big and serial required a lot more changes to have this implemented. So i think It will added later for Serial GC.

Please file an issue for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1168558319

From tschatzl at openjdk.org  Mon Apr 17 11:42:43 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 11:42:43 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v4]
In-Reply-To: <xn8uUu41-V8lDk5P-hcwujxflepXWri88CVjF0Q1CyY=.33f84683-516f-4d41-ac99-28d7fa726a3d@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <g3NSN9vcPPgHFUFbimwzId0oLFdfpYy3OpG7ssERg2E=.020a1465-0fe6-4387-84e2-49296b38bcc9@github.com>
 <sIgI1WFEnF036WuEgB2FZd6NolvKuI5OSMiCCbI1xzU=.2e30b95e-8d8a-47c2-8287-b9d83399e8c9@github.com>
 <gtn5Osese2FWJXkNfDo0AeJZypTxfc-ZPKa5SUS6ZXc=.7d1c20a1-d420-4f1b-a045-fd3cfd379b45@github.com>
 <xn8uUu41-V8lDk5P-hcwujxflepXWri88CVjF0Q1CyY=.33f84683-516f-4d41-ac99-28d7fa726a3d@github.com>
Message-ID: <LLu5_Sh8Czkpjs12fQi4LyrexrdTv_ahZyss67nqEgk=.57161848-a5f8-4530-b311-e29823ba976b@github.com>

On Tue, 28 Mar 2023 18:26:06 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> I don't get why having an alloc thread would improve/degrade the robustness of this test -- jni-call-thread and systemgc-thread should be enough.
>
> The allocations trigger GCLocker Initiated GCs, so I prefer to keep them.

Please add a comment that this is intentional to increase the variety of the GC types that can happen here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1168557820

From tschatzl at openjdk.org  Mon Apr 17 11:44:35 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 11:44:35 GMT
Subject: RFR: 8305060: G1: Refactor
 G1ScanHRForRegionClosure::scan_heap_roots [v2]
In-Reply-To: <rBKddEprv5V9fkLzIn7wj7PJ-_1d4LfXhYBFmJlIvhg=.5ad7846a-4831-46e6-80cc-81f273570fb2@github.com>
References: <CJTdUCoVlik-0IMU9xyouaiq7o1WM5pd2w_sZDUCP-A=.9baf5223-10fe-4f5c-bc8b-df4ef9c9ee94@github.com>
 <rBKddEprv5V9fkLzIn7wj7PJ-_1d4LfXhYBFmJlIvhg=.5ad7846a-4831-46e6-80cc-81f273570fb2@github.com>
Message-ID: <UMRzzOITBinFRscQQyDfmN3m1v6OnmSpH3uIcF4PPRA=.f0ea92a2-1d50-4ea1-a80c-536011e76d25@github.com>

On Tue, 11 Apr 2023 09:57:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to separate out dirty-cards iteration logic from dirty-cards processing.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - review
>  - g1-scan-card

Seem still good.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13205#pullrequestreview-1387848607

From ayang at openjdk.org  Mon Apr 17 12:00:39 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 12:00:39 GMT
Subject: RFR: 8305233: G1: Refactor G1ClearCardTableTask [v2]
In-Reply-To: <YAm4XWhr9H2Wn7e9aZlXA8Z5mH3f1tuPf4_bJVdrNac=.797e9d5c-fde0-4ab7-b180-b56688bc1a8a@github.com>
References: <84PkR6zsKATa8OU1r0DC4Yf_i97MBIQDKPISuWOLeAA=.07203beb-294c-424d-8fa0-f6a56ad4fbf0@github.com>
 <YAm4XWhr9H2Wn7e9aZlXA8Z5mH3f1tuPf4_bJVdrNac=.797e9d5c-fde0-4ab7-b180-b56688bc1a8a@github.com>
Message-ID: <edJgEl80JZeUfQs1a44ziNsKhGxESTOZlL2bt05FLjk=.55cb9ace-c73a-44a9-96e6-a15f5ea68a04@github.com>

On Tue, 4 Apr 2023 10:19:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring for better encapsulation.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/hotspot/share/gc/g1/g1RemSet.cpp
>   
>   Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13242#issuecomment-1511204005

From ayang at openjdk.org  Mon Apr 17 12:03:47 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 12:03:47 GMT
Subject: Integrated: 8305233: G1: Refactor G1ClearCardTableTask
In-Reply-To: <84PkR6zsKATa8OU1r0DC4Yf_i97MBIQDKPISuWOLeAA=.07203beb-294c-424d-8fa0-f6a56ad4fbf0@github.com>
References: <84PkR6zsKATa8OU1r0DC4Yf_i97MBIQDKPISuWOLeAA=.07203beb-294c-424d-8fa0-f6a56ad4fbf0@github.com>
Message-ID: <GDi7WQuuroGkNzQ_CBB8WfIN7OhRT0AZ2zqAkVhAieE=.9154ad46-49b0-4810-bf38-daa21357b840@github.com>

On Thu, 30 Mar 2023 10:38:29 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring for better encapsulation.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 1958f0e8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1958f0e8bdda3b8aba88f1d3d623ffcf1be31aa8
Stats:     23 lines in 1 file changed: 6 ins; 13 del; 4 mod

8305233: G1: Refactor G1ClearCardTableTask

Reviewed-by: tschatzl, iwalulya

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

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

From ayang at openjdk.org  Mon Apr 17 12:04:38 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 12:04:38 GMT
Subject: RFR: 8305892: G1: Fix G1MMUTracker::when_sec documentation [v2]
In-Reply-To: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
References: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
Message-ID: <HeL7xpRJsnLTzur65CCnPJOBImapVtTGENaXG3SgpGA=.e85cc608-9f80-493f-914c-c2fb5b9866dc@github.com>

> Trivial comment-only change.

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/share/gc/g1/g1MMUTracker.cpp
  
  Co-authored-by: Thomas Schatzl <59967451+tschatzl at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13441/files
  - new: https://git.openjdk.org/jdk/pull/13441/files/2ed8c5b5..27148306

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

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

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

From ayang at openjdk.org  Mon Apr 17 12:04:39 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 12:04:39 GMT
Subject: RFR: 8305892: G1: Fix G1MMUTracker::when_sec documentation
In-Reply-To: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
References: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
Message-ID: <z-mjXf3dL9NCC7hQj_43uLGn_O8tTYq81NaPXptxTmI=.cc35bbb0-9350-4ca5-872f-b42fe84a4373@github.com>

On Wed, 12 Apr 2023 09:11:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial comment-only change.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13441#issuecomment-1511203242

From ayang at openjdk.org  Mon Apr 17 12:04:40 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 12:04:40 GMT
Subject: Integrated: 8305892: G1: Fix G1MMUTracker::when_sec documentation
In-Reply-To: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
References: <XJ1C7BM7r6fIwmV99OwYYKQ_qlJXGC3U_RvftLbc35U=.45b9ea96-0c57-4cb7-a728-0c92e42d974b@github.com>
Message-ID: <wzuhAJiyVgqyfukZQIFhCordWw267-lviiWTn74d2PA=.d8db8e9c-3001-480f-a7ab-33b0b6a374df@github.com>

On Wed, 12 Apr 2023 09:11:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial comment-only change.

This pull request has now been integrated.

Changeset: dbd2b5f8
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbd2b5f89f10c6650c302abe2858f1e426c98ae4
Stats:     8 lines in 1 file changed: 0 ins; 0 del; 8 mod

8305892: G1: Fix G1MMUTracker::when_sec documentation

Reviewed-by: iwalulya, tschatzl

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

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

From ayang at openjdk.org  Mon Apr 17 12:26:51 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 12:26:51 GMT
Subject: RFR: 8305192: serial GC fails
 "assert(Universe::on_page_boundary(bottom) && Universe::on_page_boundary(end))
 failed: invalid space boundaries"
In-Reply-To: <IX3fc0tcEVcRV0nfzm7xb9Bq_76rGYXPSedOVGfBMj8=.b5b7fa3c-31f1-42ac-8820-79e640d0fcfb@github.com>
References: <IX3fc0tcEVcRV0nfzm7xb9Bq_76rGYXPSedOVGfBMj8=.b5b7fa3c-31f1-42ac-8820-79e640d0fcfb@github.com>
Message-ID: <iCLlXpQt6RG2isM4KgI8T_JFNKfo3LMAEELQEDPyoqQ=.7a4d68d1-b04c-4420-95e3-ffa69bb6ca4a@github.com>

On Tue, 4 Apr 2023 10:11:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Fix to ensure survivor-space is properly aligned.
> 
> (I tried to reproduce the failure on master but to no avail.)
> 
> Test: tier1-6

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13323#issuecomment-1511238231

From ayang at openjdk.org  Mon Apr 17 12:26:51 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 12:26:51 GMT
Subject: Integrated: 8305192: serial GC fails
 "assert(Universe::on_page_boundary(bottom) && Universe::on_page_boundary(end))
 failed: invalid space boundaries"
In-Reply-To: <IX3fc0tcEVcRV0nfzm7xb9Bq_76rGYXPSedOVGfBMj8=.b5b7fa3c-31f1-42ac-8820-79e640d0fcfb@github.com>
References: <IX3fc0tcEVcRV0nfzm7xb9Bq_76rGYXPSedOVGfBMj8=.b5b7fa3c-31f1-42ac-8820-79e640d0fcfb@github.com>
Message-ID: <OJwRbpkWb47dFwp4E3LopP0QoFB6lp5TAn_jAPcL3gE=.6ec597fb-0416-41e8-b047-5209c321a91a@github.com>

On Tue, 4 Apr 2023 10:11:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Fix to ensure survivor-space is properly aligned.
> 
> (I tried to reproduce the failure on master but to no avail.)
> 
> Test: tier1-6

This pull request has now been integrated.

Changeset: fb58d77e
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fb58d77e92caf15eada69d32f662d63758927701
Stats:     6 lines in 1 file changed: 4 ins; 0 del; 2 mod

8305192: serial GC fails "assert(Universe::on_page_boundary(bottom) && Universe::on_page_boundary(end)) failed: invalid space boundaries"

Reviewed-by: iwalulya, tschatzl

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

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

From ayang at openjdk.org  Mon Apr 17 12:27:34 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 12:27:34 GMT
Subject: RFR: 8305060: G1: Refactor
 G1ScanHRForRegionClosure::scan_heap_roots [v2]
In-Reply-To: <rBKddEprv5V9fkLzIn7wj7PJ-_1d4LfXhYBFmJlIvhg=.5ad7846a-4831-46e6-80cc-81f273570fb2@github.com>
References: <CJTdUCoVlik-0IMU9xyouaiq7o1WM5pd2w_sZDUCP-A=.9baf5223-10fe-4f5c-bc8b-df4ef9c9ee94@github.com>
 <rBKddEprv5V9fkLzIn7wj7PJ-_1d4LfXhYBFmJlIvhg=.5ad7846a-4831-46e6-80cc-81f273570fb2@github.com>
Message-ID: <g0cb1JfdrOViPXoKdrhXVeuX24virA_Mp_v6BP5e7js=.bfb069b8-cd41-472b-aab2-02981691d22f@github.com>

On Tue, 11 Apr 2023 09:57:44 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to separate out dirty-cards iteration logic from dirty-cards processing.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - review
>  - g1-scan-card

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13205#issuecomment-1511242789

From ayang at openjdk.org  Mon Apr 17 12:30:47 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 12:30:47 GMT
Subject: Integrated: 8305060: G1: Refactor
 G1ScanHRForRegionClosure::scan_heap_roots
In-Reply-To: <CJTdUCoVlik-0IMU9xyouaiq7o1WM5pd2w_sZDUCP-A=.9baf5223-10fe-4f5c-bc8b-df4ef9c9ee94@github.com>
References: <CJTdUCoVlik-0IMU9xyouaiq7o1WM5pd2w_sZDUCP-A=.9baf5223-10fe-4f5c-bc8b-df4ef9c9ee94@github.com>
Message-ID: <n22yOan8grVKDLkfyLiGxqQ4Izqb1amsDp-nQId9kqA=.823344db-af30-4fdd-b2bd-26722a294692@github.com>

On Tue, 28 Mar 2023 09:48:34 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to separate out dirty-cards iteration logic from dirty-cards processing.
> 
> Test: tier1-6

This pull request has now been integrated.

Changeset: cc60f2ff
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc60f2ff3f16bdb04917e09cb87f09bd544f1f8b
Stats:     245 lines in 3 files changed: 99 ins; 121 del; 25 mod

8305060: G1: Refactor G1ScanHRForRegionClosure::scan_heap_roots

Reviewed-by: tschatzl, iwalulya

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

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

From tschatzl at openjdk.org  Mon Apr 17 13:45:49 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 13:45:49 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region
In-Reply-To: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
Message-ID: <SsgzdCdeW6GsJym-CJVSnW1OgJ6fw8LcE01VaYZdYU8=.386ab41c-0cc6-4ea2-a159-0b328c1e09f3@github.com>

On Tue, 28 Mar 2023 09:59:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
> 
> Test: tier1-6

The change is okay.

In some way I would have preferred a larger refactoring:
* keeping both `_covered` and `_committed` seems unnecessary; the latter can always be calculated from the former (easily, with negligible overhead since we are committing there), so it seems to be somewhat of a waste of space. 
* `_committed` seems to be only ever actually used in `CardTable::resize_covered_region` too.
* `CardTable::resize_covered_region` requires that the given region start at either of the two covered regions, but still allows passing an arbitrary region. Maybe some more specialization just for a serial/parallel gc card table would be nice as it's only used by them. In that sense, the `initialize()` method also seems to be specific to serial/parallel.

None of that necessary in context of this particular change, it does improve the code. Maybe something to record in the bug tracker.

src/hotspot/share/gc/shared/cardTable.cpp line 77:

> 75:   _byte_map_base(nullptr),
> 76:   _covered(MemRegion::create_array(_max_covered_regions, mtGC)),
> 77:   _committed(MemRegion::create_array(_max_covered_regions, mtGC)),

Is it useful any more to dynamically create the `_committed` and `_covered` `MemRegions`? These are fixed size anyway. Also the code unconditionally allocates them even if not both are used. It seems to be a win to just statically allocate them.

src/hotspot/share/gc/shared/cardTable.cpp line 129:

> 127:   log_trace(gc, barrier)("CardTable::CardTable: ");
> 128:   log_trace(gc, barrier)("    &_byte_map[0]: " PTR_FORMAT "  &_byte_map[last_valid_index()]: " PTR_FORMAT,
> 129:                   p2i(&_byte_map[0]), p2i(&_byte_map[last_valid_index()]));

pre-existing: indentation of arguments

src/hotspot/share/gc/shared/cardTable.cpp line 153:

> 151:   assert(UseSerialGC || UseParallelGC, "only these two collectors");
> 152:   assert(_whole_heap.contains(new_region),
> 153:            "attempt to cover area not in reserved area");

pre-existing: indentation

src/hotspot/share/gc/shared/cardTable.cpp line 159:

> 157:   assert(_committed[idx].start() != nullptr, "precondition");
> 158: 
> 159:   // We don't change the start of a region, only the end.

Suggestion:

  // We don't allow changes to the start of a region, only the end.

src/hotspot/share/gc/shared/cardTable.cpp line 169:

> 167: 
> 168:   if (idx == 0) {
> 169:     // in case the card for gen-boundary is not page-size aligned

Suggestion:

    // In case the card for gen-boundary is not page-size aligned, make sure to not uncommit it erroneously.

src/hotspot/share/gc/shared/cardTable.cpp line 180:

> 178: 
> 179:   if (new_committed.word_size() > _committed[idx].word_size()) {
> 180:     // expand

Suggestion:

    // Expand.

src/hotspot/share/gc/shared/cardTable.cpp line 192:

> 190:     memset(delta.start(), clean_card, delta.byte_size());
> 191:   } else {
> 192:     // shrink

Suggestion:

    // Shrink.

src/hotspot/share/gc/shared/cardTable.hpp line 57:

> 55:   // "covering" parts of the heap that are committed. At most one covered
> 56:   // region per generation is needed.
> 57:   static constexpr int _max_covered_regions = 2;

Suggestion:

  static constexpr int max_covered_regions = 2;

Naming of this static const should follow existing practice in this file (at least ;) )

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

Changes requested by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13206#pullrequestreview-1387863741
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168593017
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168585816
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168568594
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168611144
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168588167
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168589044
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168589233
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168703736

From ayang at openjdk.org  Mon Apr 17 14:34:36 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 17 Apr 2023 14:34:36 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region
In-Reply-To: <SsgzdCdeW6GsJym-CJVSnW1OgJ6fw8LcE01VaYZdYU8=.386ab41c-0cc6-4ea2-a159-0b328c1e09f3@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <SsgzdCdeW6GsJym-CJVSnW1OgJ6fw8LcE01VaYZdYU8=.386ab41c-0cc6-4ea2-a159-0b328c1e09f3@github.com>
Message-ID: <YEf7mH5igwW3IfdOGE51fldhlFbtfWrTTms-nSyPpbM=.3a6e1f4a-85b2-4889-93c6-5513aa203a8a@github.com>

On Mon, 17 Apr 2023 13:42:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> keeping both _covered and _committed seems unnecessary; the latter can always be calculated from the former

True; I can try if the latter can be removed.

> Maybe some more specialization just for a serial/parallel gc card table would be nice as it's only used by them. In that sense, the initialize() method also seems to be specific to serial/parallel.

What specialization do you have in mind?

> src/hotspot/share/gc/shared/cardTable.cpp line 77:
> 
>> 75:   _byte_map_base(nullptr),
>> 76:   _covered(MemRegion::create_array(_max_covered_regions, mtGC)),
>> 77:   _committed(MemRegion::create_array(_max_covered_regions, mtGC)),
> 
> Is it useful any more to dynamically create the `_committed` and `_covered` `MemRegions`? These are fixed size anyway. Also the code unconditionally allocates them even if not both are used. It seems to be a win to just statically allocate them.

`_covered` and `_committed` are also referenced in `vmStructs_gc.hpp`. I can use `MemRegion _covered[2];` inside `class CardTable`, but how to represent that array-type in `vmStructs_gc.hpp`?

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

PR Comment: https://git.openjdk.org/jdk/pull/13206#issuecomment-1511479387
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168805945

From tschatzl at openjdk.org  Mon Apr 17 15:25:40 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 15:25:40 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region
In-Reply-To: <YEf7mH5igwW3IfdOGE51fldhlFbtfWrTTms-nSyPpbM=.3a6e1f4a-85b2-4889-93c6-5513aa203a8a@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <SsgzdCdeW6GsJym-CJVSnW1OgJ6fw8LcE01VaYZdYU8=.386ab41c-0cc6-4ea2-a159-0b328c1e09f3@github.com>
 <YEf7mH5igwW3IfdOGE51fldhlFbtfWrTTms-nSyPpbM=.3a6e1f4a-85b2-4889-93c6-5513aa203a8a@github.com>
Message-ID: <TzAUa5Xl-H3FrPWbFCkjItxgjB6lNRnhYQQSwfKqTXo=.23e353af-7e97-41f0-9d07-40a364f58039@github.com>

On Mon, 17 Apr 2023 14:31:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/cardTable.cpp line 77:
>> 
>>> 75:   _byte_map_base(nullptr),
>>> 76:   _covered(MemRegion::create_array(_max_covered_regions, mtGC)),
>>> 77:   _committed(MemRegion::create_array(_max_covered_regions, mtGC)),
>> 
>> Is it useful any more to dynamically create the `_committed` and `_covered` `MemRegions`? These are fixed size anyway. Also the code unconditionally allocates them even if not both are used. It seems to be a win to just statically allocate them.
>
> `_covered` and `_committed` are also referenced in `vmStructs_gc.hpp`. I can use `MemRegion _covered[2];` inside `class CardTable`, but how to represent that array-type in `vmStructs_gc.hpp`?

They are not used in the hotspot agent afaict though, so they could simply be removed.

Otherwise one could use two separate members of `MemRegion` type.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1168894038

From tschatzl at openjdk.org  Mon Apr 17 15:28:37 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 15:28:37 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region
In-Reply-To: <YEf7mH5igwW3IfdOGE51fldhlFbtfWrTTms-nSyPpbM=.3a6e1f4a-85b2-4889-93c6-5513aa203a8a@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <SsgzdCdeW6GsJym-CJVSnW1OgJ6fw8LcE01VaYZdYU8=.386ab41c-0cc6-4ea2-a159-0b328c1e09f3@github.com>
 <YEf7mH5igwW3IfdOGE51fldhlFbtfWrTTms-nSyPpbM=.3a6e1f4a-85b2-4889-93c6-5513aa203a8a@github.com>
Message-ID: <I6HWk5kHskBBGLkGEIkyvtdf7pQ1eLklXZk9dV0XOmM=.e666af8b-81b8-4d3c-baa5-173a60e54d96@github.com>

On Mon, 17 Apr 2023 14:31:27 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > Maybe some more specialization just for a serial/parallel gc card table would be nice as it's only used by them. In that sense, the initialize() method also seems to be specific to serial/parallel.
> 
> What specialization do you have in mind?

One option could be to introduce some `TwoGenerationCardTable` class that is used by serial/parallel which can add these methods/members. Not sure if it is worth, but `_committed/_covered` does not seem to be used a lot in `CardTable`; e.g. most of the time `_whole_heap` seems to be used in the common functionality anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/13206#issuecomment-1511590714

From tschatzl at openjdk.org  Mon Apr 17 15:34:32 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 17 Apr 2023 15:34:32 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region
In-Reply-To: <I6HWk5kHskBBGLkGEIkyvtdf7pQ1eLklXZk9dV0XOmM=.e666af8b-81b8-4d3c-baa5-173a60e54d96@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <SsgzdCdeW6GsJym-CJVSnW1OgJ6fw8LcE01VaYZdYU8=.386ab41c-0cc6-4ea2-a159-0b328c1e09f3@github.com>
 <YEf7mH5igwW3IfdOGE51fldhlFbtfWrTTms-nSyPpbM=.3a6e1f4a-85b2-4889-93c6-5513aa203a8a@github.com>
 <I6HWk5kHskBBGLkGEIkyvtdf7pQ1eLklXZk9dV0XOmM=.e666af8b-81b8-4d3c-baa5-173a60e54d96@github.com>
Message-ID: <Y-vP9ptv4Uh1WE5McbZje21oZRpVdsN98b7TRwcb1Ms=.99ad62a8-4cf5-44ac-8845-9735d438ea54@github.com>

On Mon, 17 Apr 2023 15:25:52 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> > > Maybe some more specialization just for a serial/parallel gc card table would be nice as it's only used by them. In that sense, the initialize() method also seems to be specific to serial/parallel.
> > 
> > 
> > What specialization do you have in mind?
> 
> One option could be to introduce some `TwoGenerationCardTable` class that is used by serial/parallel which can add these methods/members. Not sure if it is worth, but `_committed/_covered` does not seem to be used a lot in `CardTable`; e.g. most of the time `_whole_heap` seems to be used in the common functionality anyway.

.... so this may be a straightforward extraction of these members for that `TwoGenerationCardTable`, not impacting G1's card table too much (it fakes a single `_covered` region that it does not use afair).

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

PR Comment: https://git.openjdk.org/jdk/pull/13206#issuecomment-1511603476

From ayang at openjdk.org  Tue Apr 18 08:33:53 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Apr 2023 08:33:53 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region [v2]
In-Reply-To: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
Message-ID: <tuZcaqcjRz8oNG8uyCDG8EquLWOaO31NRIlEVs9Ido4=.261eff80-6a99-4124-95eb-53de55cfbe90@github.com>

> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
> 
> Test: tier1-6

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

 - remove-committed
 - review
 - card-table-clear-memregion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13206/files
  - new: https://git.openjdk.org/jdk/pull/13206/files/4971107f..430acad6

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

  Stats: 265859 lines in 2361 files changed: 230589 ins; 21540 del; 13730 mod
  Patch: https://git.openjdk.org/jdk/pull/13206.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13206/head:pull/13206

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

From ayang at openjdk.org  Tue Apr 18 08:34:10 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Apr 2023 08:34:10 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region
In-Reply-To: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
Message-ID: <_ic-Ye__Dk7ipkMvuifIHce_uLGvSXRd5rfYPZGrKXI=.35e4e24e-4d98-490e-9279-6f1e76e2926c@github.com>

On Tue, 28 Mar 2023 09:59:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
> 
> Test: tier1-6

> They are not used in the hotspot agent afaict though, so they could simply be removed.

I will explore that option in another PR.

> One option could be to introduce some TwoGenerationCardTable class that is used by serial/parallel which can add these methods/members.

I think that complicates the inheritance hierarchy too much without real benefit.

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

PR Comment: https://git.openjdk.org/jdk/pull/13206#issuecomment-1512678482

From tschatzl at openjdk.org  Tue Apr 18 09:06:49 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 18 Apr 2023 09:06:49 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region [v2]
In-Reply-To: <tuZcaqcjRz8oNG8uyCDG8EquLWOaO31NRIlEVs9Ido4=.261eff80-6a99-4124-95eb-53de55cfbe90@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <tuZcaqcjRz8oNG8uyCDG8EquLWOaO31NRIlEVs9Ido4=.261eff80-6a99-4124-95eb-53de55cfbe90@github.com>
Message-ID: <vImIVS4ohJzLkFI4ezfYcV5JiWafNbMSgIZuDFKeZSY=.31376464-72da-4109-904d-beb297889921@github.com>

On Tue, 18 Apr 2023 08:33:53 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - remove-committed
>  - review
>  - card-table-clear-memregion

Lgtm. Removal of `_committed` improved the code significantly imho.

Please consider the other formatting suggestions.

src/hotspot/share/gc/shared/cardTable.cpp line 136:

> 134:   HeapWord* addr_r = mr.is_empty()
> 135:                        ? addr_l
> 136:                        : (HeapWord*)align_up(byte_after(mr.last()), _page_size);

I think common formattings for multiline ?: statements are:


  HeapWord* addr_r = mr.is_empty() ?
                     addr_l :
                     (HeapWord*)align_up(byte_after(mr.last()), _page_size);

or


  HeapWord* addr_r = mr.is_empty()
                   ? addr_l
                   : (HeapWord*)align_up(byte_after(mr.last()), _page_size);

or in this case:

  HeapWord* addr_r = mr.is_empty() ? addr_l : (HeapWord*)align_up(byte_after(mr.last()), _page_size);


At least the "?"/":" in front of the line, indented 4 characters to anything above is very unusual.

I did see this style (4 chars indented) once in gc code though. I would like to avoid further proliferation of this one; for that particular case it's imo best to just use a single line here.

src/hotspot/share/gc/shared/cardTable.cpp line 139:

> 137: 
> 138:   if (mr.start() == _covered[0].start()) {
> 139:     // In case the card for gen-boundary is not page-size aligned, the crossing page belongs to _covered[1]

Suggestion:

    // In case the card for gen-boundary is not page-size aligned, the crossing page belongs to _covered[1].

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13206#pullrequestreview-1389605436
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1169703067
PR Review Comment: https://git.openjdk.org/jdk/pull/13206#discussion_r1169704988

From tschatzl at openjdk.org  Tue Apr 18 09:06:51 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 18 Apr 2023 09:06:51 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region
In-Reply-To: <_ic-Ye__Dk7ipkMvuifIHce_uLGvSXRd5rfYPZGrKXI=.35e4e24e-4d98-490e-9279-6f1e76e2926c@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <_ic-Ye__Dk7ipkMvuifIHce_uLGvSXRd5rfYPZGrKXI=.35e4e24e-4d98-490e-9279-6f1e76e2926c@github.com>
Message-ID: <TVGA7q54cuFi8qg9-5AX6OipnUC94AIkW4maPnDmCug=.b5d32099-aa67-47fa-acf4-d0a44ec7974c@github.com>

On Tue, 18 Apr 2023 08:31:58 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > They are not used in the hotspot agent afaict though, so they could simply be removed.
> 
> I will explore that option in another PR.
> 

Okay.

> > One option could be to introduce some TwoGenerationCardTable class that is used by serial/parallel which can add these methods/members.
> 
> I think that complicates the inheritance hierarchy too much without real benefit.

It makes code only used by serial/parallel serial/parallel specific, decluttering this base class. But I have not looked through that in detail, and this change already removes lots of unnecessary genericity, so I'm not insisting on that.

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

PR Comment: https://git.openjdk.org/jdk/pull/13206#issuecomment-1512725695

From ayang at openjdk.org  Tue Apr 18 09:21:54 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Apr 2023 09:21:54 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region [v3]
In-Reply-To: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
Message-ID: <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>

> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
> 
> Test: tier1-6

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13206/files
  - new: https://git.openjdk.org/jdk/pull/13206/files/430acad6..c2e05f8e

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

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

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

From iwalulya at openjdk.org  Tue Apr 18 09:35:52 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 18 Apr 2023 09:35:52 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v5]
In-Reply-To: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
Message-ID: <N5vPiTmQ5940j1PAqoJQXrAzD7u3QcpNJgP7tnbmglM=.00cb034b-f9a0-4019-9142-b6fed4de8fe6@github.com>

> Hi All,
> 
> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
> 
> The change should also handle the issues reported in JDK-8299276.
> 
> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
> 
> Testing: Tier 1-5.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Thomas Review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13191/files
  - new: https://git.openjdk.org/jdk/pull/13191/files/7352deed..005dc086

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

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

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

From tschatzl at openjdk.org  Tue Apr 18 11:01:47 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 18 Apr 2023 11:01:47 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region [v3]
In-Reply-To: <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>
Message-ID: <LIil52jvi2jIc_3OTptgrKsgH7LKqERAxH3bqtMJtHQ=.199de24e-46ab-4845-bcfe-d194a405396e@github.com>

On Tue, 18 Apr 2023 09:21:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13206#pullrequestreview-1389846691

From ayang at openjdk.org  Tue Apr 18 12:24:49 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Apr 2023 12:24:49 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v5]
In-Reply-To: <N5vPiTmQ5940j1PAqoJQXrAzD7u3QcpNJgP7tnbmglM=.00cb034b-f9a0-4019-9142-b6fed4de8fe6@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <N5vPiTmQ5940j1PAqoJQXrAzD7u3QcpNJgP7tnbmglM=.00cb034b-f9a0-4019-9142-b6fed4de8fe6@github.com>
Message-ID: <PGVTkzzBQtxupKM7WYqwWmqypKhqd6c9GnslrqLQ8Us=.f6957a0f-9bbd-4a65-b150-108deb5827c6@github.com>

On Tue, 18 Apr 2023 09:35:52 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi All,
>> 
>> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
>> 
>> The change should also handle the issues reported in JDK-8299276.
>> 
>> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
>> 
>> Testing: Tier 1-5.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thomas Review

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 556:

> 554:     VMThread::execute(&op);
> 555: 
> 556:     if (!VM_ParallelGCSystemGC::is_cause_full(cause) || op.gc_succeeded()) {

`!is_cause_full` would cover more cases than `System.gc` and whitebox-fullgc, right? Is this really intended?

The introduce of `op.gc_succeeded()` is not well motivated -- the semantics of the return-val of `invoke()` is also not obvious at first glance. Therefore, I'd prefer keeping the existing signature.

test/hotspot/jtreg/gc/TestJNICriticalStressTest.java line 175:

> 173:         long durationSec = Long.parseLong(args[0]);
> 174:         int allocThreadNum = Integer.parseInt(args[1]);
> 175:         int jniCriticalThreadNum = Integer.parseInt(args[2]);

Why is this always one in all test cases? Wouldn't it be more "stressing" to use sth larger? Same as `allocThreadNum` for instance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1169951304
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1169864279

From iwalulya at openjdk.org  Tue Apr 18 12:38:45 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 18 Apr 2023 12:38:45 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v5]
In-Reply-To: <PGVTkzzBQtxupKM7WYqwWmqypKhqd6c9GnslrqLQ8Us=.f6957a0f-9bbd-4a65-b150-108deb5827c6@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <N5vPiTmQ5940j1PAqoJQXrAzD7u3QcpNJgP7tnbmglM=.00cb034b-f9a0-4019-9142-b6fed4de8fe6@github.com>
 <PGVTkzzBQtxupKM7WYqwWmqypKhqd6c9GnslrqLQ8Us=.f6957a0f-9bbd-4a65-b150-108deb5827c6@github.com>
Message-ID: <dSwt75fISQPX9UyXXCzrReB6IYbnaLZkwL-qA7OUElI=.20742471-c069-4ccb-9944-fdfed825b72f@github.com>

On Tue, 18 Apr 2023 12:21:04 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>  !is_cause_full would cover more cases than System.gc and whitebox-fullgc, right? Is this really intended?

Yes, it is intended. 

> The introduce of `op.gc_succeeded()` is not well motivated -- the semantics of the return-val of `invoke()` is also not obvious at first glance. Therefore, I'd prefer keeping the existing signature.

Yeah, I did think about this. I can revert it.

> test/hotspot/jtreg/gc/TestJNICriticalStressTest.java line 175:
> 
>> 173:         long durationSec = Long.parseLong(args[0]);
>> 174:         int allocThreadNum = Integer.parseInt(args[1]);
>> 175:         int jniCriticalThreadNum = Integer.parseInt(args[2]);
> 
> Why is this always one in all test cases? Wouldn't it be more "stressing" to use sth larger? Same as `allocThreadNum` for instance.

one is enough to trigger the error if one exists, whichever number we pick higher will be random. You can suggest a number if you like.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1169967907
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1169970250

From ayang at openjdk.org  Tue Apr 18 12:40:39 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Apr 2023 12:40:39 GMT
Subject: RFR: 8306284: G1: Remove assertion in
 G1ScanHRForRegionClosure::do_claimed_block
Message-ID: <AHVLoCyneUI3XzrmzhBzXjhr4fqKqC2VALfvn3MRiZI=.d2239af0-cdff-4328-86cd-58e3e3c9bcf4@github.com>

Simple removing of a superfluous assertion.

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

Commit messages:
 - g1-remove-assert

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

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

From iwalulya at openjdk.org  Tue Apr 18 13:34:53 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 18 Apr 2023 13:34:53 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v6]
In-Reply-To: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
Message-ID: <Ks05HJyNi70FnsVjfT7CNiYqeiD_SOp9a6j20mjtnjA=.84f0743c-429d-4b97-ba2a-982e480c6743@github.com>

> Hi All,
> 
> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
> 
> The change should also handle the issues reported in JDK-8299276.
> 
> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
> 
> Testing: Tier 1-5.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Albert review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13191/files
  - new: https://git.openjdk.org/jdk/pull/13191/files/005dc086..5fc0125f

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

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

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

From ayang at openjdk.org  Tue Apr 18 13:34:54 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 18 Apr 2023 13:34:54 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v5]
In-Reply-To: <dSwt75fISQPX9UyXXCzrReB6IYbnaLZkwL-qA7OUElI=.20742471-c069-4ccb-9944-fdfed825b72f@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <N5vPiTmQ5940j1PAqoJQXrAzD7u3QcpNJgP7tnbmglM=.00cb034b-f9a0-4019-9142-b6fed4de8fe6@github.com>
 <PGVTkzzBQtxupKM7WYqwWmqypKhqd6c9GnslrqLQ8Us=.f6957a0f-9bbd-4a65-b150-108deb5827c6@github.com>
 <dSwt75fISQPX9UyXXCzrReB6IYbnaLZkwL-qA7OUElI=.20742471-c069-4ccb-9944-fdfed825b72f@github.com>
Message-ID: <Sinmlcb9NhLp8-2ZNPFi7NfjWujJhisvRPFYN6MQDHc=.ffaa0414-1718-4f58-a130-18a2612951a3@github.com>

On Tue, 18 Apr 2023 12:34:03 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Yes, it is intended.

Then, even non-explicit-gc (e.g. `_metadata_GC_threshold` or some other gc-cause) would get "guarantee that at least a Full GC is executed", not matching the title of this ticket.

> Yeah, I did think about this. I can revert it.

Thank you.

> one is enough to trigger the error if one exists

Well, there could be concurrent issues also. I'd feel more comfortable if it's > 1. (I suggest using 4, just to match its neighbor.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1170044109
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1170043892

From iwalulya at openjdk.org  Tue Apr 18 15:22:07 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 18 Apr 2023 15:22:07 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v7]
In-Reply-To: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
Message-ID: <0Yu-ATFchBXSXyFrCWscJRwSys9ojnEVpiI4QaY1U9o=.15721984-b684-4c84-8dbc-7e7f1c0c9ef7@github.com>

> Hi All,
> 
> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
> 
> The change should also handle the issues reported in JDK-8299276.
> 
> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
> 
> Testing: Tier 1-5.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Albert review - is_explicit_gc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13191/files
  - new: https://git.openjdk.org/jdk/pull/13191/files/5fc0125f..702677c7

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

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

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

From iwalulya at openjdk.org  Tue Apr 18 15:24:16 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 18 Apr 2023 15:24:16 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v5]
In-Reply-To: <Sinmlcb9NhLp8-2ZNPFi7NfjWujJhisvRPFYN6MQDHc=.ffaa0414-1718-4f58-a130-18a2612951a3@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <N5vPiTmQ5940j1PAqoJQXrAzD7u3QcpNJgP7tnbmglM=.00cb034b-f9a0-4019-9142-b6fed4de8fe6@github.com>
 <PGVTkzzBQtxupKM7WYqwWmqypKhqd6c9GnslrqLQ8Us=.f6957a0f-9bbd-4a65-b150-108deb5827c6@github.com>
 <dSwt75fISQPX9UyXXCzrReB6IYbnaLZkwL-qA7OUElI=.20742471-c069-4ccb-9944-fdfed825b72f@github.com>
 <Sinmlcb9NhLp8-2ZNPFi7NfjWujJhisvRPFYN6MQDHc=.ffaa0414-1718-4f58-a130-18a2612951a3@github.com>
Message-ID: <nfe48gKOpgCpZ1UeXwEahvJGXRw9aCafGmXdsIV_iGM=.b6ae3e6f-32ed-4dc7-b04a-03fb4cc0a23d@github.com>

On Tue, 18 Apr 2023 13:29:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Then, even non-explicit-gc (e.g. `_metadata_GC_threshold` or some other gc-cause) would get "guarantee that at least a Full GC is executed", not matching the title of this ticket.
> 
Thanks for catching that! Fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1170201215

From tschatzl at openjdk.org  Tue Apr 18 16:22:48 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 18 Apr 2023 16:22:48 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v7]
In-Reply-To: <0Yu-ATFchBXSXyFrCWscJRwSys9ojnEVpiI4QaY1U9o=.15721984-b684-4c84-8dbc-7e7f1c0c9ef7@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <0Yu-ATFchBXSXyFrCWscJRwSys9ojnEVpiI4QaY1U9o=.15721984-b684-4c84-8dbc-7e7f1c0c9ef7@github.com>
Message-ID: <jIDfflFq0MOzrHBaYjqm6tjKGNxYG3Z71qPFBV3wutY=.3bd2fa29-7aa9-44b3-9b27-831830a9ecf2@github.com>

On Tue, 18 Apr 2023 15:22:07 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi All,
>> 
>> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
>> 
>> The change should also handle the issues reported in JDK-8299276.
>> 
>> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
>> 
>> Testing: Tier 1-5.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert review - is_explicit_gc

Changes requested by tschatzl (Reviewer).

src/hotspot/share/gc/shared/gcCause.hpp line 103:

> 101:             cause == GCCause::_wb_full_gc);
> 102:   }
> 103: 

Not exactly sure what "explict gc"s are, but I would expect something more like this:

Suggestion:

  inline static bool is_explicit_gc(GCCause::Cause cause) {
    return (is_user_requested_gc(cause) ||
            is_serviceability_requested_gc(cause) ||
            cause == GCCause::_wb_young_gc) ||
            cause == GCCause::_wb_full_gc);
  }


because serviceability gcs are also explicitly requested by the user (from command line), and I believe all whitebox gcs are "explicit". Maybe also "_allocation_profiler" and "wb_breakpoint" ones (not sure right now about these ones).
At least the serviceability ones shouldn't be eaten by gc locker either, but maybe there is no guarantee about them to actually occur.

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

PR Review: https://git.openjdk.org/jdk/pull/13191#pullrequestreview-1390464630
PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1170261898

From iwalulya at openjdk.org  Tue Apr 18 16:22:49 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 18 Apr 2023 16:22:49 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v7]
In-Reply-To: <jIDfflFq0MOzrHBaYjqm6tjKGNxYG3Z71qPFBV3wutY=.3bd2fa29-7aa9-44b3-9b27-831830a9ecf2@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <0Yu-ATFchBXSXyFrCWscJRwSys9ojnEVpiI4QaY1U9o=.15721984-b684-4c84-8dbc-7e7f1c0c9ef7@github.com>
 <jIDfflFq0MOzrHBaYjqm6tjKGNxYG3Z71qPFBV3wutY=.3bd2fa29-7aa9-44b3-9b27-831830a9ecf2@github.com>
Message-ID: <2_XaMF3dcZdzfqmfutn6CD6fTb-HwZI0h1l3rF6YdpU=.32937c53-15dd-4bc5-8c86-78c4ed5a27d2@github.com>

On Tue, 18 Apr 2023 16:01:21 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert review - is_explicit_gc
>
> src/hotspot/share/gc/shared/gcCause.hpp line 103:
> 
>> 101:             cause == GCCause::_wb_full_gc);
>> 102:   }
>> 103: 
> 
> Not exactly sure what "explict gc"s are, but I would expect something more like this:
> 
> Suggestion:
> 
>   inline static bool is_explicit_gc(GCCause::Cause cause) {
>     return (is_user_requested_gc(cause) ||
>             is_serviceability_requested_gc(cause) ||
>             cause == GCCause::_wb_young_gc) ||
>             cause == GCCause::_wb_full_gc);
>   }
> 
> 
> because serviceability gcs are also explicitly requested by the user (from command line), and I believe all whitebox gcs are "explicit". Maybe also "_allocation_profiler" and "wb_breakpoint" ones (not sure right now about these ones).
> At least the serviceability ones shouldn't be eaten by gc locker either, but maybe there is no guarantee about them to actually occur.

`is_explicit_full_gc`  which ones would fall in that category? Those are the only ones we are be interested in.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1170267260

From wkemper at openjdk.org  Tue Apr 18 16:42:32 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 18 Apr 2023 16:42:32 GMT
Subject: RFR: 8305716: Enhancements for printing age tables [v2]
In-Reply-To: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
References: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
Message-ID: <XnApHUJQOWe-juMyYlYCgmFIu-MSHGwBiK9y5p5hi98=.bdeac4d5-e631-40fd-ab3f-38d7f2f70bff@github.com>

> In order to reduce the number of changes for the upcoming PR for the generational mode for Shenandoah we are opening separate PRs for the changes in common code. Shenandoah will be using this `AgeTable` class. There are two changes here:
> * `AgeTables` created with global=false will no longer SEGV when printing
> * A method was added to allow the `AgeTable` to print to an existing output stream

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

  Fix indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13377/files
  - new: https://git.openjdk.org/jdk/pull/13377/files/0c1fcefa..56d59de4

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

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

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

From wkemper at openjdk.org  Tue Apr 18 17:46:03 2023
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 18 Apr 2023 17:46:03 GMT
Subject: RFR: 8306321: Add accessor for top of PLAB
Message-ID: <nDRqxbvPwtODwCTh8pKNI7y02U_OvDxd3OgiMiMtsGQ=.7d1b8fa9-cbf4-4cf3-a2ac-2547d04df328@github.com>

The generational mode for Shenandoah needs to know the top of a PLAB when it is retired.

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

Commit messages:
 - Add accessor for top of PLAB

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

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

From kbarrett at openjdk.org  Wed Apr 19 06:11:42 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 19 Apr 2023 06:11:42 GMT
Subject: RFR: 8306284: G1: Remove assertion in
 G1ScanHRForRegionClosure::do_claimed_block
In-Reply-To: <AHVLoCyneUI3XzrmzhBzXjhr4fqKqC2VALfvn3MRiZI=.d2239af0-cdff-4328-86cd-58e3e3c9bcf4@github.com>
References: <AHVLoCyneUI3XzrmzhBzXjhr4fqKqC2VALfvn3MRiZI=.d2239af0-cdff-4328-86cd-58e3e3c9bcf4@github.com>
Message-ID: <pSU6pZ3EU3aTWRKjHkGX7hlY-JgJn0m06vPqZ_weo-Q=.1d4b65c4-1048-4f04-8048-6d78144f8f33@github.com>

On Tue, 18 Apr 2023 12:32:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing of a superfluous assertion.

I agree this assert doesn't much of anything useful.  It would probably be more useful
if it asserted that `hr != nullptr`, but even that isn't particularly helpful.

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13509#pullrequestreview-1391317680

From tschatzl at openjdk.org  Wed Apr 19 07:43:45 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Apr 2023 07:43:45 GMT
Subject: RFR: 8306284: G1: Remove assertion in
 G1ScanHRForRegionClosure::do_claimed_block
In-Reply-To: <AHVLoCyneUI3XzrmzhBzXjhr4fqKqC2VALfvn3MRiZI=.d2239af0-cdff-4328-86cd-58e3e3c9bcf4@github.com>
References: <AHVLoCyneUI3XzrmzhBzXjhr4fqKqC2VALfvn3MRiZI=.d2239af0-cdff-4328-86cd-58e3e3c9bcf4@github.com>
Message-ID: <wZSO6TUS4rNaCbACZfr4fNaoHm93ANVAn0xTIjClKBA=.3a920d18-a16c-405e-96a8-ec64a94a0d66@github.com>

On Tue, 18 Apr 2023 12:32:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing of a superfluous assertion.

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13509#pullrequestreview-1391451651

From wkemper at openjdk.org  Wed Apr 19 07:46:58 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 19 Apr 2023 07:46:58 GMT
Subject: Integrated: 8305716: Enhancements for printing age tables
In-Reply-To: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
References: <3Ab50FMgEQVp-dB2QXhEXgenPFpELwWpXtCQ1iEIZQk=.d6ee3790-012d-4517-ab32-39dacbc2548c@github.com>
Message-ID: <2PTMhdOcUOXbW8aavKxIQ7uBaS9I2FLiW9ZRpdtn-5w=.a545d093-1141-473d-a7f1-a3bb253e3c7c@github.com>

On Thu, 6 Apr 2023 18:18:54 GMT, William Kemper <wkemper at openjdk.org> wrote:

> In order to reduce the number of changes for the upcoming PR for the generational mode for Shenandoah we are opening separate PRs for the changes in common code. Shenandoah will be using this `AgeTable` class. There are two changes here:
> * `AgeTables` created with global=false will no longer SEGV when printing
> * A method was added to allow the `AgeTable` to print to an existing output stream

This pull request has now been integrated.

Changeset: 9fb53adf
Author:    William Kemper <wkemper at openjdk.org>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9fb53adfe00c5fdb8c8b5f7bc059634fc15b040d
Stats:     33 lines in 2 files changed: 10 ins; 3 del; 20 mod

8305716: Enhancements for printing age tables

Reviewed-by: kdnilsen, ysr, tschatzl

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

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

From iwalulya at openjdk.org  Wed Apr 19 10:16:16 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 19 Apr 2023 10:16:16 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v8]
In-Reply-To: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
Message-ID: <LfeTWy3wYWGESIsNoUiFemCBvR4cI5Esp-4TOaK2-IY=.b1b8b9ae-2bfb-4e99-9e5a-d180eb89f2ba@github.com>

> Hi All,
> 
> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
> 
> The change should also handle the issues reported in JDK-8299276.
> 
> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
> 
> Testing: Tier 1-5.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Thomas review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13191/files
  - new: https://git.openjdk.org/jdk/pull/13191/files/702677c7..b9180621

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

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

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

From tschatzl at openjdk.org  Wed Apr 19 10:53:39 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Apr 2023 10:53:39 GMT
Subject: RFR: 8306436: Rename PSS*:_n_workers to PSS*:_num_workers
Message-ID: <k6kWq6ZIa-rlmh4sSojpC_ZjbGgzQwclOBxximjQVWQ=.474dbae7-46c1-4cd1-ac49-044e5113ccdd@github.com>

Hi all,

  please review this rename of the `_n_workers` member to `_num_workers` since the latter uses the more common prefix for amounts of things.

Testing: gha

Thanks,
  Thomas

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

Commit messages:
 - Rename PSS*:_n_workers to PSS*:_num_workers

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

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

From ayang at openjdk.org  Wed Apr 19 10:58:41 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 19 Apr 2023 10:58:41 GMT
Subject: RFR: 8306436: Rename PSS*:_n_workers to PSS*:_num_workers
In-Reply-To: <k6kWq6ZIa-rlmh4sSojpC_ZjbGgzQwclOBxximjQVWQ=.474dbae7-46c1-4cd1-ac49-044e5113ccdd@github.com>
References: <k6kWq6ZIa-rlmh4sSojpC_ZjbGgzQwclOBxximjQVWQ=.474dbae7-46c1-4cd1-ac49-044e5113ccdd@github.com>
Message-ID: <CfBkDjDRO3vxwfo1_eQoKD0sLpkS3CgHhyNf1HQl0ko=.919f31e5-982c-496a-8fa3-abe6fda77ee3@github.com>

On Wed, 19 Apr 2023 10:45:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this rename of the `_n_workers` member to `_num_workers` since the latter uses the more common prefix for amounts of things.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13531#pullrequestreview-1391802281

From tschatzl at openjdk.org  Wed Apr 19 11:20:49 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 19 Apr 2023 11:20:49 GMT
Subject: RFR: 8306440: Rename PSS:_num_optional_regions to
 _num_initial_optional_regions
Message-ID: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>

Hi all,

   please review this small change that clarifies the use of `PSS::_num_optional_regions` to be the initial amount of optional regions, not the current amount of optional regions.

Testing: gha

Thanks,
  Thomas

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

Depends on: https://git.openjdk.org/jdk/pull/13531

Commit messages:
 - Rename PSS:_num_optional_regions to _num_initial_optional_regions to emphasize that it's the initial amount of optional regions

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

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

From iwalulya at openjdk.org  Wed Apr 19 11:25:10 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 19 Apr 2023 11:25:10 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v9]
In-Reply-To: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
Message-ID: <FvmPjEIM1IlMybuerBg8y1Vu8Rezy6gIfVMXGP-2X0U=.fec342e6-af20-4640-a854-6dc69739cacb@github.com>

> Hi All,
> 
> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
> 
> The change should also handle the issues reported in JDK-8299276.
> 
> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
> 
> Testing: Tier 1-5.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  skip young gcs for parallel too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13191/files
  - new: https://git.openjdk.org/jdk/pull/13191/files/b9180621..bd418d01

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

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

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

From shade at openjdk.org  Wed Apr 19 14:11:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 19 Apr 2023 14:11:59 GMT
Subject: RFR: 8306321: Add an accessor for the top of a PLAB
In-Reply-To: <nDRqxbvPwtODwCTh8pKNI7y02U_OvDxd3OgiMiMtsGQ=.7d1b8fa9-cbf4-4cf3-a2ac-2547d04df328@github.com>
References: <nDRqxbvPwtODwCTh8pKNI7y02U_OvDxd3OgiMiMtsGQ=.7d1b8fa9-cbf4-4cf3-a2ac-2547d04df328@github.com>
Message-ID: <cbOrcuhAL1knyuGdYFuCgfPLMEuoQ5v55xIEgvt79zA=.43305955-c9be-4b04-86a2-c997ec3c188a@github.com>

On Tue, 18 Apr 2023 17:37:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The generational mode for Shenandoah needs to know the top of a PLAB when it is retired.

This looks fine to me.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13516#pullrequestreview-1392161725

From ysr at openjdk.org  Wed Apr 19 18:32:49 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 19 Apr 2023 18:32:49 GMT
Subject: RFR: 8306321: Add an accessor for the top of a PLAB
In-Reply-To: <nDRqxbvPwtODwCTh8pKNI7y02U_OvDxd3OgiMiMtsGQ=.7d1b8fa9-cbf4-4cf3-a2ac-2547d04df328@github.com>
References: <nDRqxbvPwtODwCTh8pKNI7y02U_OvDxd3OgiMiMtsGQ=.7d1b8fa9-cbf4-4cf3-a2ac-2547d04df328@github.com>
Message-ID: <zORSPVRb6uWCs0ymgcv_CRVj2XkdIIuZFllJaeUdHT8=.2ca68ef0-a853-4f5d-91a1-addeae021a94@github.com>

On Tue, 18 Apr 2023 17:37:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The generational mode for Shenandoah needs to know the top of a PLAB when it is retired.

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13516#pullrequestreview-1392665211

From wkemper at openjdk.org  Wed Apr 19 18:35:57 2023
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 19 Apr 2023 18:35:57 GMT
Subject: Integrated: 8306321: Add an accessor for the top of a PLAB
In-Reply-To: <nDRqxbvPwtODwCTh8pKNI7y02U_OvDxd3OgiMiMtsGQ=.7d1b8fa9-cbf4-4cf3-a2ac-2547d04df328@github.com>
References: <nDRqxbvPwtODwCTh8pKNI7y02U_OvDxd3OgiMiMtsGQ=.7d1b8fa9-cbf4-4cf3-a2ac-2547d04df328@github.com>
Message-ID: <q8i-e2ZNbpQk01PmIv_1chiqFsnm7bce-sPf47CjSE0=.f253663a-53a8-4be5-8565-97f002b6f60f@github.com>

On Tue, 18 Apr 2023 17:37:00 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The generational mode for Shenandoah needs to know the top of a PLAB when it is retired.

This pull request has now been integrated.

Changeset: ed34e7f5
Author:    William Kemper <wkemper at openjdk.org>
Committer: Y. Srinivas Ramakrishna <ysr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed34e7f5aeb1d38d3a26d6bbd4c69624b0662cfb
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8306321: Add an accessor for the top of a PLAB

Reviewed-by: shade, ysr

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

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

From tschatzl at openjdk.org  Thu Apr 20 09:32:46 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 20 Apr 2023 09:32:46 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v9]
In-Reply-To: <FvmPjEIM1IlMybuerBg8y1Vu8Rezy6gIfVMXGP-2X0U=.fec342e6-af20-4640-a854-6dc69739cacb@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <FvmPjEIM1IlMybuerBg8y1Vu8Rezy6gIfVMXGP-2X0U=.fec342e6-af20-4640-a854-6dc69739cacb@github.com>
Message-ID: <TZQuS-d_fkYj8Z7ECVB3-yfI-c75GR12M9_iNE8iN5Q=.f4da3c2b-2b1e-41cf-be17-d7383c971ee7@github.com>

On Wed, 19 Apr 2023 11:25:10 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi All,
>> 
>> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of `System.gc` or `WhiteBox.fullGC`, even if the call is concurrent with an active `GCLocker `. 
>> 
>> The change should also handle the issues reported in JDK-8299276.
>> 
>> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
>> 
>> Testing: Tier 1-5.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip young gcs for parallel too

lgtm.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13191#pullrequestreview-1393589660

From tschatzl at openjdk.org  Thu Apr 20 13:02:55 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 20 Apr 2023 13:02:55 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v7]
In-Reply-To: <2_XaMF3dcZdzfqmfutn6CD6fTb-HwZI0h1l3rF6YdpU=.32937c53-15dd-4bc5-8c86-78c4ed5a27d2@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <0Yu-ATFchBXSXyFrCWscJRwSys9ojnEVpiI4QaY1U9o=.15721984-b684-4c84-8dbc-7e7f1c0c9ef7@github.com>
 <jIDfflFq0MOzrHBaYjqm6tjKGNxYG3Z71qPFBV3wutY=.3bd2fa29-7aa9-44b3-9b27-831830a9ecf2@github.com>
 <2_XaMF3dcZdzfqmfutn6CD6fTb-HwZI0h1l3rF6YdpU=.32937c53-15dd-4bc5-8c86-78c4ed5a27d2@github.com>
Message-ID: <lP9Euhlvbxb0M5lj5YS4vMK1PODlaHcecv4k29NlntQ=.45dab97e-9ed7-4ffe-b659-c87cffde2c6d@github.com>

On Tue, 18 Apr 2023 16:05:36 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/gcCause.hpp line 103:
>> 
>>> 101:             cause == GCCause::_wb_full_gc);
>>> 102:   }
>>> 103: 
>> 
>> Not exactly sure what "explict gc"s are, but I would expect something more like this:
>> 
>> Suggestion:
>> 
>>   inline static bool is_explicit_gc(GCCause::Cause cause) {
>>     return (is_user_requested_gc(cause) ||
>>             is_serviceability_requested_gc(cause) ||
>>             cause == GCCause::_wb_young_gc) ||
>>             cause == GCCause::_wb_full_gc);
>>   }
>> 
>> 
>> because serviceability gcs are also explicitly requested by the user (from command line), and I believe all whitebox gcs are "explicit". Maybe also "_allocation_profiler" and "wb_breakpoint" ones (not sure right now about these ones).
>> At least the serviceability ones shouldn't be eaten by gc locker either, but maybe there is no guarantee about them to actually occur.
>
> `is_explicit_full_gc`  which ones would fall in that category? Those are the only ones we are be interested in.

All but `GCCause::_wb_young_gc` from this list; everything that's triggered by the end user in some form (serviceability gcs are from jcmd typically, so they fit in imho). But after some discussion with you I found that all stw collectors always suppress young gcs that failed due to gclocker, so such a change does not really matter. Keep it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1172332285

From ayang at openjdk.org  Thu Apr 20 13:02:53 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 20 Apr 2023 13:02:53 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v9]
In-Reply-To: <FvmPjEIM1IlMybuerBg8y1Vu8Rezy6gIfVMXGP-2X0U=.fec342e6-af20-4640-a854-6dc69739cacb@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <FvmPjEIM1IlMybuerBg8y1Vu8Rezy6gIfVMXGP-2X0U=.fec342e6-af20-4640-a854-6dc69739cacb@github.com>
Message-ID: <yu-LaO4uTTdkkGAbHfxBagB-pAHh6ZK4jZeZq_Q0z-0=.83fbab34-7c31-453f-bdfa-be852ba5cb05@github.com>

On Wed, 19 Apr 2023 11:25:10 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi All,
>> 
>> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of an explicit Full GC call, even if the call is concurrent with an active `GCLocker`.  We specify explicit GCs as GCs triggered by the end user in some form (jcmd, System.GC, or WhiteBox testing).
>> 
>> The change should also handle the issues reported in JDK-8299276.
>> 
>> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
>> 
>> Testing: Tier 1-5.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   skip young gcs for parallel too

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 559:

> 557:         !VM_ParallelGCSystemGC::is_cause_full(cause) ||
> 558:         op.full_gc_succeeded()) {
> 559:       return;

Looking at the caller context, I'd believe all callers expect a GC cycle has just run (by this thread or another) when `collect(cause)` returns. Therefore, the terminating condition should be to check #gc_cycles against the intended gc-type (young or not), sth like:


{
  MutexLocker ml(Heap_lock);
  if (is_young_gc) {
    if (gc_count != total_collections()) {
      return;
    }
  } else {
    if (full_gc_count != total_full_collections()) {
      return;
    }
  }
}


(Originally, I was thinking only about full-gc, i.e. systemgc and `_wb_full_gc`, but it also seems reasonable to provide such guarantee, a gc-cycle has run, for `_wb_young_gc`.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1172553101

From ayang at openjdk.org  Thu Apr 20 13:05:55 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 20 Apr 2023 13:05:55 GMT
Subject: RFR: 8306284: G1: Remove assertion in
 G1ScanHRForRegionClosure::do_claimed_block
In-Reply-To: <AHVLoCyneUI3XzrmzhBzXjhr4fqKqC2VALfvn3MRiZI=.d2239af0-cdff-4328-86cd-58e3e3c9bcf4@github.com>
References: <AHVLoCyneUI3XzrmzhBzXjhr4fqKqC2VALfvn3MRiZI=.d2239af0-cdff-4328-86cd-58e3e3c9bcf4@github.com>
Message-ID: <JIPcStWaSprfVkYx44q6lOv5BN65BqzpEW8gmpkc7Go=.c7781a66-d3df-4e86-85ec-65393f2b9f7d@github.com>

On Tue, 18 Apr 2023 12:32:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing of a superfluous assertion.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13509#issuecomment-1516286739

From ayang at openjdk.org  Thu Apr 20 13:05:56 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 20 Apr 2023 13:05:56 GMT
Subject: Integrated: 8306284: G1: Remove assertion in
 G1ScanHRForRegionClosure::do_claimed_block
In-Reply-To: <AHVLoCyneUI3XzrmzhBzXjhr4fqKqC2VALfvn3MRiZI=.d2239af0-cdff-4328-86cd-58e3e3c9bcf4@github.com>
References: <AHVLoCyneUI3XzrmzhBzXjhr4fqKqC2VALfvn3MRiZI=.d2239af0-cdff-4328-86cd-58e3e3c9bcf4@github.com>
Message-ID: <FSGzuDbgJ31PRP9-kY0LwqP_WJNMfy82Pz11cLUQiiA=.3fd6ffab-e077-4efa-a39b-359785e4244b@github.com>

On Tue, 18 Apr 2023 12:32:05 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple removing of a superfluous assertion.

This pull request has now been integrated.

Changeset: 73018b39
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73018b39cd25daf01d8928fb50b011160faaad8f
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8306284: G1: Remove assertion in G1ScanHRForRegionClosure::do_claimed_block

Reviewed-by: kbarrett, tschatzl

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

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

From iwalulya at openjdk.org  Thu Apr 20 13:11:50 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 20 Apr 2023 13:11:50 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v9]
In-Reply-To: <yu-LaO4uTTdkkGAbHfxBagB-pAHh6ZK4jZeZq_Q0z-0=.83fbab34-7c31-453f-bdfa-be852ba5cb05@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <FvmPjEIM1IlMybuerBg8y1Vu8Rezy6gIfVMXGP-2X0U=.fec342e6-af20-4640-a854-6dc69739cacb@github.com>
 <yu-LaO4uTTdkkGAbHfxBagB-pAHh6ZK4jZeZq_Q0z-0=.83fbab34-7c31-453f-bdfa-be852ba5cb05@github.com>
Message-ID: <2i1qCn-pfZKOV87CuQk8hW24YOEbVF17oVRBJfsZRKo=.8c39ef24-1c8c-436d-817f-560dfe8d6c36@github.com>

On Thu, 20 Apr 2023 13:00:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   skip young gcs for parallel too
>
> src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 559:
> 
>> 557:         !VM_ParallelGCSystemGC::is_cause_full(cause) ||
>> 558:         op.full_gc_succeeded()) {
>> 559:       return;
> 
> Looking at the caller context, I'd believe all callers expect a GC cycle has just run (by this thread or another) when `collect(cause)` returns. Therefore, the terminating condition should be to check #gc_cycles against the intended gc-type (young or not), sth like:
> 
> 
> {
>   MutexLocker ml(Heap_lock);
>   if (is_young_gc) {
>     if (gc_count != total_collections()) {
>       return;
>     }
>   } else {
>     if (full_gc_count != total_full_collections()) {
>       return;
>     }
>   }
> }
> 
> 
> (Originally, I was thinking only about full-gc, i.e. systemgc and `_wb_full_gc`, but it also seems reasonable to provide such guarantee, a gc-cycle has run, for `_wb_young_gc`.)

I suggest we do that in a follow up CR. For parallel (and I guess for Serial) is that easy, for G1 it requires a bit more code movements.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13191#discussion_r1172564192

From iwalulya at openjdk.org  Thu Apr 20 15:46:49 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Thu, 20 Apr 2023 15:46:49 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v10]
In-Reply-To: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
Message-ID: <ToaKlPUK-mTXElRNxfC3OKxMVxBTwFJOZ4X_wQHveZo=.f286192b-4c5c-4623-9ab7-9bf4f55a84cc@github.com>

> Hi All,
> 
> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of an explicit Full GC call, even if the call is concurrent with an active `GCLocker`.  We specify explicit GCs as GCs triggered by the end user in some form (jcmd, System.GC, or WhiteBox testing).
> 
> The change should also handle the issues reported in JDK-8299276.
> 
> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
> 
> Testing: Tier 1-5.

Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:

  Albert Review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13191/files
  - new: https://git.openjdk.org/jdk/pull/13191/files/bd418d01..bb88da8f

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

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

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

From ayang at openjdk.org  Thu Apr 20 16:31:48 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 20 Apr 2023 16:31:48 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v10]
In-Reply-To: <ToaKlPUK-mTXElRNxfC3OKxMVxBTwFJOZ4X_wQHveZo=.f286192b-4c5c-4623-9ab7-9bf4f55a84cc@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <ToaKlPUK-mTXElRNxfC3OKxMVxBTwFJOZ4X_wQHveZo=.f286192b-4c5c-4623-9ab7-9bf4f55a84cc@github.com>
Message-ID: <JLW7rnwDdVeYk4ZKgfrRp87TgkMBNz16MgSyEMItLE0=.ba88c6ed-b583-4485-b1f3-6f862836ab9f@github.com>

On Thu, 20 Apr 2023 15:46:49 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

>> Hi All,
>> 
>> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of an explicit Full GC call, even if the call is concurrent with an active `GCLocker`.  We specify explicit GCs as GCs triggered by the end user in some form (jcmd, System.GC, or WhiteBox testing).
>> 
>> The change should also handle the issues reported in JDK-8299276.
>> 
>> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
>> 
>> Testing: Tier 1-5.
>
> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Albert Review

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13191#pullrequestreview-1394374039

From ayang at openjdk.org  Fri Apr 21 09:26:43 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 21 Apr 2023 09:26:43 GMT
Subject: RFR: 8306440: Rename PSS:_num_optional_regions to
 _num_initial_optional_regions
In-Reply-To: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
References: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
Message-ID: <ZFOguVsgSBwRIj7_XwfMGGKEQWMEAyHPWQNACAJQsyY=.10c9e3f2-8bdd-49ca-8e30-b518d20962df@github.com>

On Wed, 19 Apr 2023 11:13:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>    please review this small change that clarifies the use of `PSS::_num_optional_regions` to be the initial amount of optional regions, not the current amount of optional regions.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

I feel `_max_num_optional_regions` better reflects its intrinsic semantic.

Inside young-gc pause, `initial` and `optional` most often refer to the dual initial-evac vs optional-evac and everything associated with them. Therefore, it can be confusing to see both words in one name.

(Ofc, this is quite subjective.)

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13532#pullrequestreview-1395426411

From tschatzl at openjdk.org  Fri Apr 21 10:18:55 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 21 Apr 2023 10:18:55 GMT
Subject: RFR: 8306440: Rename PSS:_num_optional_regions to
 _num_initial_optional_regions [v2]
In-Reply-To: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
References: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
Message-ID: <A4nh8jpfEywdcHoQC1cedwrnvq3oGKyGaHhjFmakCn8=.b0a0dad5-3a17-4b44-a8fe-3e1916090fac@github.com>

> Hi all,
> 
>    please review this small change that clarifies the use of `PSS::_num_optional_regions` to be the initial amount of optional regions, not the current amount of optional regions.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with 36 additional commits since the last revision:

 - ayang review
 - Merge branch 'master' into 8306440-rename-num_optional_regions
 - 8306581: JVMCI tests failed when run with -XX:TypeProfileLevel=222 after JDK-8303431
   
   Reviewed-by: never, kvn
 - 8306430: Open source some AWT tests related to TextComponent and Toolkit
   
   Reviewed-by: serb
 - 8305942: Open source several AWT Focus related tests
   
   Reviewed-by: prr
 - 8306060: Open source few AWT Insets related tests
   
   Reviewed-by: serb, prr
 - 8305236: Some LoadLoad barriers in the interpreter are unnecessary after JDK-8220051
   
   Reviewed-by: dholmes, fyang, aph
 - 8305207: Calendar.aggregateStamp(int, int) return value can be simplified
   
   Reviewed-by: naoto, rriggs, iris
 - 4737887: (cal) API: Calendar methods taking field should document exceptions
   
   Reviewed-by: naoto
 - 8306474: Move InstanceKlass read-only flags
   
   Reviewed-by: jrose, dholmes
 - ... and 26 more: https://git.openjdk.org/jdk/compare/aa346ef9...a427591c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13532/files
  - new: https://git.openjdk.org/jdk/pull/13532/files/aa346ef9..a427591c

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

  Stats: 7991 lines in 137 files changed: 7501 ins; 294 del; 196 mod
  Patch: https://git.openjdk.org/jdk/pull/13532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13532/head:pull/13532

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

From lkorinth at openjdk.org  Fri Apr 21 13:26:55 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 21 Apr 2023 13:26:55 GMT
Subject: RFR: 8306435: Juggle04/TestDescription.java should be a booleanArr
 test and not a byteArr one
Message-ID: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>

Each garbage producer should have three test description each with different `-ms` flags. A mistake was made when this file was created (probably because the first byteArr test is named differently).

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

Commit messages:
 - 8306435:

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

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

From lkorinth at openjdk.org  Fri Apr 21 13:26:56 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 21 Apr 2023 13:26:56 GMT
Subject: RFR: 8306435: Juggle04/TestDescription.java should be a booleanArr
 test and not a byteArr one
In-Reply-To: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
References: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
Message-ID: <oMIh2aivPQ6q5mj9zCC9GpIhaxYCmWLjv0zfGq0sKMs=.460d5e67-b0df-455e-83da-6c2a3e0e4c1d@github.com>

On Fri, 21 Apr 2023 13:19:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Each garbage producer should have three test description each with different `-ms` flags. A mistake was made when this file was created (probably because the first byteArr test is named differently).

If you type `rg -A1 ".*-gp .*Arr" --no-heading | sort` in test/hotspot/jtreg/vmTestbase/gc/ArrayJuggle, you will spot the problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/13580#issuecomment-1517829166

From tschatzl at openjdk.org  Fri Apr 21 13:34:46 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 21 Apr 2023 13:34:46 GMT
Subject: RFR: 8306435: Juggle04/TestDescription.java should be a booleanArr
 test and not a byteArr one
In-Reply-To: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
References: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
Message-ID: <st4N9JVvdzDmVAlECsGvL4VPWPSIJt_dpGom6EIOl7A=.27b247bc-7466-4d24-bb73-90bebedd5616@github.com>

On Fri, 21 Apr 2023 13:19:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Each garbage producer should have three test description each with different `-ms` flags. A mistake was made when this file was created (probably because the first byteArr test is named differently).

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13580#pullrequestreview-1395778614

From lmesnik at openjdk.org  Fri Apr 21 13:44:43 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 21 Apr 2023 13:44:43 GMT
Subject: RFR: 8306435: Juggle04/TestDescription.java should be a booleanArr
 test and not a byteArr one
In-Reply-To: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
References: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
Message-ID: <kJiZ1_J3mOJ8scCDUsf9GcH-_fAFwYzPisyK_oxK-Zs=.85240d86-218d-4d62-b237-dd3b9ec5a91c@github.com>

On Fri, 21 Apr 2023 13:19:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Each garbage producer should have three test description each with different `-ms` flags. A mistake was made when this file was created (probably because the first byteArr test is named differently).

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13580#pullrequestreview-1395793691

From shade at openjdk.org  Fri Apr 21 13:44:45 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 21 Apr 2023 13:44:45 GMT
Subject: RFR: 8306435: Juggle04/TestDescription.java should be a booleanArr
 test and not a byteArr one
In-Reply-To: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
References: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
Message-ID: <68u1AhrvzNU3pdZ35VjWtNOZKGzlnSW6DgedtattrWk=.098dfd73-f814-4afd-858d-9fb5442525e3@github.com>

On Fri, 21 Apr 2023 13:19:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Each garbage producer should have three test description each with different `-ms` flags. A mistake was made when this file was created (probably because the first byteArr test is named differently).

Marked as reviewed by shade (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13580#pullrequestreview-1395794769

From iwalulya at openjdk.org  Fri Apr 21 14:02:42 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 21 Apr 2023 14:02:42 GMT
Subject: RFR: 8306436: Rename PSS*:_n_workers to PSS*:_num_workers
In-Reply-To: <k6kWq6ZIa-rlmh4sSojpC_ZjbGgzQwclOBxximjQVWQ=.474dbae7-46c1-4cd1-ac49-044e5113ccdd@github.com>
References: <k6kWq6ZIa-rlmh4sSojpC_ZjbGgzQwclOBxximjQVWQ=.474dbae7-46c1-4cd1-ac49-044e5113ccdd@github.com>
Message-ID: <oPblhuiU9krIw3VUxDCdu8tEFxOcS8ihT5JSLqEExFs=.d2b8bc64-6611-45df-b1a1-bcb5df0c2f02@github.com>

On Wed, 19 Apr 2023 10:45:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this rename of the `_n_workers` member to `_num_workers` since the latter uses the more common prefix for amounts of things.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13531#pullrequestreview-1395826879

From tschatzl at openjdk.org  Fri Apr 21 14:09:03 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 21 Apr 2023 14:09:03 GMT
Subject: RFR: 8306436: Rename PSS*:_n_workers to PSS*:_num_workers
In-Reply-To: <k6kWq6ZIa-rlmh4sSojpC_ZjbGgzQwclOBxximjQVWQ=.474dbae7-46c1-4cd1-ac49-044e5113ccdd@github.com>
References: <k6kWq6ZIa-rlmh4sSojpC_ZjbGgzQwclOBxximjQVWQ=.474dbae7-46c1-4cd1-ac49-044e5113ccdd@github.com>
Message-ID: <LN4H-sT_RzUuiLKem_GPXhT4TlofSN9CbNndwIrdMyM=.9adc75f1-3151-441c-ba92-b67e41b02801@github.com>

On Wed, 19 Apr 2023 10:45:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this rename of the `_n_workers` member to `_num_workers` since the latter uses the more common prefix for amounts of things.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Thanks for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/13531#issuecomment-1517887129

From tschatzl at openjdk.org  Fri Apr 21 14:09:04 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 21 Apr 2023 14:09:04 GMT
Subject: Integrated: 8306436: Rename PSS*:_n_workers to PSS*:_num_workers
In-Reply-To: <k6kWq6ZIa-rlmh4sSojpC_ZjbGgzQwclOBxximjQVWQ=.474dbae7-46c1-4cd1-ac49-044e5113ccdd@github.com>
References: <k6kWq6ZIa-rlmh4sSojpC_ZjbGgzQwclOBxximjQVWQ=.474dbae7-46c1-4cd1-ac49-044e5113ccdd@github.com>
Message-ID: <5kkSFsrbFi3gt91Xyw-rHErzhWZEJmxz3ausCqQh2es=.cbf662fc-48d1-4dda-bc9e-c5b9fad55e04@github.com>

On Wed, 19 Apr 2023 10:45:13 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this rename of the `_n_workers` member to `_num_workers` since the latter uses the more common prefix for amounts of things.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 9cd5741c
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9cd5741c14358d6e9ffc97d63ba2d2adebf73ca2
Stats:     19 lines in 2 files changed: 2 ins; 0 del; 17 mod

8306436: Rename PSS*:_n_workers to PSS*:_num_workers

Reviewed-by: ayang, iwalulya

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

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

From tschatzl at openjdk.org  Fri Apr 21 14:21:00 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 21 Apr 2023 14:21:00 GMT
Subject: RFR: 8306440: Rename PSS:_num_optional_regions to
 _max_num_optional_regions [v3]
In-Reply-To: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
References: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
Message-ID: <kswYY8dI4fMMVY8MgA2sJB4WKctQtnvicXYrgmn0mMg=.f7e41dc2-11a4-47f1-93ef-8b71e6f8e87d@github.com>

> Hi all,
> 
>    please review this small change that clarifies the use of `PSS::_num_optional_regions` to be the initial amount of optional regions, not the current amount of optional regions.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - ayang review
 - Rename PSS:_num_optional_regions to _num_initial_optional_regions to emphasize that it's the initial amount of optional regions
   
   Rename the stated member to better indicate that this is the initial amount of optional
   region at the start of gc vs. the one for the current iteration of the evacuation.
   Optional.

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

Changes: https://git.openjdk.org/jdk/pull/13532/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13532&range=02
  Stats: 10 lines in 3 files changed: 1 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13532/head:pull/13532

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

From iwalulya at openjdk.org  Fri Apr 21 14:21:01 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Fri, 21 Apr 2023 14:21:01 GMT
Subject: RFR: 8306440: Rename PSS:_num_optional_regions to
 _max_num_optional_regions [v3]
In-Reply-To: <kswYY8dI4fMMVY8MgA2sJB4WKctQtnvicXYrgmn0mMg=.f7e41dc2-11a4-47f1-93ef-8b71e6f8e87d@github.com>
References: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
 <kswYY8dI4fMMVY8MgA2sJB4WKctQtnvicXYrgmn0mMg=.f7e41dc2-11a4-47f1-93ef-8b71e6f8e87d@github.com>
Message-ID: <MCegcvfG6AJXCbUPDPCuqPQ4_VmqVAimSl-QdMxt7zI=.de710680-4af7-488f-ab07-96f0e7c24bfb@github.com>

On Fri, 21 Apr 2023 14:17:01 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>    please review this small change that clarifies the use of `PSS::_num_optional_regions` to be the initial amount of optional regions, not the current amount of optional regions.
>> 
>> Testing: gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - ayang review
>  - Rename PSS:_num_optional_regions to _num_initial_optional_regions to emphasize that it's the initial amount of optional regions
>    
>    Rename the stated member to better indicate that this is the initial amount of optional
>    region at the start of gc vs. the one for the current iteration of the evacuation.
>    Optional.

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13532#pullrequestreview-1395853110

From tschatzl at openjdk.org  Fri Apr 21 14:21:02 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 21 Apr 2023 14:21:02 GMT
Subject: RFR: 8306440: Rename PSS:_num_optional_regions to
 _max_num_optional_regions [v3]
In-Reply-To: <ZFOguVsgSBwRIj7_XwfMGGKEQWMEAyHPWQNACAJQsyY=.10c9e3f2-8bdd-49ca-8e30-b518d20962df@github.com>
References: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
 <ZFOguVsgSBwRIj7_XwfMGGKEQWMEAyHPWQNACAJQsyY=.10c9e3f2-8bdd-49ca-8e30-b518d20962df@github.com>
Message-ID: <TsKxgp3zurkweJfnRe-SsQUXr2Yr2xhccP0KUp8OGGg=.93fb367c-93df-465d-9c23-112cd07f415f@github.com>

On Fri, 21 Apr 2023 09:23:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - ayang review
>>  - Rename PSS:_num_optional_regions to _num_initial_optional_regions to emphasize that it's the initial amount of optional regions
>>    
>>    Rename the stated member to better indicate that this is the initial amount of optional
>>    region at the start of gc vs. the one for the current iteration of the evacuation.
>>    Optional.
>
> I feel `_max_num_optional_regions` better reflects its intrinsic semantic.
> 
> Inside young-gc pause, `initial` and `optional` most often refer to the dual initial-evac vs optional-evac and everything associated with them. Therefore, it can be confusing to see both words in one name.
> 
> (Ofc, this is quite subjective.)

Thanks @albertnetymk @walulyai for your reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/13532#issuecomment-1517902262

From tschatzl at openjdk.org  Fri Apr 21 14:21:04 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Fri, 21 Apr 2023 14:21:04 GMT
Subject: Integrated: 8306440: Rename PSS:_num_optional_regions to
 _max_num_optional_regions
In-Reply-To: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
References: <NgZQ5ghTQmgbeuF9kfFzCzX50uvMgTuNj5rmH2v2GJw=.90c6e818-acd7-4dbd-996d-7585f2adfeac@github.com>
Message-ID: <M3aQnaM-FqnH4d411xKT8QxXDkc47qgtfHNCbJpgo18=.35b167e6-99fc-44e4-8148-5272e855d4d7@github.com>

On Wed, 19 Apr 2023 11:13:36 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>    please review this small change that clarifies the use of `PSS::_num_optional_regions` to be the initial amount of optional regions, not the current amount of optional regions.
> 
> Testing: gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: d518dbf7
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d518dbf726ca41f4566df74deed6adeb39ce2ed7
Stats:     10 lines in 3 files changed: 1 ins; 0 del; 9 mod

8306440: Rename PSS:_num_optional_regions to _max_num_optional_regions

Reviewed-by: ayang, iwalulya

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

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

From kbarrett at openjdk.org  Sun Apr 23 01:10:05 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 23 Apr 2023 01:10:05 GMT
Subject: RFR: 8306695: Divide by zero in G1Policy::logged_cards_processing_time
Message-ID: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>

Please review this change to G1Policy::logged_cards_processing_time to avoid a
floating point division by zero when both the number of logged cards and the
total cards processed are zero.  This happens during early GCs.  The fix is to
change the comparison used to decide between scaling the total time vs
ascribing all of the time to the logged cards.  It is changed from ">" to ">="
so that it also covers the case of both values being zero.

Testing:
mach5 tier1
Local build with UBSAN and verified there are no longer any division by zero
errors reported by it.

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

Commit messages:
 - fix

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

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

From lkorinth at openjdk.org  Mon Apr 24 08:05:09 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 24 Apr 2023 08:05:09 GMT
Subject: RFR: 8306435: Juggle04/TestDescription.java should be a booleanArr
 test and not a byteArr one
In-Reply-To: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
References: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
Message-ID: <m_ETyolmdd3e7MPLucVwAQ0YSd0LaLWsEDcEk2qqZZg=.a640c200-32b3-489f-8321-171d6e274f8d@github.com>

On Fri, 21 Apr 2023 13:19:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Each garbage producer should have three test description each with different `-ms` flags. A mistake was made when this file was created (probably because the first byteArr test is named differently).

Thanks for your review!

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

PR Comment: https://git.openjdk.org/jdk/pull/13580#issuecomment-1519578164

From lkorinth at openjdk.org  Mon Apr 24 08:05:10 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 24 Apr 2023 08:05:10 GMT
Subject: Integrated: 8306435: Juggle04/TestDescription.java should be a
 booleanArr test and not a byteArr one
In-Reply-To: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
References: <EulK7d7952XzZJDmjHeAb53G2qxDhRw8LupuLxVA9pU=.07903d04-6cab-4620-9b8e-b70de286c6a4@github.com>
Message-ID: <RuOYCyYgABsblVo5oFKxs7-ZeuvgnAEfPH_J9QkrwNk=.455ae06a-8735-4f9e-b452-dbf4fc33bc9a@github.com>

On Fri, 21 Apr 2023 13:19:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> Each garbage producer should have three test description each with different `-ms` flags. A mistake was made when this file was created (probably because the first byteArr test is named differently).

This pull request has now been integrated.

Changeset: ce493dda
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce493dda9066b70f9541a8e06349fa81f79bb66c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8306435: Juggle04/TestDescription.java should be a booleanArr test and not a byteArr one

Reviewed-by: tschatzl, lmesnik, shade

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

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

From iwalulya at openjdk.org  Mon Apr 24 08:19:45 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 24 Apr 2023 08:19:45 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region [v3]
In-Reply-To: <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>
Message-ID: <MaCEeQhxlebYD2clk-nBFQd4NjWYTdUBxK-DqVo2QnY=.12e9730b-02fa-4f80-8535-26a656f2efc1@github.com>

On Tue, 18 Apr 2023 09:21:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13206#pullrequestreview-1397424069

From tschatzl at openjdk.org  Mon Apr 24 08:34:47 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 24 Apr 2023 08:34:47 GMT
Subject: RFR: 8306695: Divide by zero in
 G1Policy::logged_cards_processing_time
In-Reply-To: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>
References: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>
Message-ID: <ApgWShlxhKQkrrbUDyY07NJSumEAwhFfcDNC7SsvcxQ=.34aa6dac-0bd8-486c-b46d-da193195af2b@github.com>

On Sun, 23 Apr 2023 01:01:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to G1Policy::logged_cards_processing_time to avoid a
> floating point division by zero when both the number of logged cards and the
> total cards processed are zero.  This happens during early GCs.  The fix is to
> change the comparison used to decide between scaling the total time vs
> ascribing all of the time to the logged cards.  It is changed from ">" to ">="
> so that it also covers the case of both values being zero.
> 
> Testing:
> mach5 tier1
> Local build with UBSAN and verified there are no longer any division by zero
> errors reported by it.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13601#pullrequestreview-1397450335

From iwalulya at openjdk.org  Mon Apr 24 08:34:47 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 24 Apr 2023 08:34:47 GMT
Subject: RFR: 8306695: Divide by zero in
 G1Policy::logged_cards_processing_time
In-Reply-To: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>
References: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>
Message-ID: <NK8zjFKAzIYPXJKGQzA2z2DUHNVFzDRcIGh9oT8deCM=.7a32949e-1f3a-4582-b3ee-94cee0307403@github.com>

On Sun, 23 Apr 2023 01:01:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to G1Policy::logged_cards_processing_time to avoid a
> floating point division by zero when both the number of logged cards and the
> total cards processed are zero.  This happens during early GCs.  The fix is to
> change the comparison used to decide between scaling the total time vs
> ascribing all of the time to the logged cards.  It is changed from ">" to ">="
> so that it also covers the case of both values being zero.
> 
> Testing:
> mach5 tier1
> Local build with UBSAN and verified there are no longer any division by zero
> errors reported by it.

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13601#pullrequestreview-1397448974

From iwalulya at openjdk.org  Mon Apr 24 08:40:48 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 24 Apr 2023 08:40:48 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region [v3]
In-Reply-To: <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>
Message-ID: <t3sEI5qOuoVFpYaxONJHPrBaXJv6BIUtbo7Q0sQ5t_E=.12cb4eed-fc83-4741-bbfa-51a0ab09d3d3@github.com>

On Tue, 18 Apr 2023 09:21:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Errors flagged by pre-submit

Marked as reviewed by iwalulya (Reviewer).

Check the pre-submit test errors.

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

Changes requested by iwalulya (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13206#pullrequestreview-1397456405
PR Review: https://git.openjdk.org/jdk/pull/13206#pullrequestreview-1397459121
PR Comment: https://git.openjdk.org/jdk/pull/13206#issuecomment-1519627160

From iwalulya at openjdk.org  Mon Apr 24 08:40:49 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 24 Apr 2023 08:40:49 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region [v3]
In-Reply-To: <t3sEI5qOuoVFpYaxONJHPrBaXJv6BIUtbo7Q0sQ5t_E=.12cb4eed-fc83-4741-bbfa-51a0ab09d3d3@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>
 <t3sEI5qOuoVFpYaxONJHPrBaXJv6BIUtbo7Q0sQ5t_E=.12cb4eed-fc83-4741-bbfa-51a0ab09d3d3@github.com>
Message-ID: <plXKcmanCTwa4RXw9TamKTln2O1pCK3_gTulk9cQpQo=.b02ab297-0755-4d06-9e83-1cfd7a4f33d5@github.com>

On Mon, 24 Apr 2023 08:36:00 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Errors flagged by pre-submit

Don't seem related to this change, but please verify.

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

PR Comment: https://git.openjdk.org/jdk/pull/13206#issuecomment-1519632057

From iwalulya at openjdk.org  Mon Apr 24 08:47:49 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 24 Apr 2023 08:47:49 GMT
Subject: RFR: 8057586: Explicit GC ignored if GCLocker is active [v10]
In-Reply-To: <JLW7rnwDdVeYk4ZKgfrRp87TgkMBNz16MgSyEMItLE0=.ba88c6ed-b583-4485-b1f3-6f862836ab9f@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
 <ToaKlPUK-mTXElRNxfC3OKxMVxBTwFJOZ4X_wQHveZo=.f286192b-4c5c-4623-9ab7-9bf4f55a84cc@github.com>
 <JLW7rnwDdVeYk4ZKgfrRp87TgkMBNz16MgSyEMItLE0=.ba88c6ed-b583-4485-b1f3-6f862836ab9f@github.com>
Message-ID: <BtHuybktT-88zmWS-1l2zforDziaSwfr3GxF1kVes-w=.d8788685-7438-405b-888c-cab8e62918d0@github.com>

On Thu, 20 Apr 2023 16:29:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Ivan Walulya has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Albert Review
>
> Marked as reviewed by ayang (Reviewer).

Thanks, @albertnetymk and @tschatzl for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/13191#issuecomment-1519641712

From iwalulya at openjdk.org  Mon Apr 24 08:51:06 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 24 Apr 2023 08:51:06 GMT
Subject: Integrated: 8057586: Explicit GC ignored if GCLocker is active
In-Reply-To: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
References: <TzwRa489lno5tzzNC63u_wyhR6emnurJhxzVylGcUes=.3052d746-fbf9-499e-9910-3ac221b2d74d@github.com>
Message-ID: <djHydCEZ2bpMAX1xGCvKyGlSaTdFvXO1yN53xC3SL84=.e60adf6e-6ad6-4982-8938-87b0b76ac7e6@github.com>

On Mon, 27 Mar 2023 13:41:32 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi All,
> 
> Please review this change to guarantee that at least a Full GC is executed between the invocation and return of an explicit Full GC call, even if the call is concurrent with an active `GCLocker`.  We specify explicit GCs as GCs triggered by the end user in some form (jcmd, System.GC, or WhiteBox testing).
> 
> The change should also handle the issues reported in JDK-8299276.
> 
> Split into 3 commits, one commit for changes to each GC in [G1, Parallel, Serial]. 
> 
> Testing: Tier 1-5.

This pull request has now been integrated.

Changeset: 4a9f8efa
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a9f8efa867f84463f054d6624bcc5a89033e152
Stats:     332 lines in 12 files changed: 310 ins; 4 del; 18 mod

8057586: Explicit GC ignored if GCLocker is active

Reviewed-by: tschatzl, ayang

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

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

From ayang at openjdk.org  Mon Apr 24 10:30:56 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 24 Apr 2023 10:30:56 GMT
Subject: RFR: 8305062: Refactor CardTable::resize_covered_region [v3]
In-Reply-To: <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
 <Zekkv3572cENJu2pkOT3CcfasPyKa2KKPXWIs3KeP7Q=.5712444f-f901-4047-bddd-de183be045c3@github.com>
Message-ID: <aUEvOoStI-ZaqMIXGoIRJ7bTrgR80KVVzAkPiKLhuFs=.d483eae8-3088-4ecf-bad7-576ff4c92818@github.com>

On Tue, 18 Apr 2023 09:21:54 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
>> 
>> Test: tier1-6
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13206#issuecomment-1519863653

From ayang at openjdk.org  Mon Apr 24 10:30:58 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 24 Apr 2023 10:30:58 GMT
Subject: Integrated: 8305062: Refactor CardTable::resize_covered_region
In-Reply-To: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
References: <Mz-g9AoMKGokPnQkr74nOxasT2iWSf34ArGJXkeU1MU=.a6eb000a-c0db-4687-8dff-c60254eea2ee@github.com>
Message-ID: <49OU5ZzgrxjYMJpOuwzBFDqjh9enPuDVRdOrOPChKiM=.fb87790f-9ec6-407d-a156-e1d643137388@github.com>

On Tue, 28 Mar 2023 09:59:51 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to make logic around cardtable cover-region more concrete, since #generations and gen-boundary is fixed for Serial/Parallel.
> 
> Test: tier1-6

This pull request has now been integrated.

Changeset: 30fa50d1
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/30fa50d15854ffaec2f17882710e9f09f829b77a
Stats:     277 lines in 8 files changed: 27 ins; 180 del; 70 mod

8305062: Refactor CardTable::resize_covered_region

Reviewed-by: tschatzl, iwalulya

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

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

From tschatzl at openjdk.org  Mon Apr 24 10:46:58 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 24 Apr 2023 10:46:58 GMT
Subject: RFR: 8306733: Remove template paramter of
 G1DetermineCompactionQueueClosure::free_pinned_region
Message-ID: <P4QOGP0XOTeMxXyB-oxa0kvoH7XEWj3Y5xNSi6PrMew=.85e7406e-d88a-4379-be9d-eadc2ce6204e@github.com>

Hi all,

  after [JDK-8298048](https://bugs.openjdk.org/browse/JDK-8298048) G1DetermineCompactionQueueClosure::free_pinned_region() may only be called with humongous regions, so the template parameter is unnecessary. This PR removes it.
I kept the method itself (not inlined) because I believe its name acts as a good documentation what is done here at the place it is called, even if it's only 3 LOC.

Testing: local compilation, gha

Thanks,
  Thomas

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

Commit messages:
 - After JDK-8298048 G1DetermineCompactionQueueClosure::free_pinned_region() may only be called with humongous regions, so the template parameter is unnecessary.

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

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

From ayang at openjdk.org  Mon Apr 24 11:37:42 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 24 Apr 2023 11:37:42 GMT
Subject: RFR: 8306733: Remove template parameter of
 G1DetermineCompactionQueueClosure::free_pinned_region
In-Reply-To: <P4QOGP0XOTeMxXyB-oxa0kvoH7XEWj3Y5xNSi6PrMew=.85e7406e-d88a-4379-be9d-eadc2ce6204e@github.com>
References: <P4QOGP0XOTeMxXyB-oxa0kvoH7XEWj3Y5xNSi6PrMew=.85e7406e-d88a-4379-be9d-eadc2ce6204e@github.com>
Message-ID: <o-ML9MBBt0nh8jyQJhyxU0Qwm2e2Pu4p3plMVSLAL0U=.7d771446-a2c4-4085-9d9f-48654e5a1ae2@github.com>

On Mon, 24 Apr 2023 10:39:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   after [JDK-8298048](https://bugs.openjdk.org/browse/JDK-8298048) G1DetermineCompactionQueueClosure::free_pinned_region() may only be called with humongous regions, so the template parameter is unnecessary. This PR removes it.
> I kept the method itself (not inlined) because I believe its name acts as a good documentation what is done here at the place it is called, even if it's only 3 LOC.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Inlining it is more readable, IMO. For example, it's not obvious whether `add_to_compaction_queue` should be the caller or the callee.

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

Marked as reviewed by ayang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13610#pullrequestreview-1397767548

From ayang at openjdk.org  Mon Apr 24 11:50:46 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 24 Apr 2023 11:50:46 GMT
Subject: RFR: 8306740: G1: Change G1CardSetHashTableScan to lambda
Message-ID: <QlEgYerB89biMK57ZN9oP70S27fjktOBEmGIigIS1R0=.ab5f8319-62df-482b-8ade-60cd17bbb7dc@github.com>

Simple refactoring a closure class to lambda.

Test: hotspot_gc

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

Commit messages:
 - g1-lambda

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

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

From iwalulya at openjdk.org  Mon Apr 24 12:11:44 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 24 Apr 2023 12:11:44 GMT
Subject: RFR: 8306733: Remove template parameter of
 G1DetermineCompactionQueueClosure::free_pinned_region
In-Reply-To: <P4QOGP0XOTeMxXyB-oxa0kvoH7XEWj3Y5xNSi6PrMew=.85e7406e-d88a-4379-be9d-eadc2ce6204e@github.com>
References: <P4QOGP0XOTeMxXyB-oxa0kvoH7XEWj3Y5xNSi6PrMew=.85e7406e-d88a-4379-be9d-eadc2ce6204e@github.com>
Message-ID: <HSzLOZnhZbYWVInlLMsA1MrRM2R3qYayCFXAvx-H5oA=.4c369a82-b91a-4431-bea4-39029e9ac528@github.com>

On Mon, 24 Apr 2023 10:39:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   after [JDK-8298048](https://bugs.openjdk.org/browse/JDK-8298048) G1DetermineCompactionQueueClosure::free_pinned_region() may only be called with humongous regions, so the template parameter is unnecessary. This PR removes it.
> I kept the method itself (not inlined) because I believe its name acts as a good documentation what is done here at the place it is called, even if it's only 3 LOC.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by iwalulya (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13610#pullrequestreview-1397842793

From ayang at openjdk.org  Mon Apr 24 13:16:57 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 24 Apr 2023 13:16:57 GMT
Subject: RFR: 8306749: Make CardTable::invalidate non-virtual
Message-ID: <0MS_quDT5evJWvVp2YSg1o0Xt7qZ7-F6WNUc34zqsT0=.784db7be-75ba-4280-b461-264739c402ad@github.com>

Trivial removing unused `virtual` specifier.

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

Commit messages:
 - card-table-remove-virtual

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

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

From kbarrett at openjdk.org  Mon Apr 24 16:54:51 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 24 Apr 2023 16:54:51 GMT
Subject: RFR: 8306740: G1: Change G1CardSetHashTableScan to lambda
In-Reply-To: <QlEgYerB89biMK57ZN9oP70S27fjktOBEmGIigIS1R0=.ab5f8319-62df-482b-8ade-60cd17bbb7dc@github.com>
References: <QlEgYerB89biMK57ZN9oP70S27fjktOBEmGIigIS1R0=.ab5f8319-62df-482b-8ade-60cd17bbb7dc@github.com>
Message-ID: <ySunvqKVs24TVu6Mpqv6V4-fJhXhl_MvTqJ9Lf-OiLE=.e0e23810-5230-43b0-8207-2db41d8ffdf2@github.com>

On Mon, 24 Apr 2023 11:43:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring a closure class to lambda.
> 
> Test: hotspot_gc

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13612#pullrequestreview-1398444585

From iwalulya at openjdk.org  Mon Apr 24 17:07:59 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Mon, 24 Apr 2023 17:07:59 GMT
Subject: RFR: 8306766: Reduce heap size for TestJNICriticalStressTest
Message-ID: <5KT6zrYiWqQPrV34UvbZKF2UL2jWg1bHnnCpYHPJZnM=.07bcdbf7-f92b-494f-a48b-0cc6c4c1341a@github.com>

Hi all,

Please review this change to reduce the heap size for the test TestJNICriticalStressTest. The test fails in GHA where 32-bit machines fail to reserve the current heap size (3g).

Testing: locally.

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

Commit messages:
 - reduce heap size

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

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

From ayang at openjdk.org  Mon Apr 24 17:11:51 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 24 Apr 2023 17:11:51 GMT
Subject: RFR: 8306766: Reduce heap size for TestJNICriticalStressTest
In-Reply-To: <5KT6zrYiWqQPrV34UvbZKF2UL2jWg1bHnnCpYHPJZnM=.07bcdbf7-f92b-494f-a48b-0cc6c4c1341a@github.com>
References: <5KT6zrYiWqQPrV34UvbZKF2UL2jWg1bHnnCpYHPJZnM=.07bcdbf7-f92b-494f-a48b-0cc6c4c1341a@github.com>
Message-ID: <PnmN5Ply3-nuSGB3QRiVKP0nL3EIaY0GRWx6YrjWgUI=.251cb8a9-4aba-4425-8356-af04c83be572@github.com>

On Mon, 24 Apr 2023 16:59:34 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to reduce the heap size for the test TestJNICriticalStressTest. The test fails in GHA where 32-bit machines fail to reserve the current heap size (3g).
> 
> Testing: locally.

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13619#pullrequestreview-1398470530

From kbarrett at openjdk.org  Tue Apr 25 04:25:31 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 25 Apr 2023 04:25:31 GMT
Subject: RFR: 8306695: Divide by zero in
 G1Policy::logged_cards_processing_time [v2]
In-Reply-To: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>
References: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>
Message-ID: <QDZ2MFi6-Vclsh3-DotFOufTqxXmP7DAOJlrxJa590I=.5323f374-ec22-4770-b1dd-d2eaf86c2768@github.com>

> Please review this change to G1Policy::logged_cards_processing_time to avoid a
> floating point division by zero when both the number of logged cards and the
> total cards processed are zero.  This happens during early GCs.  The fix is to
> change the comparison used to decide between scaling the total time vs
> ascribing all of the time to the logged cards.  It is changed from ">" to ">="
> so that it also covers the case of both values being zero.
> 
> Testing:
> mach5 tier1
> Local build with UBSAN and verified there are no longer any division by zero
> errors reported by it.

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

 - Merge branch 'master' into policy-div0
 - fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13601/files
  - new: https://git.openjdk.org/jdk/pull/13601/files/5d00bd2f..7a6ac793

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

  Stats: 4621 lines in 95 files changed: 3526 ins; 784 del; 311 mod
  Patch: https://git.openjdk.org/jdk/pull/13601.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13601/head:pull/13601

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

From kbarrett at openjdk.org  Tue Apr 25 04:25:32 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 25 Apr 2023 04:25:32 GMT
Subject: RFR: 8306695: Divide by zero in
 G1Policy::logged_cards_processing_time [v2]
In-Reply-To: <ApgWShlxhKQkrrbUDyY07NJSumEAwhFfcDNC7SsvcxQ=.34aa6dac-0bd8-486c-b46d-da193195af2b@github.com>
References: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>
 <ApgWShlxhKQkrrbUDyY07NJSumEAwhFfcDNC7SsvcxQ=.34aa6dac-0bd8-486c-b46d-da193195af2b@github.com>
Message-ID: <MeJSk4FEW89Xm7ZM-Zr48vA4rfecRzgGkwpdtsEFUNg=.b7b14b65-0187-417f-84b6-e89c7266e886@github.com>

On Mon, 24 Apr 2023 08:32:16 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into policy-div0
>>  - fix
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks @tschatzl and @walulyai for reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/13601#issuecomment-1521133054

From kbarrett at openjdk.org  Tue Apr 25 04:25:33 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 25 Apr 2023 04:25:33 GMT
Subject: Integrated: 8306695: Divide by zero in
 G1Policy::logged_cards_processing_time
In-Reply-To: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>
References: <WPff60C9FNMod3NusgB4FbyBsYQDAfcKBooMwVAc8yc=.4b6c45db-a50f-4a64-a27b-48e4af94644f@github.com>
Message-ID: <vWZidaahiLDWiHe4hMBC2XDDnUWJ1znIeWActn8s6Tg=.b2a0fce3-e801-4d29-b813-b4fb5f92c2d3@github.com>

On Sun, 23 Apr 2023 01:01:53 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to G1Policy::logged_cards_processing_time to avoid a
> floating point division by zero when both the number of logged cards and the
> total cards processed are zero.  This happens during early GCs.  The fix is to
> change the comparison used to decide between scaling the total time vs
> ascribing all of the time to the logged cards.  It is changed from ">" to ">="
> so that it also covers the case of both values being zero.
> 
> Testing:
> mach5 tier1
> Local build with UBSAN and verified there are no longer any division by zero
> errors reported by it.

This pull request has now been integrated.

Changeset: 8063aa2e
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8063aa2e4a71d3f9f7867563bae92a4f75097b2a
Stats:     10 lines in 1 file changed: 7 ins; 0 del; 3 mod

8306695: Divide by zero in G1Policy::logged_cards_processing_time

Reviewed-by: iwalulya, tschatzl

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

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

From tschatzl at openjdk.org  Tue Apr 25 07:51:07 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 07:51:07 GMT
Subject: RFR: 8306766: Reduce heap size for TestJNICriticalStressTest
In-Reply-To: <5KT6zrYiWqQPrV34UvbZKF2UL2jWg1bHnnCpYHPJZnM=.07bcdbf7-f92b-494f-a48b-0cc6c4c1341a@github.com>
References: <5KT6zrYiWqQPrV34UvbZKF2UL2jWg1bHnnCpYHPJZnM=.07bcdbf7-f92b-494f-a48b-0cc6c4c1341a@github.com>
Message-ID: <GG5zEaehArDdF2cWziEJ2Iy7aCNOwizd8re7z6Fevfs=.b7923c50-a9ad-4f59-9153-7c976ff472d5@github.com>

On Mon, 24 Apr 2023 16:59:34 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to reduce the heap size for the test TestJNICriticalStressTest. The test fails in GHA where 32-bit machines fail to reserve the current heap size (3g).
> 
> Testing: locally.

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13619#pullrequestreview-1399328036

From iwalulya at openjdk.org  Tue Apr 25 10:30:19 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 25 Apr 2023 10:30:19 GMT
Subject: RFR: 8306766: Reduce heap size for TestJNICriticalStressTest
In-Reply-To: <5KT6zrYiWqQPrV34UvbZKF2UL2jWg1bHnnCpYHPJZnM=.07bcdbf7-f92b-494f-a48b-0cc6c4c1341a@github.com>
References: <5KT6zrYiWqQPrV34UvbZKF2UL2jWg1bHnnCpYHPJZnM=.07bcdbf7-f92b-494f-a48b-0cc6c4c1341a@github.com>
Message-ID: <dpKH46-TmazQpX8nhIsuCV8x8Lo_XLXUekTwSlDN-_M=.122cda4d-cebe-4ebb-be99-262a5ceb5b1c@github.com>

On Mon, 24 Apr 2023 16:59:34 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to reduce the heap size for the test TestJNICriticalStressTest. The test fails in GHA where 32-bit machines fail to reserve the current heap size (3g).
> 
> Testing: locally.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/13619#issuecomment-1521547362

From iwalulya at openjdk.org  Tue Apr 25 10:30:20 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 25 Apr 2023 10:30:20 GMT
Subject: Integrated: 8306766: Reduce heap size for TestJNICriticalStressTest
In-Reply-To: <5KT6zrYiWqQPrV34UvbZKF2UL2jWg1bHnnCpYHPJZnM=.07bcdbf7-f92b-494f-a48b-0cc6c4c1341a@github.com>
References: <5KT6zrYiWqQPrV34UvbZKF2UL2jWg1bHnnCpYHPJZnM=.07bcdbf7-f92b-494f-a48b-0cc6c4c1341a@github.com>
Message-ID: <JvLgl4RzudRjfP9MFU6eOfu6W0QvsvxNgR2S5NxVaRk=.2551aa6b-0ec0-4141-9ffa-2daf2797f458@github.com>

On Mon, 24 Apr 2023 16:59:34 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi all,
> 
> Please review this change to reduce the heap size for the test TestJNICriticalStressTest. The test fails in GHA where 32-bit machines fail to reserve the current heap size (3g).
> 
> Testing: locally.

This pull request has now been integrated.

Changeset: a98f5875
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a98f58756d61f01c6c7bfdf27a119aae29dc5b2a
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8306766: Reduce heap size for TestJNICriticalStressTest

Reviewed-by: ayang, tschatzl

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

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

From ayang at openjdk.org  Tue Apr 25 10:38:04 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Apr 2023 10:38:04 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array
Message-ID: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>

Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.

Test: hotspot_gc

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

Commit messages:
 - card-table-array-field

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

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

From tschatzl at openjdk.org  Tue Apr 25 10:43:20 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 10:43:20 GMT
Subject: RFR: 8306733: Remove template parameter of
 G1DetermineCompactionQueueClosure::free_pinned_region
In-Reply-To: <P4QOGP0XOTeMxXyB-oxa0kvoH7XEWj3Y5xNSi6PrMew=.85e7406e-d88a-4379-be9d-eadc2ce6204e@github.com>
References: <P4QOGP0XOTeMxXyB-oxa0kvoH7XEWj3Y5xNSi6PrMew=.85e7406e-d88a-4379-be9d-eadc2ce6204e@github.com>
Message-ID: <cRiZlSW7_39Whuz1SmVw9GT9tts-9KzM76fitrjnvDg=.11a3ad9b-885f-4047-96dc-895b2634c65a@github.com>

On Mon, 24 Apr 2023 10:39:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   after [JDK-8298048](https://bugs.openjdk.org/browse/JDK-8298048) G1DetermineCompactionQueueClosure::free_pinned_region() may only be called with humongous regions, so the template parameter is unnecessary. This PR removes it.
> I kept the method itself (not inlined) because I believe its name acts as a good documentation what is done here at the place it is called, even if it's only 3 LOC.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

Thanks for your reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/13610#issuecomment-1521565357

From tschatzl at openjdk.org  Tue Apr 25 10:43:21 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 10:43:21 GMT
Subject: Integrated: 8306733: Remove template parameter of
 G1DetermineCompactionQueueClosure::free_pinned_region
In-Reply-To: <P4QOGP0XOTeMxXyB-oxa0kvoH7XEWj3Y5xNSi6PrMew=.85e7406e-d88a-4379-be9d-eadc2ce6204e@github.com>
References: <P4QOGP0XOTeMxXyB-oxa0kvoH7XEWj3Y5xNSi6PrMew=.85e7406e-d88a-4379-be9d-eadc2ce6204e@github.com>
Message-ID: <GOiU-vwQA_mgPBMzr7Zx4dq36KlPKcI2-qvzBAcfkEA=.23edef21-3b93-4699-934c-a5f2fd2b4fe6@github.com>

On Mon, 24 Apr 2023 10:39:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   after [JDK-8298048](https://bugs.openjdk.org/browse/JDK-8298048) G1DetermineCompactionQueueClosure::free_pinned_region() may only be called with humongous regions, so the template parameter is unnecessary. This PR removes it.
> I kept the method itself (not inlined) because I believe its name acts as a good documentation what is done here at the place it is called, even if it's only 3 LOC.
> 
> Testing: local compilation, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: a4a53858
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a4a5385831b58e66fe3f34cef618643f9be68c9e
Stats:     10 lines in 2 files changed: 0 ins; 6 del; 4 mod

8306733: Remove template parameter of G1DetermineCompactionQueueClosure::free_pinned_region

Reviewed-by: ayang, iwalulya

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

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

From tschatzl at openjdk.org  Tue Apr 25 10:43:09 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 10:43:09 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array
In-Reply-To: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
Message-ID: <dI2lvMoGBUH2LSQv99ka6q3UDzyKIsKBTtYtL5d14wg=.c051bdb6-2c64-465f-8a7a-e5624d087218@github.com>

On Tue, 25 Apr 2023 10:30:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
> 
> Test: hotspot_gc

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13636#pullrequestreview-1399632849

From tschatzl at openjdk.org  Tue Apr 25 10:44:10 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 10:44:10 GMT
Subject: RFR: 8306749: Make CardTable::invalidate non-virtual
In-Reply-To: <0MS_quDT5evJWvVp2YSg1o0Xt7qZ7-F6WNUc34zqsT0=.784db7be-75ba-4280-b461-264739c402ad@github.com>
References: <0MS_quDT5evJWvVp2YSg1o0Xt7qZ7-F6WNUc34zqsT0=.784db7be-75ba-4280-b461-264739c402ad@github.com>
Message-ID: <iyQtfY2L3ER3qGtOSyr1vLSmlzVgPDHpAw_NE2E9Za8=.7da89e78-7c07-4256-96c2-f0ca6c1f2fc1@github.com>

On Mon, 24 Apr 2023 13:08:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unused `virtual` specifier.

Lgtm and trivial.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13617#pullrequestreview-1399634788

From tschatzl at openjdk.org  Tue Apr 25 10:45:08 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 10:45:08 GMT
Subject: RFR: 8306740: G1: Change G1CardSetHashTableScan to lambda
In-Reply-To: <QlEgYerB89biMK57ZN9oP70S27fjktOBEmGIigIS1R0=.ab5f8319-62df-482b-8ade-60cd17bbb7dc@github.com>
References: <QlEgYerB89biMK57ZN9oP70S27fjktOBEmGIigIS1R0=.ab5f8319-62df-482b-8ade-60cd17bbb7dc@github.com>
Message-ID: <0dJD-jg5PHyuxhAbzIHRpVy6pZJzs1aFpY_ubZXhGrQ=.710ad9c4-271c-437b-a14e-57f163d8a3f1@github.com>

On Mon, 24 Apr 2023 11:43:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring a closure class to lambda.
> 
> Test: hotspot_gc

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13612#pullrequestreview-1399636269

From iwalulya at openjdk.org  Tue Apr 25 11:13:15 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Tue, 25 Apr 2023 11:13:15 GMT
Subject: RFR: 8306735: G1: G1FullGCScope remove unnecessary member _explicit_gc
Message-ID: <uJBqSNy76CE6ahqOiHT8XfBs71m2T1jJUyhxLdqIcIg=.145eaf84-c361-4dfb-9838-e48ac0c22e1d@github.com>

Hi All,

Please review this change to remove the unnecessary `explicit_gc` member from G1FullGCScope. We can rely on gc_cause() to determine whether the explicit_gc is true where required. 

Testing: tier1_gc

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

Commit messages:
 - Remove _explicit_gc

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

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

From ayang at openjdk.org  Tue Apr 25 11:18:07 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Apr 2023 11:18:07 GMT
Subject: RFR: 8306735: G1: G1FullGCScope remove unnecessary member
 _explicit_gc
In-Reply-To: <uJBqSNy76CE6ahqOiHT8XfBs71m2T1jJUyhxLdqIcIg=.145eaf84-c361-4dfb-9838-e48ac0c22e1d@github.com>
References: <uJBqSNy76CE6ahqOiHT8XfBs71m2T1jJUyhxLdqIcIg=.145eaf84-c361-4dfb-9838-e48ac0c22e1d@github.com>
Message-ID: <nnuCfokmnnnCFIlBUsNHur6e0MV2dVM73StrVpspuAQ=.e1ba7c1a-196c-42e8-8beb-88eb944b9937@github.com>

On Tue, 25 Apr 2023 11:05:21 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi All,
> 
> Please review this change to remove the unnecessary `explicit_gc` member from G1FullGCScope. We can rely on gc_cause() to determine whether the explicit_gc is true where required. 
> 
> Testing: tier1_gc

Marked as reviewed by ayang (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13638#pullrequestreview-1399685194

From tschatzl at openjdk.org  Tue Apr 25 11:24:07 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 11:24:07 GMT
Subject: RFR: 8306735: G1: G1FullGCScope remove unnecessary member
 _explicit_gc
In-Reply-To: <uJBqSNy76CE6ahqOiHT8XfBs71m2T1jJUyhxLdqIcIg=.145eaf84-c361-4dfb-9838-e48ac0c22e1d@github.com>
References: <uJBqSNy76CE6ahqOiHT8XfBs71m2T1jJUyhxLdqIcIg=.145eaf84-c361-4dfb-9838-e48ac0c22e1d@github.com>
Message-ID: <8PiM4E1IRTGhAySdr7aOoUao6eAjL4-TSmy40QN8iyE=.74321654-db48-4e6c-8220-26412f0886a9@github.com>

On Tue, 25 Apr 2023 11:05:21 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi All,
> 
> Please review this change to remove the unnecessary `explicit_gc` member from G1FullGCScope. We can rely on gc_cause() to determine whether the explicit_gc is true where required. 
> 
> Testing: tier1_gc

Marked as reviewed by tschatzl (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13638#pullrequestreview-1399694061

From ayang at openjdk.org  Tue Apr 25 13:39:18 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Apr 2023 13:39:18 GMT
Subject: RFR: 8306740: G1: Change G1CardSetHashTableScan to lambda
In-Reply-To: <QlEgYerB89biMK57ZN9oP70S27fjktOBEmGIigIS1R0=.ab5f8319-62df-482b-8ade-60cd17bbb7dc@github.com>
References: <QlEgYerB89biMK57ZN9oP70S27fjktOBEmGIigIS1R0=.ab5f8319-62df-482b-8ade-60cd17bbb7dc@github.com>
Message-ID: <1b7_21xaApHMqbrIszY71HWf0Tl7iKVBVfvJAWUTQcc=.fa2180a1-1964-463c-aad6-7d96f930630c@github.com>

On Mon, 24 Apr 2023 11:43:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring a closure class to lambda.
> 
> Test: hotspot_gc

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13612#issuecomment-1521800570

From ayang at openjdk.org  Tue Apr 25 13:39:19 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Apr 2023 13:39:19 GMT
Subject: Integrated: 8306740: G1: Change G1CardSetHashTableScan to lambda
In-Reply-To: <QlEgYerB89biMK57ZN9oP70S27fjktOBEmGIigIS1R0=.ab5f8319-62df-482b-8ade-60cd17bbb7dc@github.com>
References: <QlEgYerB89biMK57ZN9oP70S27fjktOBEmGIigIS1R0=.ab5f8319-62df-482b-8ade-60cd17bbb7dc@github.com>
Message-ID: <EH4mXASCEdnCyHR2j4F85z-RZHNyRipiX9epwcdjZ_g=.21294b2f-8dfb-47af-baf6-09a65ff25506@github.com>

On Mon, 24 Apr 2023 11:43:16 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring a closure class to lambda.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 9d1fe656
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9d1fe6565c6c355399578aa7aa211885342deb02
Stats:     26 lines in 1 file changed: 6 ins; 12 del; 8 mod

8306740: G1: Change G1CardSetHashTableScan to lambda

Reviewed-by: kbarrett, tschatzl

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

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

From ayang at openjdk.org  Tue Apr 25 13:45:14 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Apr 2023 13:45:14 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v2]
In-Reply-To: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
Message-ID: <_vvPOrKKjiHlt6cRNtxx80x4b7qEaNoWSQTX8SUiEfw=.90827c47-bb49-4c62-8f9b-ba810960d5e0@github.com>

> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
> 
> Test: hotspot_gc

Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - protected-destructor
 - card-table-array-field

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

Changes: https://git.openjdk.org/jdk/pull/13636/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13636&range=01
  Stats: 24 lines in 6 files changed: 7 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13636.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13636/head:pull/13636

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

From tschatzl at openjdk.org  Tue Apr 25 13:57:20 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 13:57:20 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions
Message-ID: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>

Hi all,

  please review this change that removes the pinned tag from `HeapRegion`.

So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions.

With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed".

The (current) pinned flag is surprisingly little used, only for policy decisions.

The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently anyway).

Testing: tier1-3, gha

Thanks,
  Thomas

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

Commit messages:
 - Fix hsdb
 - compilation fixes
 - Initial implementation

Changes: https://git.openjdk.org/jdk/pull/13643/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13643&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306836
  Stats: 66 lines in 20 files changed: 16 ins; 22 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/13643.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13643/head:pull/13643

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

From ayang at openjdk.org  Tue Apr 25 14:16:14 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Apr 2023 14:16:14 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v3]
In-Reply-To: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
Message-ID: <q6wTfQWiJBLuFNE31O3MpLGbsDba58IZ7qa8IPxqedg=.1758cb3b-ce00-4217-92b0-6a4386ead411@github.com>

> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
> 
> Test: hotspot_gc

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13636/files
  - new: https://git.openjdk.org/jdk/pull/13636/files/4c7815cd..760fbe3b

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

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

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

From kbarrett at openjdk.org  Tue Apr 25 14:40:17 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 25 Apr 2023 14:40:17 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v2]
In-Reply-To: <_vvPOrKKjiHlt6cRNtxx80x4b7qEaNoWSQTX8SUiEfw=.90827c47-bb49-4c62-8f9b-ba810960d5e0@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
 <_vvPOrKKjiHlt6cRNtxx80x4b7qEaNoWSQTX8SUiEfw=.90827c47-bb49-4c62-8f9b-ba810960d5e0@github.com>
Message-ID: <Pj374LHNtWQa0zS33JQ3rWWhZGZ_uE1I4waqThTKS7k=.a0e7ebac-341c-4415-a7d3-1bf18faaf908@github.com>

On Tue, 25 Apr 2023 13:45:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - protected-destructor
>  - card-table-array-field

src/hotspot/share/gc/g1/g1BarrierSet.hpp line 52:

> 50:   void invalidate(JavaThread* thread, MemRegion mr);
> 51: 
> 52:   ~G1BarrierSet() = default;

Why is this being privatized?

src/hotspot/share/gc/shared/cardTable.hpp line 60:

> 58: 
> 59:   // The covered regions should be in address order.
> 60:   MemRegion _covered[max_covered_regions];

The whole concept of covered_regions doesn't seem to belong in this class.  G1CardTable derives from
CardTable, but doesn't appear to use this at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13636#discussion_r1176566977
PR Review Comment: https://git.openjdk.org/jdk/pull/13636#discussion_r1176603754

From ayang at openjdk.org  Tue Apr 25 15:00:16 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Apr 2023 15:00:16 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v2]
In-Reply-To: <Pj374LHNtWQa0zS33JQ3rWWhZGZ_uE1I4waqThTKS7k=.a0e7ebac-341c-4415-a7d3-1bf18faaf908@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
 <_vvPOrKKjiHlt6cRNtxx80x4b7qEaNoWSQTX8SUiEfw=.90827c47-bb49-4c62-8f9b-ba810960d5e0@github.com>
 <Pj374LHNtWQa0zS33JQ3rWWhZGZ_uE1I4waqThTKS7k=.a0e7ebac-341c-4415-a7d3-1bf18faaf908@github.com>
Message-ID: <pnfe0R7QLOfZUmKmrkillvz-2cJIqFzmbXTw5QPrblQ=.e691df4e-89d2-4772-b8c2-015c52880605@github.com>

On Tue, 25 Apr 2023 14:02:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - protected-destructor
>>  - card-table-array-field
>
> src/hotspot/share/gc/g1/g1BarrierSet.hpp line 52:
> 
>> 50:   void invalidate(JavaThread* thread, MemRegion mr);
>> 51: 
>> 52:   ~G1BarrierSet() = default;
> 
> Why is this being privatized?

To minimize the public API; it doesn't need to be public.

> src/hotspot/share/gc/shared/cardTable.hpp line 60:
> 
>> 58: 
>> 59:   // The covered regions should be in address order.
>> 60:   MemRegion _covered[max_covered_regions];
> 
> The whole concept of covered_regions doesn't seem to belong in this class.  G1CardTable derives from
> CardTable, but doesn't appear to use this at all.

`_covered` is not really used by G1, so are some other fields, e.g. `_guard_region`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13636#discussion_r1176643608
PR Review Comment: https://git.openjdk.org/jdk/pull/13636#discussion_r1176647288

From ayang at openjdk.org  Tue Apr 25 15:10:15 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Tue, 25 Apr 2023 15:10:15 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions
In-Reply-To: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
Message-ID: <7a8WQxuLeLXBx9EGCq2ntzVZvEgdGrDl6UJKtS3I4a0=.69144425-8a3d-4e66-95a7-f6dbb36e875a@github.com>

On Tue, 25 Apr 2023 13:49:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that removes the pinned tag from `HeapRegion`.
> 
> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions.
> 
> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed".
> 
> The (current) pinned flag is surprisingly little used, only for policy decisions.
> 
> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway).
> 
> Testing: tier1-3, gha
> 
> Thanks,
>   Thomas

The name, `is_young_gc_movable`, seems to suggest it is context sensitive. Maybe it's clearer if it's not defined as an API of heap-region, like other region-type-predicates.

For example, it's odd to see them on the same abstraction level, when the two APIs refer to sth quite different.


  assert(hr->is_young_gc_movable(), "Should only be movable region in compaction queue");
  assert(!hr->is_humongous(), "Should be no humongous regions in compaction queue");


Additionally, it's confusing to see sth named "*young_gc*" in full-gc code (`g1FullGCPrepareTask.inline.hpp`).

For this particular PR, could one just use `!hr->is_humongous()` where `is_young_gc_movable` is used? (Essentially, inlining the new API.)

src/hotspot/share/gc/g1/g1HeapVerifier.cpp line 414:

> 412:       // There are no other valid region types. Check for one invalid
> 413:       // one we can identify before crashing: non-movable.
> 414:       assert(hr->is_young_gc_movable(), "Heap region %u is non-movable.", hr->hrm_index());

Given this branch is unreachable, can one just use `fatal(...)` without a predicate?

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

PR Review: https://git.openjdk.org/jdk/pull/13643#pullrequestreview-1400139894
PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1176660073

From tschatzl at openjdk.org  Tue Apr 25 15:33:07 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 15:33:07 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions
In-Reply-To: <7a8WQxuLeLXBx9EGCq2ntzVZvEgdGrDl6UJKtS3I4a0=.69144425-8a3d-4e66-95a7-f6dbb36e875a@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
 <7a8WQxuLeLXBx9EGCq2ntzVZvEgdGrDl6UJKtS3I4a0=.69144425-8a3d-4e66-95a7-f6dbb36e875a@github.com>
Message-ID: <nzMiIxNjOMRFn842NYAIkh5Uzr8IiyNWoOeMBBYK4DI=.93f02759-c161-4974-a20b-d1c15adc8efd@github.com>

On Tue, 25 Apr 2023 15:05:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that removes the pinned tag from `HeapRegion`.
>> 
>> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions.
>> 
>> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed".
>> 
>> The (current) pinned flag is surprisingly little used, only for policy decisions.
>> 
>> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway).
>> 
>> Testing: tier1-3, gha
>> 
>> Thanks,
>>   Thomas
>
> src/hotspot/share/gc/g1/g1HeapVerifier.cpp line 414:
> 
>> 412:       // There are no other valid region types. Check for one invalid
>> 413:       // one we can identify before crashing: non-movable.
>> 414:       assert(hr->is_young_gc_movable(), "Heap region %u is non-movable.", hr->hrm_index());
> 
> Given this branch is unreachable, can one just use `fatal(...)` without a predicate?

>The name, is_young_gc_movable, seems to suggest it is context sensitive. Maybe it's clearer if it's not defined as an API of heap-region, like other region-type-predicates.

It is defined in `G1Policy`, there is simply a shortcut via `HeapRegion`. I considered removing that shortcut in `HeapRegion`, but then this would mean lots of clutter everywhere to get to the policy object.

I will find a better location for a helper.

>
>For example, it's odd to see them on the same abstraction level, when the two APIs refer to sth quite different.
>
>  assert(hr->is_young_gc_movable(), "Should only be movable region in compaction queue");
>  assert(!hr->is_humongous(), "Should be no humongous regions in compaction queue");
>
>Additionally, it's confusing to see sth named "young_gc" in full-gc code (g1FullGCPrepareTask.inline.hpp).

I was too lazy to wrap it in a "movable-during-first-full-gc-attempt" method, will fix. I thought the comment would be enough.

>
>For this particular PR, could one just use !hr->is_humongous() where is_young_gc_movable is used? (Essentially, inlining >the new API.)

I do not like inlining this API because this looses the documentation of this condition. One would probably need to add a "(At the moment) Humongous regions are non-movable." comment everywhere to understand why that condition is there.

Thanks,
  Thomas

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1176691594

From tschatzl at openjdk.org  Tue Apr 25 15:33:08 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 15:33:08 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions
In-Reply-To: <nzMiIxNjOMRFn842NYAIkh5Uzr8IiyNWoOeMBBYK4DI=.93f02759-c161-4974-a20b-d1c15adc8efd@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
 <7a8WQxuLeLXBx9EGCq2ntzVZvEgdGrDl6UJKtS3I4a0=.69144425-8a3d-4e66-95a7-f6dbb36e875a@github.com>
 <nzMiIxNjOMRFn842NYAIkh5Uzr8IiyNWoOeMBBYK4DI=.93f02759-c161-4974-a20b-d1c15adc8efd@github.com>
Message-ID: <IsBBX_cSznNjq_0Ok1fqMpOBPCmj0UDqkS25LkZngUM=.a2d30aa0-2390-4903-ae22-5481cff242e8@github.com>

On Tue, 25 Apr 2023 15:29:08 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1HeapVerifier.cpp line 414:
>> 
>>> 412:       // There are no other valid region types. Check for one invalid
>>> 413:       // one we can identify before crashing: non-movable.
>>> 414:       assert(hr->is_young_gc_movable(), "Heap region %u is non-movable.", hr->hrm_index());
>> 
>> Given this branch is unreachable, can one just use `fatal(...)` without a predicate?
>
>>The name, is_young_gc_movable, seems to suggest it is context sensitive. Maybe it's clearer if it's not defined as an API of heap-region, like other region-type-predicates.
> 
> It is defined in `G1Policy`, there is simply a shortcut via `HeapRegion`. I considered removing that shortcut in `HeapRegion`, but then this would mean lots of clutter everywhere to get to the policy object.
> 
> I will find a better location for a helper.
> 
>>
>>For example, it's odd to see them on the same abstraction level, when the two APIs refer to sth quite different.
>>
>>  assert(hr->is_young_gc_movable(), "Should only be movable region in compaction queue");
>>  assert(!hr->is_humongous(), "Should be no humongous regions in compaction queue");
>>
>>Additionally, it's confusing to see sth named "young_gc" in full-gc code (g1FullGCPrepareTask.inline.hpp).
> 
> I was too lazy to wrap it in a "movable-during-first-full-gc-attempt" method, will fix. I thought the comment would be enough.
> 
>>
>>For this particular PR, could one just use !hr->is_humongous() where is_young_gc_movable is used? (Essentially, inlining >the new API.)
> 
> I do not like inlining this API because this looses the documentation of this condition. One would probably need to add a "(At the moment) Humongous regions are non-movable." comment everywhere to understand why that condition is there.
> 
> Thanks,
>   Thomas

> Given this branch is unreachable, can one just use `fatal(...)` without a predicate?

I also thought about this: the purpose of the additional assert is/was (I think) to fail with a better message than just crashing with some nondescript message, filtering out other possible cases. 
Will remove this after all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1176693623

From tschatzl at openjdk.org  Tue Apr 25 15:59:05 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 15:59:05 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v2]
In-Reply-To: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
Message-ID: <khfhozcQPnUcBKmnZJyeD9_bBzzjJEkIWBTklv0h3Y4=.cc31f10b-cf30-4ccc-b85a-1154870ae529@github.com>

> Hi all,
> 
>   please review this change that removes the pinned tag from `HeapRegion`.
> 
> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions.
> 
> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed".
> 
> The (current) pinned flag is surprisingly little used, only for policy decisions.
> 
> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway).
> 
> Testing: tier1-3, gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  ayang review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13643/files
  - new: https://git.openjdk.org/jdk/pull/13643/files/c0345927..4b736512

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

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

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

From tschatzl at openjdk.org  Tue Apr 25 16:33:13 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 25 Apr 2023 16:33:13 GMT
Subject: RFR: 8306858: Remove some renmants of CMS from SA agent
Message-ID: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>

Hi all,

  please review this change that removes some remaining CMS related stuff.

Testing: tier1-3, gha

Thanks,
  Thomas

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

Commit messages:
 - Remove CMS stuff

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

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

From shade at openjdk.org  Tue Apr 25 16:46:07 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 25 Apr 2023 16:46:07 GMT
Subject: RFR: 8306858: Remove some renmants of CMS from SA agent
In-Reply-To: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
References: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
Message-ID: <CRkubWyarHjWTXaHQOVuojCiVHr3_TeguekYROkKlYk=.3a477759-edce-456c-88ee-755accfa7240@github.com>

On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that removes some remaining CMS related stuff.
> 
> Testing: tier1-3, gha
> 
> Thanks,
>   Thomas

Looks fine to me.

But the synopsis has a typo, "remnants".

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1400332261

From cjplummer at openjdk.org  Tue Apr 25 18:25:09 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Apr 2023 18:25:09 GMT
Subject: RFR: 8306858: Remove some remnants of CMS from SA agent
In-Reply-To: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
References: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
Message-ID: <IWi555jWap_GRy1cr0jDxH9KgMniwxXr--pxoPyvE6c=.cd2810c8-e587-40c1-abc8-a3c42399236f@github.com>

On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that removes some remaining CMS related stuff.
> 
> Testing: tier1-3, gha
> 
> Thanks,
>   Thomas

Marked as reviewed by cjplummer (Reviewer).

Copyrights need updating

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

PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1400476463
Changes requested by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1400478623

From cjplummer at openjdk.org  Tue Apr 25 18:35:12 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 25 Apr 2023 18:35:12 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v2]
In-Reply-To: <khfhozcQPnUcBKmnZJyeD9_bBzzjJEkIWBTklv0h3Y4=.cc31f10b-cf30-4ccc-b85a-1154870ae529@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
 <khfhozcQPnUcBKmnZJyeD9_bBzzjJEkIWBTklv0h3Y4=.cc31f10b-cf30-4ccc-b85a-1154870ae529@github.com>
Message-ID: <ewWlYbu-Rr9y3lSz43oVIuO4-9WnOgATox4sg3LSlN0=.cbef98e6-1d2b-4ba6-9d01-98b455a35f67@github.com>

On Tue, 25 Apr 2023 15:59:05 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that removes the pinned tag from `HeapRegion`.
>> 
>> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions.
>> 
>> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed".
>> 
>> The (current) pinned flag is surprisingly little used, only for policy decisions.
>> 
>> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway).
>> 
>> Testing: tier1-3, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang review

A few files need copyright updates

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 1109:

> 1107:                           } else if (region.isPinned()) {
> 1108:                             anno = "Pinned ";
> 1109:                             bad = false;

Does this mean that the region will now always be one of Free, Young, Humongous, or Old?

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

PR Review: https://git.openjdk.org/jdk/pull/13643#pullrequestreview-1400494547
PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1176886830

From kbarrett at openjdk.org  Wed Apr 26 02:26:52 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 26 Apr 2023 02:26:52 GMT
Subject: RFR: 8306858: Remove some remnants of CMS from SA agent
In-Reply-To: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
References: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
Message-ID: <PNobz4MW26LdeL9OuWKPQGqsaKWefbeu7ts7MocpTYk=.6cef7a57-5e5c-43de-ada5-9b4bb6613080@github.com>

On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that removes some remaining CMS related stuff.
> 
> Testing: tier1-3, gha
> 
> Thanks,
>   Thomas

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1401041280

From kbarrett at openjdk.org  Wed Apr 26 03:22:00 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 26 Apr 2023 03:22:00 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v2]
In-Reply-To: <pnfe0R7QLOfZUmKmrkillvz-2cJIqFzmbXTw5QPrblQ=.e691df4e-89d2-4772-b8c2-015c52880605@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
 <_vvPOrKKjiHlt6cRNtxx80x4b7qEaNoWSQTX8SUiEfw=.90827c47-bb49-4c62-8f9b-ba810960d5e0@github.com>
 <Pj374LHNtWQa0zS33JQ3rWWhZGZ_uE1I4waqThTKS7k=.a0e7ebac-341c-4415-a7d3-1bf18faaf908@github.com>
 <pnfe0R7QLOfZUmKmrkillvz-2cJIqFzmbXTw5QPrblQ=.e691df4e-89d2-4772-b8c2-015c52880605@github.com>
Message-ID: <JLfXR0qvQpHAjlVNOXPJ8YNabO0z2WP00vZfiCsZzW4=.ea947d46-2134-4e92-8046-cbd1100b637b@github.com>

On Tue, 25 Apr 2023 14:56:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/cardTable.hpp line 60:
>> 
>>> 58: 
>>> 59:   // The covered regions should be in address order.
>>> 60:   MemRegion _covered[max_covered_regions];
>> 
>> The whole concept of covered_regions doesn't seem to belong in this class.  G1CardTable derives from
>> CardTable, but doesn't appear to use this at all.
>
> `_covered` is not really used by G1, so are some other fields, e.g. `_guard_region`.

Yeah, it looks like there are a bunch of hierarchy / abstraction bugs in this area.  OK, I'll agree this is a
step-wise improvement, with hopefully more to come.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13636#discussion_r1177289723

From kbarrett at openjdk.org  Wed Apr 26 03:46:23 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 26 Apr 2023 03:46:23 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v3]
In-Reply-To: <q6wTfQWiJBLuFNE31O3MpLGbsDba58IZ7qa8IPxqedg=.1758cb3b-ce00-4217-92b0-6a4386ead411@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
 <q6wTfQWiJBLuFNE31O3MpLGbsDba58IZ7qa8IPxqedg=.1758cb3b-ce00-4217-92b0-6a4386ead411@github.com>
Message-ID: <lk49glKEklzN2jngxYhtZtAatJ7dR1AguPIvyJDVNQU=.9f68ad3a-b849-4c60-a199-681a017253db@github.com>

On Tue, 25 Apr 2023 14:16:14 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Changes requested by kbarrett (Reviewer).

src/hotspot/share/gc/shared/cardTableBarrierSet.hpp line 65:

> 63:   ~CardTableBarrierSet();
> 64: 
> 65: public:

The destructor should remain public - this class is directly instantiated.
It should also be virtual, since this class is also used as a base class.  This is a small but typical example
of why classes shouldn't do such double duty.

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

PR Review: https://git.openjdk.org/jdk/pull/13636#pullrequestreview-1401100561
PR Review Comment: https://git.openjdk.org/jdk/pull/13636#discussion_r1177299711

From kbarrett at openjdk.org  Wed Apr 26 03:47:23 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 26 Apr 2023 03:47:23 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v2]
In-Reply-To: <pnfe0R7QLOfZUmKmrkillvz-2cJIqFzmbXTw5QPrblQ=.e691df4e-89d2-4772-b8c2-015c52880605@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
 <_vvPOrKKjiHlt6cRNtxx80x4b7qEaNoWSQTX8SUiEfw=.90827c47-bb49-4c62-8f9b-ba810960d5e0@github.com>
 <Pj374LHNtWQa0zS33JQ3rWWhZGZ_uE1I4waqThTKS7k=.a0e7ebac-341c-4415-a7d3-1bf18faaf908@github.com>
 <pnfe0R7QLOfZUmKmrkillvz-2cJIqFzmbXTw5QPrblQ=.e691df4e-89d2-4772-b8c2-015c52880605@github.com>
Message-ID: <3Hr60Zjb74LOp9HPlaEzxGRQzP5SVCJpggVARLMiQdU=.7665ca0d-f104-43e3-89fa-40fae8cadbbb@github.com>

On Tue, 25 Apr 2023 14:54:43 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1BarrierSet.hpp line 52:
>> 
>>> 50:   void invalidate(JavaThread* thread, MemRegion mr);
>>> 51: 
>>> 52:   ~G1BarrierSet() = default;
>> 
>> Why is this being privatized?
>
> To minimize the public API; it doesn't need to be public.

It should be public - this is a directly instantiated class.  Yes, I know we don't currently call it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13636#discussion_r1177298729

From tschatzl at openjdk.org  Wed Apr 26 08:41:30 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 26 Apr 2023 08:41:30 GMT
Subject: RFR: 8306858: Remove some remnants of CMS from SA agent [v2]
In-Reply-To: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
References: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
Message-ID: <fKfNyzm_4Ah7FDT-M9MvJyJ0WWy6Q2fUTY8gvW4Dd6k=.9f3162b5-a6bf-485d-9310-d3350ec830d8@github.com>

> Hi all,
> 
>   please review this change that removes some remaining CMS related stuff.
> 
> Testing: tier1-3, gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  cplummer review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13646/files
  - new: https://git.openjdk.org/jdk/pull/13646/files/42d4cafa..79f9a814

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

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

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

From tschatzl at openjdk.org  Wed Apr 26 09:12:24 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 26 Apr 2023 09:12:24 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3]
In-Reply-To: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
Message-ID: <kYvyLOGR1YHM3nr3lr5yGK8xS5SFT_YNFIHBNSeRhvE=.6668da15-9481-4ec9-be8a-8b91e19eaa90@github.com>

> Hi all,
> 
>   please review this change that removes the pinned tag from `HeapRegion`.
> 
> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions.
> 
> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed".
> 
> The (current) pinned flag is surprisingly little used, only for policy decisions.
> 
> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway).
> 
> Testing: tier1-3, gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  cplummer review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13643/files
  - new: https://git.openjdk.org/jdk/pull/13643/files/4b736512..eacf54ba

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

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

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

From tschatzl at openjdk.org  Wed Apr 26 09:13:25 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 26 Apr 2023 09:13:25 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3]
In-Reply-To: <ewWlYbu-Rr9y3lSz43oVIuO4-9WnOgATox4sg3LSlN0=.cbef98e6-1d2b-4ba6-9d01-98b455a35f67@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
 <khfhozcQPnUcBKmnZJyeD9_bBzzjJEkIWBTklv0h3Y4=.cc31f10b-cf30-4ccc-b85a-1154870ae529@github.com>
 <ewWlYbu-Rr9y3lSz43oVIuO4-9WnOgATox4sg3LSlN0=.cbef98e6-1d2b-4ba6-9d01-98b455a35f67@github.com>
Message-ID: <5fltNms8YN-m7KHDT11zD1NQ_2BxcIy-vcR_HlSO5nE=.25134e10-40f5-4a65-9eb4-7a578b90c630@github.com>

On Tue, 25 Apr 2023 18:31:19 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cplummer review
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/HSDB.java line 1109:
> 
>> 1107:                           } else if (region.isPinned()) {
>> 1108:                             anno = "Pinned ";
>> 1109:                             bad = false;
> 
> Does this mean that the region will now always be one of Free, Young, Humongous, or Old?

As the description says, the "pinned" attribute is going away temporarily as it is not really required/used at this time. So only the base region types you specified will remain.

The attribute will be re-introduced in a bit during completion of [JDK-8276094](https://bugs.openjdk.org/browse/JDK-8276094) with a slightly different meaning.

Btw, the code has been wrong in that the "pinned" attribute is a modifier of the base types (Free, Young, ...), not a separate category.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13643#discussion_r1177560794

From tschatzl at openjdk.org  Wed Apr 26 09:51:28 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 26 Apr 2023 09:51:28 GMT
Subject: RFR: 8306541: Refactor collection set candidate handling to prepare
 for JDK-8140326
Message-ID: <4oheKwC7DqtsyjvQCNR2XDazOT7xkoGrLBrwbVp-wS8=.433fb484-259f-49eb-9bd7-ca31220cf808@github.com>

Hi all,

  please review this refactoring of collection set candidate set handling.

The idea is to improve the interface to collection set candidates and prepare for having collection set candidates available at any time to evacuate them at any young collection.

These preparations to allow for multiple sources for these candidates (from the marking, as now, and from retained regions, i.e. evacuation failed regions as per [JDK-8140326](https://bugs.openjdk.org/browse/JDK-8140326)).

This patch only uses candidates from marking at this time.
 
Also moves gc efficiency out of HeapRegion and associate it to the list element as it's not used otherwise.
    
In detail:
    * the collection set candidates set is not temporarily allocated any more, but the candidate collection set object is available all the time.
    
    * G1CollectionSetCandidates is the main class, representing the current candidates. Contains the "from marking" candidate list only (at this point).
    
    * there are several additional helper sets/lists
      * G1CollectionSetRegionList: list of HeapRegion*, typically sorted by efficiency (but not necessarily). Also does not contain gc efficiences.
      * G1CollectionCandidateList: list of candidates, i.e. HeapRegion* with their gc efficiency. Building block for the actual collection set candidates list.
    
All these sets implement C++ iterators for simpler use in various places.
    
Testing:
 - this patch only: tier1-3, gha
 - with JDK-8140326 tier1-7 (or 8?)

Thanks,
  Thomas

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

Commit messages:
 - Whitespace fixes
 - typo
 - More cleanup
 - Cleanup
 - Cleanup
 - Refactor collection set candidates

Changes: https://git.openjdk.org/jdk/pull/13666/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13666&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306541
  Stats: 1137 lines in 26 files changed: 659 ins; 231 del; 247 mod
  Patch: https://git.openjdk.org/jdk/pull/13666.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13666/head:pull/13666

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

From tschatzl at openjdk.org  Wed Apr 26 09:51:28 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 26 Apr 2023 09:51:28 GMT
Subject: RFR: 8306541: Refactor collection set candidate handling to
 prepare for JDK-8140326
In-Reply-To: <4oheKwC7DqtsyjvQCNR2XDazOT7xkoGrLBrwbVp-wS8=.433fb484-259f-49eb-9bd7-ca31220cf808@github.com>
References: <4oheKwC7DqtsyjvQCNR2XDazOT7xkoGrLBrwbVp-wS8=.433fb484-259f-49eb-9bd7-ca31220cf808@github.com>
Message-ID: <OiIVSU2AwcA9Jfa7YXFsQgHK0h5V11FIqy0p0C8txo4=.0f709e0b-6428-4445-accb-f32eec3d6b0a@github.com>

On Wed, 26 Apr 2023 09:20:46 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this refactoring of collection set candidate set handling.
> 
> The idea is to improve the interface to collection set candidates and prepare for having collection set candidates available at any time to evacuate them at any young collection.
> 
> These preparations to allow for multiple sources for these candidates (from the marking, as now, and from retained regions, i.e. evacuation failed regions as per [JDK-8140326](https://bugs.openjdk.org/browse/JDK-8140326)).
> 
> This patch only uses candidates from marking at this time.
>  
> Also moves gc efficiency out of HeapRegion and associate it to the list element as it's not used otherwise.
>     
> In detail:
>     * the collection set candidates set is not temporarily allocated any more, but the candidate collection set object is available all the time.
>     
>     * G1CollectionSetCandidates is the main class, representing the current candidates. Contains the "from marking" candidate list only (at this point).
>     
>     * there are several additional helper sets/lists
>       * G1CollectionSetRegionList: list of HeapRegion*, typically sorted by efficiency (but not necessarily). Also does not contain gc efficiences.
>       * G1CollectionCandidateList: list of candidates, i.e. HeapRegion* with their gc efficiency. Building block for the actual collection set candidates list.
>     
> All these sets implement C++ iterators for simpler use in various places.
>     
> Testing:
>  - this patch only: tier1-3, gha
>  - with JDK-8140326 tier1-7 (or 8?)
> 
> Thanks,
>   Thomas

The first two commits in the branch https://github.com/openjdk/jdk/compare/master...tschatzl:jdk:remove-pinned-mask show this change (first two patches) in context of what is to come for [JDK-8140326](https://bugs.openjdk.org/browse/JDK-8140326)), which is the fourth patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/13666#issuecomment-1523085024

From ayang at openjdk.org  Wed Apr 26 09:51:32 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 26 Apr 2023 09:51:32 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v4]
In-Reply-To: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
Message-ID: <DjO3WkJ0gm262QkCn5FxEjmCMaogg1erbF5969tfwjM=.70982f26-6d20-4694-9592-e88cd9b380ff@github.com>

> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
> 
> Test: hotspot_gc

Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:

  review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13636/files
  - new: https://git.openjdk.org/jdk/pull/13636/files/760fbe3b..63ce68bf

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

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

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

From iwalulya at openjdk.org  Wed Apr 26 10:27:54 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 26 Apr 2023 10:27:54 GMT
Subject: RFR: 8306735: G1: G1FullGCScope remove unnecessary member
 _explicit_gc
In-Reply-To: <uJBqSNy76CE6ahqOiHT8XfBs71m2T1jJUyhxLdqIcIg=.145eaf84-c361-4dfb-9838-e48ac0c22e1d@github.com>
References: <uJBqSNy76CE6ahqOiHT8XfBs71m2T1jJUyhxLdqIcIg=.145eaf84-c361-4dfb-9838-e48ac0c22e1d@github.com>
Message-ID: <ib4KagHdS65tu2F8tXI1kYZO7zT4gJt_YE5_IyRrkQ0=.cd9f9063-4834-491b-8301-17371b47e475@github.com>

On Tue, 25 Apr 2023 11:05:21 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi All,
> 
> Please review this change to remove the unnecessary `explicit_gc` member from G1FullGCScope. We can rely on gc_cause() to determine whether the explicit_gc is true where required. 
> 
> Testing: tier1_gc

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/13638#issuecomment-1523154893

From iwalulya at openjdk.org  Wed Apr 26 10:27:55 2023
From: iwalulya at openjdk.org (Ivan Walulya)
Date: Wed, 26 Apr 2023 10:27:55 GMT
Subject: Integrated: 8306735: G1: G1FullGCScope remove unnecessary member
 _explicit_gc
In-Reply-To: <uJBqSNy76CE6ahqOiHT8XfBs71m2T1jJUyhxLdqIcIg=.145eaf84-c361-4dfb-9838-e48ac0c22e1d@github.com>
References: <uJBqSNy76CE6ahqOiHT8XfBs71m2T1jJUyhxLdqIcIg=.145eaf84-c361-4dfb-9838-e48ac0c22e1d@github.com>
Message-ID: <--cvJLc1QpTKgK2kAsNYOXtqwEbu4C-hCHPXV3Atgkw=.389f9a86-bff3-420d-8b32-9452b40ce180@github.com>

On Tue, 25 Apr 2023 11:05:21 GMT, Ivan Walulya <iwalulya at openjdk.org> wrote:

> Hi All,
> 
> Please review this change to remove the unnecessary `explicit_gc` member from G1FullGCScope. We can rely on gc_cause() to determine whether the explicit_gc is true where required. 
> 
> Testing: tier1_gc

This pull request has now been integrated.

Changeset: 86f41a4c
Author:    Ivan Walulya <iwalulya at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86f41a4c42268d364175263804eb4d1ce82fa943
Stats:     31 lines in 7 files changed: 0 ins; 20 del; 11 mod

8306735: G1: G1FullGCScope remove unnecessary member _explicit_gc

Reviewed-by: ayang, tschatzl

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

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

From ayang at openjdk.org  Wed Apr 26 11:13:23 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 26 Apr 2023 11:13:23 GMT
Subject: RFR: 8306749: Make CardTable::invalidate non-virtual
In-Reply-To: <0MS_quDT5evJWvVp2YSg1o0Xt7qZ7-F6WNUc34zqsT0=.784db7be-75ba-4280-b461-264739c402ad@github.com>
References: <0MS_quDT5evJWvVp2YSg1o0Xt7qZ7-F6WNUc34zqsT0=.784db7be-75ba-4280-b461-264739c402ad@github.com>
Message-ID: <H5_waNQ_iXSpSPVq4l4OtVSuN__bn2SiYKLkRtFuciM=.6c3952fc-a190-4104-a327-bdd78fbc3364@github.com>

On Mon, 24 Apr 2023 13:08:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unused `virtual` specifier.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13617#issuecomment-1523222703

From ayang at openjdk.org  Wed Apr 26 11:13:24 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Wed, 26 Apr 2023 11:13:24 GMT
Subject: Integrated: 8306749: Make CardTable::invalidate non-virtual
In-Reply-To: <0MS_quDT5evJWvVp2YSg1o0Xt7qZ7-F6WNUc34zqsT0=.784db7be-75ba-4280-b461-264739c402ad@github.com>
References: <0MS_quDT5evJWvVp2YSg1o0Xt7qZ7-F6WNUc34zqsT0=.784db7be-75ba-4280-b461-264739c402ad@github.com>
Message-ID: <Wm3dEH6Bk_U9BLQlmjhEsaw_baxDx8GfkhakRLc_s9w=.63a9be0a-cb9c-4257-b51e-6b8ef893f17e@github.com>

On Mon, 24 Apr 2023 13:08:10 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Trivial removing unused `virtual` specifier.

This pull request has now been integrated.

Changeset: c5910fa0
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5910fa065ec9b95fcc63047a76f9f4c5cf64dd6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8306749: Make CardTable::invalidate non-virtual

Reviewed-by: tschatzl

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

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

From kbarrett at openjdk.org  Wed Apr 26 13:24:26 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 26 Apr 2023 13:24:26 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v4]
In-Reply-To: <DjO3WkJ0gm262QkCn5FxEjmCMaogg1erbF5969tfwjM=.70982f26-6d20-4694-9592-e88cd9b380ff@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
 <DjO3WkJ0gm262QkCn5FxEjmCMaogg1erbF5969tfwjM=.70982f26-6d20-4694-9592-e88cd9b380ff@github.com>
Message-ID: <JQEUdcT5Y6zAxbAM7U0PasrDYLhJJPA3h5lhCMPJ3co=.5ee2dfb8-7931-4900-af85-a087188837c2@github.com>

On Wed, 26 Apr 2023 09:51:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13636#pullrequestreview-1401969582

From tschatzl at openjdk.org  Wed Apr 26 15:10:53 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 26 Apr 2023 15:10:53 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v4]
In-Reply-To: <DjO3WkJ0gm262QkCn5FxEjmCMaogg1erbF5969tfwjM=.70982f26-6d20-4694-9592-e88cd9b380ff@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
 <DjO3WkJ0gm262QkCn5FxEjmCMaogg1erbF5969tfwjM=.70982f26-6d20-4694-9592-e88cd9b380ff@github.com>
Message-ID: <YGLAqIMaiZbw2bCI1pL7xMMLlpK3bKktRWMpNagW6fA=.2584db47-67e3-4b03-9ba9-90b7f70b035f@github.com>

On Wed, 26 Apr 2023 09:51:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Still good.

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

Marked as reviewed by tschatzl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13636#pullrequestreview-1402199464

From cjplummer at openjdk.org  Wed Apr 26 17:39:52 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Apr 2023 17:39:52 GMT
Subject: RFR: 8306858: Remove some remnants of CMS from SA agent [v2]
In-Reply-To: <fKfNyzm_4Ah7FDT-M9MvJyJ0WWy6Q2fUTY8gvW4Dd6k=.9f3162b5-a6bf-485d-9310-d3350ec830d8@github.com>
References: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
 <fKfNyzm_4Ah7FDT-M9MvJyJ0WWy6Q2fUTY8gvW4Dd6k=.9f3162b5-a6bf-485d-9310-d3350ec830d8@github.com>
Message-ID: <jsDkQ2KIGL87floUUL9pP25Z4excn_6zUDwWrB2f0sM=.b164925e-801d-468d-b222-99d9810d1503@github.com>

On Wed, 26 Apr 2023 08:41:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that removes some remaining CMS related stuff.
>> 
>> Testing: tier1-3, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cplummer review

Looks good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1402482123

From cjplummer at openjdk.org  Wed Apr 26 17:40:23 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Wed, 26 Apr 2023 17:40:23 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3]
In-Reply-To: <kYvyLOGR1YHM3nr3lr5yGK8xS5SFT_YNFIHBNSeRhvE=.6668da15-9481-4ec9-be8a-8b91e19eaa90@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
 <kYvyLOGR1YHM3nr3lr5yGK8xS5SFT_YNFIHBNSeRhvE=.6668da15-9481-4ec9-be8a-8b91e19eaa90@github.com>
Message-ID: <zFUXBLOopxU-xdZlCOjG_3sY9n6ExFF3i4S52-K2Vrc=.49478095-f417-4f33-b0fc-5d5b227b622c@github.com>

On Wed, 26 Apr 2023 09:12:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that removes the pinned tag from `HeapRegion`.
>> 
>> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions.
>> 
>> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed".
>> 
>> The (current) pinned flag is surprisingly little used, only for policy decisions.
>> 
>> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway).
>> 
>> Testing: tier1-3, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cplummer review

SA changes look good.

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

Marked as reviewed by cjplummer (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13643#pullrequestreview-1402487734

From ysr at openjdk.org  Wed Apr 26 18:28:23 2023
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 26 Apr 2023 18:28:23 GMT
Subject: RFR: 8306858: Remove some remnants of CMS from SA agent [v2]
In-Reply-To: <fKfNyzm_4Ah7FDT-M9MvJyJ0WWy6Q2fUTY8gvW4Dd6k=.9f3162b5-a6bf-485d-9310-d3350ec830d8@github.com>
References: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
 <fKfNyzm_4Ah7FDT-M9MvJyJ0WWy6Q2fUTY8gvW4Dd6k=.9f3162b5-a6bf-485d-9310-d3350ec830d8@github.com>
Message-ID: <LsX7DxpUjp-Ucgc7_-xAQBf8IluMWjm0Se8c13YYwKM=.743b9169-195d-4132-993a-ce892980b888@github.com>

On Wed, 26 Apr 2023 08:41:30 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that removes some remaining CMS related stuff.
>> 
>> Testing: tier1-3, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cplummer review

Marked as reviewed by ysr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13646#pullrequestreview-1402551121

From tschatzl at openjdk.org  Thu Apr 27 07:41:24 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 27 Apr 2023 07:41:24 GMT
Subject: RFR: 8306858: Remove some remnants of CMS from SA agent [v2]
In-Reply-To: <CRkubWyarHjWTXaHQOVuojCiVHr3_TeguekYROkKlYk=.3a477759-edce-456c-88ee-755accfa7240@github.com>
References: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
 <CRkubWyarHjWTXaHQOVuojCiVHr3_TeguekYROkKlYk=.3a477759-edce-456c-88ee-755accfa7240@github.com>
Message-ID: <KQ7J5mKky1yfjSSzWxBTw_FyxLM-i5AIuOsQghb4WO0=.683a6416-310a-4470-a165-c56461bd49c6@github.com>

On Tue, 25 Apr 2023 16:43:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   cplummer review
>
> Looks fine to me.
> 
> But the synopsis has a typo, "remnants".

Thanks @shipilev @kimbarrett @plummercj @ysr for you reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/13646#issuecomment-1524964919

From tschatzl at openjdk.org  Thu Apr 27 07:41:26 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 27 Apr 2023 07:41:26 GMT
Subject: Integrated: 8306858: Remove some remnants of CMS from SA agent
In-Reply-To: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
References: <erxba4kbHT8lOE7aDgYuHsFn1hOnJLMMZv-dQUCrQrw=.ca136eaa-6fdf-4cc8-9721-edfe5415fda1@github.com>
Message-ID: <IJTvOoFImwBHPlXguRKgE4UtDIe0aUy2mLwffjSAgAA=.f3fc4375-2500-4264-947e-4a324e382e1f@github.com>

On Tue, 25 Apr 2023 16:25:40 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   please review this change that removes some remaining CMS related stuff.
> 
> Testing: tier1-3, gha
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: d94ce656
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d94ce6566d50fc0a6218adbb64d8f90e9eeb844a
Stats:     16 lines in 4 files changed: 0 ins; 12 del; 4 mod

8306858: Remove some remnants of CMS from SA agent

Reviewed-by: shade, cjplummer, kbarrett, ysr

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

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

From ayang at openjdk.org  Thu Apr 27 10:56:24 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 27 Apr 2023 10:56:24 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3]
In-Reply-To: <kYvyLOGR1YHM3nr3lr5yGK8xS5SFT_YNFIHBNSeRhvE=.6668da15-9481-4ec9-be8a-8b91e19eaa90@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
 <kYvyLOGR1YHM3nr3lr5yGK8xS5SFT_YNFIHBNSeRhvE=.6668da15-9481-4ec9-be8a-8b91e19eaa90@github.com>
Message-ID: <p_8SJVKjw780wslzPpbN0JbGdz_9cj7LIC4UjhA4GGA=.d08d0b7f-2c1f-480e-a98f-b7b99a66ba6f@github.com>

On Wed, 26 Apr 2023 09:12:24 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this change that removes the pinned tag from `HeapRegion`.
>> 
>> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions.
>> 
>> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed".
>> 
>> The (current) pinned flag is surprisingly little used, only for policy decisions.
>> 
>> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway).
>> 
>> Testing: tier1-3, gha
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cplummer review

> I think you are right about using is_humongous() directly here: the reason we skip compacting of humongous regions during the "main" compaction is intentional here

However, I am unable to discern the difference -- why `is_young_gc_movable` is semantically-correct in one place, but not in the other in this concrete example.


bool G1CollectionSetChooser::should_add(HeapRegion* hr) {
  return !hr->is_young() &&
         G1CollectedHeap::heap()->policy()->is_young_gc_movable(hr) &&


vs


void G1FullCollector::before_marking_update_attribute_table(HeapRegion* hr) {
  if (hr->is_free()) {
    _region_attr_table.set_free(hr->hrm_index());
  } else if (hr->is_humongous()) {


Looking at where `G1CollectionSetChooser::should_add` is called, can one use `hr->is_old()` instead of `!hr->is_young() && G1CollectedHeap::heap()->policy()->is_young_gc_movable(hr)`? (In fact, I believe that inlining `should_add` to the caller would result in a smoother code flow and prevent some duplicate region-type queries.)

In my opinion, introducing a new `is_young_gc_movable` API in this particular PR may not be entirely justified. It may make more sense to introduce it in later PRs where region-pinning is supported and the API is actually utilized.

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

PR Comment: https://git.openjdk.org/jdk/pull/13643#issuecomment-1525434952

From ayang at openjdk.org  Thu Apr 27 11:54:25 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 27 Apr 2023 11:54:25 GMT
Subject: RFR: 8306833: Change CardTable::_covered to static array [v4]
In-Reply-To: <DjO3WkJ0gm262QkCn5FxEjmCMaogg1erbF5969tfwjM=.70982f26-6d20-4694-9592-e88cd9b380ff@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
 <DjO3WkJ0gm262QkCn5FxEjmCMaogg1erbF5969tfwjM=.70982f26-6d20-4694-9592-e88cd9b380ff@github.com>
Message-ID: <LZlBI16HMSXW42o_mvk1OWdraoB34DVbiz_3rjtvou4=.d63c2555-4d19-4e4c-ba8e-12c1940e0986@github.com>

On Wed, 26 Apr 2023 09:51:32 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
>> 
>> Test: hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/13636#issuecomment-1525541379

From ayang at openjdk.org  Thu Apr 27 11:54:26 2023
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Thu, 27 Apr 2023 11:54:26 GMT
Subject: Integrated: 8306833: Change CardTable::_covered to static array
In-Reply-To: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
References: <gMDYdoL6DY595LakloMENX6G4KgK_lvT-wUKK8TpU_w=.a4bca0b8-bfda-41e5-8def-fc267d531c09@github.com>
Message-ID: <WX_u6kFWv5AtAL0VCk1rhJ-AI7EBAmzXz8PkA9fc9A8=.13462d0a-59cc-4b64-b765-c2ff88a967be@github.com>

On Tue, 25 Apr 2023 10:30:49 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring to remove unused declaration in `vmStructs_gc.hpp`, which then enables more cleanup in `CardTable`.
> 
> Test: hotspot_gc

This pull request has now been integrated.

Changeset: 96cdf93b
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96cdf93b425612ec2e7815fec4f6f6fcc0e70f47
Stats:     14 lines in 4 files changed: 2 ins; 6 del; 6 mod

8306833: Change CardTable::_covered to static array

Reviewed-by: tschatzl, kbarrett

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

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

From tschatzl at openjdk.org  Thu Apr 27 12:31:24 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 27 Apr 2023 12:31:24 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v4]
In-Reply-To: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
Message-ID: <cjhTJB5OFUTT5pOdW_4IPwTEfjPez4GpuPKLQOhSK9g=.a33aea76-89b8-4470-b7b5-81796011cc52@github.com>

> Hi all,
> 
>   please review this change that removes the pinned tag from `HeapRegion`.
> 
> So that "pinned" tag for G1 heap regions indicates that the region should not move during (young) gc. This applies to now removed archive regions and humongous objects/regions.
> 
> With "real" g1 region pinning to deal with gclocker in g1 once and for all upcoming we need a refcount, a single bit is not sufficient anymore. Further there will be a naming conflict as this kind of "pinning" is different to g1 region pinning "pinning". The former indicates "contents can not be moved, but can be reclaimed", while the latter means "contents can not be moved and not reclaimed".
> 
> The (current) pinned flag is surprisingly little used, only for policy decisions.
> 
> The suggestion this change implements is to remove the "pinned" tag as it is, and reserve it for future g1 region pinning (that needs to store the pinning attribute differently as a refcount anyway).
> 
> Testing: tier1-3, gha
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  remove is_young_gc_movable in full gc code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13643/files
  - new: https://git.openjdk.org/jdk/pull/13643/files/eacf54ba..e136c7e4

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

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

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

From rkennke at openjdk.org  Thu Apr 27 12:41:56 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 27 Apr 2023 12:41:56 GMT
Subject: RFR: 8305896: Alternative full GC forwarding
Message-ID: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>

Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large. I propose to add an alternative forwarding mechanism using a forwarding table that would be used for compact object headers.

The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).

Testing:
 - [x] hotspot_gc -UseAltGCForwarding
 - [x] hotspot_gc +UseAltGCForwarding
 - [x] tier1 -UseAltGCForwarding
 - [x] tier1 +UseAltGCForwarding
 - [x] tier2 -UseAltGCForwarding
 - [x] tier2 +UseAltGCForwarding

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

Commit messages:
 - Add gtest for SlidingForwarding
 - Some cleanups
 - Fix 32 bit builds
 - Improve handling of Serial GC spaces; some refactorings
 - Implement fallback-hashtable for G1 serial compaction
 - 8305896: Alternative full GC forwarding

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

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

From tschatzl at openjdk.org  Thu Apr 27 13:25:53 2023
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 27 Apr 2023 13:25:53 GMT
Subject: RFR: 8306836: Remove pinned tag for G1 heap regions [v3]
In-Reply-To: <p_8SJVKjw780wslzPpbN0JbGdz_9cj7LIC4UjhA4GGA=.d08d0b7f-2c1f-480e-a98f-b7b99a66ba6f@github.com>
References: <t6jsFqyRY_ZJWlpqDLr4DpfcaxYZJHURfalPSHcW1KY=.c3ba8263-6979-4074-ae86-a89586f9eba0@github.com>
 <kYvyLOGR1YHM3nr3lr5yGK8xS5SFT_YNFIHBNSeRhvE=.6668da15-9481-4ec9-be8a-8b91e19eaa90@github.com>
 <p_8SJVKjw780wslzPpbN0JbGdz_9cj7LIC4UjhA4GGA=.d08d0b7f-2c1f-480e-a98f-b7b99a66ba6f@github.com>
Message-ID: <EHBr9TffozIoBzjWSsW9wZvbl_sLKrMkMi5HKQA7eMU=.6ea074c9-2ac0-43ef-bb66-b21607f491ad@github.com>

On Thu, 27 Apr 2023 10:38:17 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> > I think you are right about using is_humongous() directly here: the reason we skip compacting of humongous regions during the "main" compaction is intentional here
> 
> However, I am unable to discern the difference -- why `is_young_gc_movable` is semantically-correct in one place, but not in the other in this concrete example.
> 
> ```
> bool G1CollectionSetChooser::should_add(HeapRegion* hr) {
>   return !hr->is_young() &&
>          G1CollectedHeap::heap()->policy()->is_young_gc_movable(hr) &&
> ```
> 

`G1CollectionSetChooser::should_add` asks: can/should I add this region to the collection set candidates to evacuate (reclaim via moving) this region during young gc?

> vs
> 
> ```
> void G1FullCollector::before_marking_update_attribute_table(HeapRegion* hr) {
>   if (hr->is_free()) {
>     _region_attr_table.set_free(hr->hrm_index());
>   } else if (hr->is_humongous()) {
> ```

`G1FullCollector::before_marking_update_attribute_table` asks: can I compact/move this region in the (small object) compaction phase later?

So they are asking the question for different types of gc, where in the second case it is actually asking that question for a phase that is about compacting regular object regions. So it seems somewhat obvious to exclude non-regular object regions at the outset, or at least not use this predicate (which you criticized as non-obvious why full gc uses a predicate with "young-gc" inside).

Then there is the matter of documentation: if one writes `!is_humongous()` there, there is need for a comment like "we do not move humongous objects during young gc" everywhere you need it, while the method name also acts as the documentation, saying "exclude everything that we are not moving during young gc".

> 
> Looking at where `G1CollectionSetChooser::should_add` is called, can one use `hr->is_old()` instead of `!hr->is_young() && G1CollectedHeap::heap()->policy()->is_young_gc_movable(hr)`? (In fact, I believe that inlining `should_add` to the caller would result in a smoother code flow and prevent some duplicate region-type queries.)
> 

Combining the two into the single predicate may be correct from an execution POV. However the two predicates filter for different reasons: The `!is_young` filters out regions that are not allowed to be put in the collection set candidates at all (it's a set of old regions that young gc may evacuate later by definition), the second filters those that can't be reclaimed by moving/evacuation.

Otherwise one would need to add comments, this way it is self-commenting (and this isn't performance sensitive).

> In my opinion, introducing a new `is_young_gc_movable` API in this particular PR may not be entirely justified. It may make more sense to introduce it in later PRs where region-pinning is supported and the API is actually utilized.

`is_young_gc_movable` and pinning are separate concerns. `is_young_gc_movable` is a static view on the region. Pinning is assumed to be very transient, and assumed to not pin too much (generating lots of garbage in pinned regions basically - everything but the potentially pinned objects are still evacuated out).
So it is more than likely advantageous to put pinned regions into the candidates for proactive evacuation.

Thanks,
  Thomas

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

PR Comment: https://git.openjdk.org/jdk/pull/13643#issuecomment-1525668118

From rkennke at openjdk.org  Thu Apr 27 14:54:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 27 Apr 2023 14:54:23 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v2]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <dOL3e-oX0rQxLlf4cc9dW0HabQuSNqc3Kk7Ar10K71A=.5439bb0a-da39-44e3-b770-ec62e86943fd@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Clarify comments for SlidingForwarding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/4fad3332..ca81f54c

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

  Stats: 23 lines in 1 file changed: 12 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13582/head:pull/13582

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

From rkennke at openjdk.org  Thu Apr 27 15:29:54 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 27 Apr 2023 15:29:54 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v3]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <OU0QGrmmw-vPOHYAHY42Qa2zKGfmYSbqhGju1bJvQ_c=.ad10f56b-5595-4225-ac82-aac8066eabdc@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

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

 - Merge branch 'master' into JDK-8305896
 - Clarify comments for SlidingForwarding
 - Add gtest for SlidingForwarding
 - Some cleanups
 - Fix 32 bit builds
 - Improve handling of Serial GC spaces; some refactorings
 - Implement fallback-hashtable for G1 serial compaction
 - 8305896: Alternative full GC forwarding

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/ca81f54c..30f19716

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

  Stats: 41686 lines in 715 files changed: 26160 ins; 11223 del; 4303 mod
  Patch: https://git.openjdk.org/jdk/pull/13582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13582/head:pull/13582

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

From rkennke at openjdk.org  Thu Apr 27 15:37:53 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 27 Apr 2023 15:37:53 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v4]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <IyWUINHfh4MZ7AT1fem55-qMty_LEq_0JGEMDbcx7lI=.66d3e59f-2c35-420f-8737-4132add4f238@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Fix
 - Make flag off by default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/30f19716..a79a0eda

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

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

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

From rkennke at openjdk.org  Thu Apr 27 16:36:29 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 27 Apr 2023 16:36:29 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v5]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <-r3SSIOnHRJgP85GHgzqNjf9euMaCxnTguqDI9sqPkA=.f12337e9-ff3a-41ba-a5e3-c7780c045da0@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix 32 bit build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/a79a0eda..75f69ea4

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

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

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

From rkennke at openjdk.org  Thu Apr 27 18:02:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 27 Apr 2023 18:02:23 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v6]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <Ofou9tC73026j30HgtG3kZdFiFfHgWCHD_5XpMqHs2s=.58e6532d-dd19-4a85-827b-6aa4bb644211@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Fix wrong cast
 - Add missing include

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/75f69ea4..03b3f281

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

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

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

From rkennke at openjdk.org  Thu Apr 27 19:09:29 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 27 Apr 2023 19:09:29 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v7]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <JAqfGDQzeHnEQJFIuQ6HhR_jSZOq8Hcz7dsThsq9-DI=.d08bde44-b03f-4232-b7d0-e172154fd72d@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Fix cast again
 - Add missing include

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/03b3f281..98f32ac2

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

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

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

From rkennke at openjdk.org  Thu Apr 27 19:34:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 27 Apr 2023 19:34:23 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v8]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <VYtk3uYFcbgDu0ii9bPhPcJupt3GWkaCEQI3OYni08A=.2b147369-57ea-4d11-b748-fdf182f7afa5@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Windows build fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/98f32ac2..c0c3675e

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

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

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

From rkennke at openjdk.org  Thu Apr 27 20:54:00 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 27 Apr 2023 20:54:00 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v9]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <YF6kGoaT7kgSzaRWcLqSY-lZykaZ8axfKlF_Zt8OnQY=.5242a1a2-f9fa-48b3-82bf-b588956a88c3@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Move ifdef to right place

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/c0c3675e..c1b844b7

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

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

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

From stuefe at openjdk.org  Fri Apr 28 07:30:23 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 28 Apr 2023 07:30:23 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v9]
In-Reply-To: <YF6kGoaT7kgSzaRWcLqSY-lZykaZ8axfKlF_Zt8OnQY=.5242a1a2-f9fa-48b3-82bf-b588956a88c3@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <YF6kGoaT7kgSzaRWcLqSY-lZykaZ8axfKlF_Zt8OnQY=.5242a1a2-f9fa-48b3-82bf-b588956a88c3@github.com>
Message-ID: <UvsCxssEDOgJZZ2mew4Y2MV2ynx53_GQqmHeuBIGBzo=.2f06cb12-83f3-43a3-b7c2-e0a77a00a1c7@github.com>

On Thu, 27 Apr 2023 20:54:00 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
>> 
>> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
>> 
>> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
>> 
>> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
>> 
>> With this, forwarding information would be encoded like this:
>>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>>  - Bit 2: Used for 'fallback'-forwarding (see below)
>>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>>  - Bits 4..31 The number of heap words from the target base address
>> 
>> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
>> 
>> All the table accesses can be done unsynchronized because:
>> - Serial GC is single-threaded anyway
>> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
>> - G1 serial compaction is single-threaded
>> 
>> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
>> 
>> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
>> 
>> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
>> 
>> Testing:
>>  - [x] hotspot_gc -UseAltGCForwarding
>>  - [x] hotspot_gc +UseAltGCForwarding
>>  - [x] tier1 -UseAltGCForwarding
>>  - [x] tier1 +UseAltGCForwarding
>>  - [x] tier2 -UseAltGCForwarding
>>  - [x] tier2 +UseAltGCForwarding
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move ifdef to right place

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 63:

> 61:   }
> 62:   if (region_idx >= NUM_TARGET_REGIONS) {
> 63:     assert(UseG1GC, "Only happens with G1 serial compaction");

Breaks Minimal - proposal:  https://github.com/openjdk/lilliput/pull/87/commits/e42fae8f93cef4e531be541dab4d32bc19882647

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180022501

From rkennke at openjdk.org  Fri Apr 28 07:52:53 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 07:52:53 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v10]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <1rB2fkk813I4tm8B-G2ArcAjSJxWzyYIgf8yBWBVGwc=.8dc9ecb5-24c0-4a86-bf29-4cf6408a1b1b@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix minimal build

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/c1b844b7..743ca09d

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

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

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

From shade at openjdk.org  Fri Apr 28 09:35:28 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Apr 2023 09:35:28 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v10]
In-Reply-To: <1rB2fkk813I4tm8B-G2ArcAjSJxWzyYIgf8yBWBVGwc=.8dc9ecb5-24c0-4a86-bf29-4cf6408a1b1b@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <1rB2fkk813I4tm8B-G2ArcAjSJxWzyYIgf8yBWBVGwc=.8dc9ecb5-24c0-4a86-bf29-4cf6408a1b1b@github.com>
Message-ID: <zkiBPM_mXDpnQSyo5SCHxsFHvfJJ-UrK8UYOZGRxCts=.d0554025-2214-4609-aa12-af1eb651d0c3@github.com>

On Fri, 28 Apr 2023 07:52:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
>> 
>> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
>> 
>> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
>> 
>> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
>> 
>> With this, forwarding information would be encoded like this:
>>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>>  - Bit 2: Used for 'fallback'-forwarding (see below)
>>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>>  - Bits 4..31 The number of heap words from the target base address
>> 
>> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
>> 
>> All the table accesses can be done unsynchronized because:
>> - Serial GC is single-threaded anyway
>> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
>> - G1 serial compaction is single-threaded
>> 
>> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
>> 
>> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
>> 
>> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
>> 
>> Testing:
>>  - [x] hotspot_gc -UseAltGCForwarding
>>  - [x] hotspot_gc +UseAltGCForwarding
>>  - [x] tier1 -UseAltGCForwarding
>>  - [x] tier1 +UseAltGCForwarding
>>  - [x] tier2 -UseAltGCForwarding
>>  - [x] tier2 +UseAltGCForwarding
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix minimal build

I need to dive deeper into how `slidingForwarding.*` is documented and implemented, cursory review comments meanwhile.

src/hotspot/share/gc/g1/g1FullGCPrepareTask.inline.hpp line 35:

> 33: #include "gc/g1/g1FullGCScope.hpp"
> 34: #include "gc/g1/heapRegion.inline.hpp"
> 35: #include "gc/shared/gcForwarding.hpp"

`gcForwarding.inline.hpp`?

src/hotspot/share/gc/shared/gcForwarding.inline.hpp line 48:

> 46:   } else
> 47: #endif
> 48:     return obj->forwardee();

The usual style for these it to have braces on `else` path, so that you don't accidentally add the statement outside the `else` branch later. Like this:


#ifdef _LP64
  if (UseAltGCForwarding) {
    ...
  } else
#endif
  {
    return obj->forwardee();
  }

src/hotspot/share/gc/shared/gcForwarding.inline.hpp line 59:

> 57:   } else
> 58: #endif
> 59:     obj->forward_to(fwd);

Same as above.

src/hotspot/share/gc/shared/slidingForwarding.cpp line 49:

> 47:     _num_regions = 1;
> 48:     _region_size_words_shift = log2i_exact(round_up_power_of_2(heap_size_words));
> 49:   }

This feels like something that Serial GC code should be doing when initializing the forwarding.

src/hotspot/share/gc/shared/slidingForwarding.cpp line 54:

> 52: SlidingForwarding::~SlidingForwarding() {
> 53:   if (_target_base_table != nullptr) {
> 54:     FREE_C_HEAP_ARRAY(HeapWord*, _target_base_table);

Want to `nullptr` the pointers here? Not sure how sensible that is in destructors.

src/hotspot/share/gc/shared/slidingForwarding.cpp line 64:

> 62:   assert(_target_base_table == nullptr, "Should be uninitialized");
> 63:   _target_base_table = NEW_C_HEAP_ARRAY(HeapWord*, _num_regions * NUM_TARGET_REGIONS, mtGC);
> 64:   size_t max = _num_regions * NUM_TARGET_REGIONS;

Swap these lines and reuse `max`.

src/hotspot/share/gc/shared/slidingForwarding.cpp line 90:

> 88: HeapWord* SlidingForwarding::fallback_forwardee(HeapWord* from) const {
> 89:   if (_fallback_table == nullptr) {
> 90:     return nullptr;

Is it an error to ask for `fallback_forwardee` if there is no table initialized? This implies that no fallback forwardings happened, which implies the no fallback mask is set in any object header, so why are we at this path?

src/hotspot/share/gc/shared/slidingForwarding.cpp line 119:

> 117:   val *= 0xbf58476d1ce4e5b9ull;
> 118:   val ^= val >> 56;
> 119:   val *= 0x94d049bb133111ebull;

Is this a piece of SplitMix64? Let's say so in the comment.

src/hotspot/share/gc/shared/slidingForwarding.cpp line 121:

> 119:   val *= 0x94d049bb133111ebull;
> 120:   val = (val * 11400714819323198485llu) >> (64 - log2i_exact(TABLE_SIZE));
> 121:   assert(val < TABLE_SIZE, "must fit in table: val: " UINT64_FORMAT ", table-size: " UINTX_FORMAT ", table-size-bits: %d", val, TABLE_SIZE, log2i_exact(TABLE_SIZE));

Break the line before the arguments.

src/hotspot/share/gc/shared/slidingForwarding.cpp line 133:

> 131:     entry->_to = _table[idx]._to;
> 132:     _table[idx]._next = entry;
> 133:   }

On else branch, we should probably assert that `_table[idx]._next == nullptr`? We don't set it, but it is safer to check.

src/hotspot/share/gc/shared/slidingForwarding.hpp line 111:

> 109:   HeapWord**       _target_base_table;
> 110: 
> 111:   FallbackTable* _fallback_table;

Indentation relative to other fields.

src/hotspot/share/gc/shared/slidingForwarding.hpp line 135:

> 133: /*
> 134:  * A simple hash-table that acts as fallback for the sliding forwarding.
> 135:  * This is used in the case of G1 serial compactio, which violates the

"compaction"

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 37:

> 35: size_t SlidingForwarding::region_index_containing(HeapWord* addr) const {
> 36:   assert(addr >= _heap_start, "sanity: addr: " PTR_FORMAT " heap base: " PTR_FORMAT, p2i(addr), p2i(_heap_start));
> 37:   size_t index = ((size_t) (addr - _heap_start)) >> _region_size_words_shift;

We have `pointer_delta` for these subtractions. (This would subsume the previous assert too, I think).

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 43:

> 41: 
> 42: bool SlidingForwarding::region_contains(HeapWord* region_base, HeapWord* addr) const {
> 43:   return uintptr_t(addr - region_base) < (1ull << _region_size_words_shift);

Same, `pointer_delta`

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 46:

> 44: }
> 45: 
> 46: 

Excess newline.

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 56:

> 54:     encode_base = _target_base_table[base_table_idx + region_idx];
> 55:     if (encode_base == UNUSED_BASE) {
> 56:       encode_base = _heap_start + target_idx * (1ull << _region_size_words_shift);

`(1ull << _region_size_words_shift)` looks like something you want to pre-compute in a separate field.

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 64:

> 62:   }
> 63:   if (region_idx >= NUM_TARGET_REGIONS) {
> 64:     assert(G1GC_ONLY(UseG1GC) NOT_G1GC(false), "Only happens with G1 serial compaction");

I think the "top" GC flags are always available -- they are deliberately defined in shared `gc_globals.hpp`, so you can just `assert(UseG1GC, ...` here?

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 70:

> 68:   assert(target >= encode_base, "target must be above encode base, target:" PTR_FORMAT ", encoded_base: " PTR_FORMAT ",  target_idx: " SIZE_FORMAT ", heap start: " PTR_FORMAT ", region_idx: " INTPTR_FORMAT,
> 69:          p2i(target), p2i(encode_base), target_idx, p2i(_heap_start), region_idx);
> 70:   assert(region_contains(encode_base, target), "region must contain target: original: " PTR_FORMAT ", target: " PTR_FORMAT ", encode_base: " PTR_FORMAT ", region_idx: " INTPTR_FORMAT, p2i(original), p2i(target), p2i(encode_base), region_idx);

These are way too long, need to be broken up with line breaks.

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 71:

> 69:          p2i(target), p2i(encode_base), target_idx, p2i(_heap_start), region_idx);
> 70:   assert(region_contains(encode_base, target), "region must contain target: original: " PTR_FORMAT ", target: " PTR_FORMAT ", encode_base: " PTR_FORMAT ", region_idx: " INTPTR_FORMAT, p2i(original), p2i(target), p2i(encode_base), region_idx);
> 71:   uintptr_t encoded = (((uintptr_t)(target - encode_base)) << COMPRESSED_BITS_SHIFT) |

`pointer_delta`?

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 83:

> 81:   size_t base_table_idx = orig_idx * 2 + region_idx;
> 82:   HeapWord* decoded = _target_base_table[base_table_idx] + (encoded >> COMPRESSED_BITS_SHIFT);
> 83:   assert(decoded >= _heap_start, "must be above heap start, encoded: " INTPTR_FORMAT ", region_idx: " SIZE_FORMAT ", base: " PTR_FORMAT, encoded, region_idx, p2i(_target_base_table[base_table_idx]));

Line break after format string.

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 100:

> 98:   if ((encoded & FALLBACK_MASK) != 0) {
> 99:     fallback_forward_to(from, to);
> 100:     return;

No need for this `return`.

src/hotspot/share/gc/shared/slidingForwarding.inline.hpp line 108:

> 106:   markWord header = original->mark();
> 107:   if ((header.value() & FALLBACK_MASK) != 0) {
> 108:     HeapWord* from = cast_from_oop<HeapWord*>(original);

Can pull this `from` to the shared path, and reuse below.

src/hotspot/share/gc/shared/space.cpp line 30:

> 28: #include "gc/shared/collectedHeap.inline.hpp"
> 29: #include "gc/shared/genCollectedHeap.hpp"
> 30: #include "gc/shared/gcForwarding.inline.hpp"

Not in alphabetic order :)

test/hotspot/gtest/gc/shared/test_slidingForwarding.cpp line 60:

> 58: 
> 59:   sf.forward_to(obj1, obj2);
> 60:   ASSERT_EQ(obj1->mark().value(), uintptr_t((2 << 4) | 3));

These "magic" `(2 << 4) | 3` values should really be the calls to helper method in the test, I think. Would make the test much easier to maintain if any changes in header format are done.

test/hotspot/gtest/gc/shared/test_slidingForwarding.cpp line 63:

> 61:   ASSERT_EQ(sf.forwardee(obj1), obj2);
> 62: 
> 63:   sf.forward_to(obj1, obj3);

Wait, so this implies the forwardings can be overwritten? I understand this need for the test, but wouldn't that be a lifecycle error for product code? Once forwarding is done, it must be only reset, no?

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

PR Review: https://git.openjdk.org/jdk/pull/13582#pullrequestreview-1404392852
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180102170
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180107096
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180107632
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180132214
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180133548
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180132855
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180137812
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180140786
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180141592
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180148194
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180157853
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180149772
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180152420
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180153007
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180153255
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180158933
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180160952
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180162695
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180163068
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180163746
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180164630
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180165500
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180103112
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180120093
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180126262

From shade at openjdk.org  Fri Apr 28 09:35:30 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 28 Apr 2023 09:35:30 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v4]
In-Reply-To: <IyWUINHfh4MZ7AT1fem55-qMty_LEq_0JGEMDbcx7lI=.66d3e59f-2c35-420f-8737-4132add4f238@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <IyWUINHfh4MZ7AT1fem55-qMty_LEq_0JGEMDbcx7lI=.66d3e59f-2c35-420f-8737-4132add4f238@github.com>
Message-ID: <asIRSsaIApUAZlgBMftWbyVHrUAHZc1b99ix1896omk=.98d0e430-4c33-4e28-9ab9-076f469c8012@github.com>

On Thu, 27 Apr 2023 15:37:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
>> 
>> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
>> 
>> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
>> 
>> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
>> 
>> With this, forwarding information would be encoded like this:
>>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>>  - Bit 2: Used for 'fallback'-forwarding (see below)
>>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>>  - Bits 4..31 The number of heap words from the target base address
>> 
>> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
>> 
>> All the table accesses can be done unsynchronized because:
>> - Serial GC is single-threaded anyway
>> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
>> - G1 serial compaction is single-threaded
>> 
>> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
>> 
>> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
>> 
>> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
>> 
>> Testing:
>>  - [x] hotspot_gc -UseAltGCForwarding
>>  - [x] hotspot_gc +UseAltGCForwarding
>>  - [x] tier1 -UseAltGCForwarding
>>  - [x] tier1 +UseAltGCForwarding
>>  - [x] tier2 -UseAltGCForwarding
>>  - [x] tier2 +UseAltGCForwarding
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix
>  - Make flag off by default

src/hotspot/share/gc/shared/gc_globals.hpp line 698:

> 696:           constraint(GCCardSizeInBytesConstraintFunc,AtParse)               \
> 697:                                                                             \
> 698:   product(bool, UseAltGCForwarding, false, EXPERIMENTAL,                \

Indenting for a trailing backslash.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1179375826

From rkennke at openjdk.org  Fri Apr 28 11:34:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 11:34:23 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v10]
In-Reply-To: <zkiBPM_mXDpnQSyo5SCHxsFHvfJJ-UrK8UYOZGRxCts=.d0554025-2214-4609-aa12-af1eb651d0c3@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <1rB2fkk813I4tm8B-G2ArcAjSJxWzyYIgf8yBWBVGwc=.8dc9ecb5-24c0-4a86-bf29-4cf6408a1b1b@github.com>
 <zkiBPM_mXDpnQSyo5SCHxsFHvfJJ-UrK8UYOZGRxCts=.d0554025-2214-4609-aa12-af1eb651d0c3@github.com>
Message-ID: <5mEASRIjUVToeJEjNmTvikXSEWihHcwPQJvTVOpyEM4=.c3332c8f-71cb-462a-bdf8-798d882a832a@github.com>

On Fri, 28 Apr 2023 09:02:18 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix minimal build
>
> src/hotspot/share/gc/shared/slidingForwarding.cpp line 49:
> 
>> 47:     _num_regions = 1;
>> 48:     _region_size_words_shift = log2i_exact(round_up_power_of_2(heap_size_words));
>> 49:   }
> 
> This feels like something that Serial GC code should be doing when initializing the forwarding.

Yes but that means to create a dependency that I would rather like to avoid: Serial GC would have to know about the maximum encodable range of slidingForwarding (and therefore about sliding forwarding to begin with). OTOH, the way I did it was to create the dependency in the inverse direction. A way out might be to not do that optimization, but it seems rather important: the heap < 2GB seems fairly common with Serial GC. Hmmm

> test/hotspot/gtest/gc/shared/test_slidingForwarding.cpp line 63:
> 
>> 61:   ASSERT_EQ(sf.forwardee(obj1), obj2);
>> 62: 
>> 63:   sf.forward_to(obj1, obj3);
> 
> Wait, so this implies the forwardings can be overwritten? I understand this need for the test, but wouldn't that be a lifecycle error for product code? Once forwarding is done, it must be only reset, no?

As far as I understand, GC serial compaction can re-forward already forwarded objects.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180283786
PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180280730

From eosterlund at openjdk.org  Fri Apr 28 13:55:22 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 Apr 2023 13:55:22 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v10]
In-Reply-To: <1rB2fkk813I4tm8B-G2ArcAjSJxWzyYIgf8yBWBVGwc=.8dc9ecb5-24c0-4a86-bf29-4cf6408a1b1b@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <1rB2fkk813I4tm8B-G2ArcAjSJxWzyYIgf8yBWBVGwc=.8dc9ecb5-24c0-4a86-bf29-4cf6408a1b1b@github.com>
Message-ID: <ADMBY0hzCSrLO4FRHo4IPYJaagXAbwIGzYNei5hXjDo=.41034c46-b134-47df-b537-7e7c920b84db@github.com>

On Fri, 28 Apr 2023 07:52:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
>> 
>> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
>> 
>> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
>> 
>> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
>> 
>> With this, forwarding information would be encoded like this:
>>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>>  - Bit 2: Used for 'fallback'-forwarding (see below)
>>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>>  - Bits 4..31 The number of heap words from the target base address
>> 
>> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
>> 
>> All the table accesses can be done unsynchronized because:
>> - Serial GC is single-threaded anyway
>> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
>> - G1 serial compaction is single-threaded
>> 
>> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
>> 
>> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
>> 
>> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
>> 
>> Testing:
>>  - [x] hotspot_gc -UseAltGCForwarding
>>  - [x] hotspot_gc +UseAltGCForwarding
>>  - [x] tier1 -UseAltGCForwarding
>>  - [x] tier1 +UseAltGCForwarding
>>  - [x] tier2 -UseAltGCForwarding
>>  - [x] tier2 +UseAltGCForwarding
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix minimal build

Nice work @rkennke. Do you have any data on the RSS impact of using the alt forwarding table for some programs? Naturally, as the main motivation of the change is to allow a memory optimization, we shouldn't be too wasteful with memory to enable said memory optimization.

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

PR Comment: https://git.openjdk.org/jdk/pull/13582#issuecomment-1527576950

From rkennke at openjdk.org  Fri Apr 28 14:16:58 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 14:16:58 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v10]
In-Reply-To: <ADMBY0hzCSrLO4FRHo4IPYJaagXAbwIGzYNei5hXjDo=.41034c46-b134-47df-b537-7e7c920b84db@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <1rB2fkk813I4tm8B-G2ArcAjSJxWzyYIgf8yBWBVGwc=.8dc9ecb5-24c0-4a86-bf29-4cf6408a1b1b@github.com>
 <ADMBY0hzCSrLO4FRHo4IPYJaagXAbwIGzYNei5hXjDo=.41034c46-b134-47df-b537-7e7c920b84db@github.com>
Message-ID: <s0K2mo7-h_mPuN_T_a8tw92a23P95SF76pTIVXL45Lk=.02c5f0f2-9dc4-4e75-83b7-84d041f29f82@github.com>

On Fri, 28 Apr 2023 13:36:33 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> Nice work @rkennke. Do you have any data on the RSS impact of using the alt forwarding table for some programs? Naturally, as the main motivation of the change is to allow a memory optimization, we shouldn't be too wasteful with memory to enable said memory optimization.

It only allocates a relatively small side-table that is number-of-regions * 2words. For G1 and Shenandoah, it uses the 'natural' GC regions. A typical number of regions would be 2048, so we'd get a side-table of 4096 * 2 * 8 = 64KB. If we assume a region-size of 2M (which seems at the lower end of the spectrum) then that heap would be 4GB. That's an overhead of 0.0016% if I counted correctly. Ultimately it depends on the workload, but I believe it is an acceptable overhead.

Also, the 'memory optimization' (compact object headers) would be benefitial for the common operation, i.e. *all situations*. This GC forwarding change is only relevant for full-GCs which is an exceptional situation. At least in Shenandoah we try very hard to avoid it altogether, for Serial and G1 it tends to happen once in a while, but IMO not often enough that 0.0016% overhead would be a concern.

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

PR Comment: https://git.openjdk.org/jdk/pull/13582#issuecomment-1527613926

From rkennke at openjdk.org  Fri Apr 28 14:38:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 14:38:23 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v11]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <hugTyVFPxqwbPWQxs9YoHuC_1sb6nN5ta8zoFscWWyA=.c6202072-d205-492b-9c95-6aa8482ee034@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Address @shipilev's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/743ca09d..0ef9950b

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

  Stats: 61 lines in 8 files changed: 29 ins; 9 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/13582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13582/head:pull/13582

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

From rkennke at openjdk.org  Fri Apr 28 14:54:53 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 14:54:53 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v12]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <7wh9oQNWTga_roKBanu2246zZ53TTL3HyoeAdnVQYpk=.f69973bf-821c-47dc-a8df-f4b47af1c9a6@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Improve comment/explanation at top of SlidingForwarding, thanks @shipilev

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/0ef9950b..f2804816

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

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

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

From eosterlund at openjdk.org  Fri Apr 28 14:55:23 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 Apr 2023 14:55:23 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v12]
In-Reply-To: <7wh9oQNWTga_roKBanu2246zZ53TTL3HyoeAdnVQYpk=.f69973bf-821c-47dc-a8df-f4b47af1c9a6@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <7wh9oQNWTga_roKBanu2246zZ53TTL3HyoeAdnVQYpk=.f69973bf-821c-47dc-a8df-f4b47af1c9a6@github.com>
Message-ID: <HhOyH1aEj9rQSQ50P4697AaHy2WWw1ZxCqLVdTOS6K8=.9f270054-3d02-4538-85d7-203250fe0251@github.com>

On Fri, 28 Apr 2023 14:38:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
>> 
>> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
>> 
>> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
>> 
>> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
>> 
>> With this, forwarding information would be encoded like this:
>>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>>  - Bit 2: Used for 'fallback'-forwarding (see below)
>>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>>  - Bits 4..31 The number of heap words from the target base address
>> 
>> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
>> 
>> All the table accesses can be done unsynchronized because:
>> - Serial GC is single-threaded anyway
>> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
>> - G1 serial compaction is single-threaded
>> 
>> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
>> 
>> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
>> 
>> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
>> 
>> Testing:
>>  - [x] hotspot_gc -UseAltGCForwarding
>>  - [x] hotspot_gc +UseAltGCForwarding
>>  - [x] tier1 -UseAltGCForwarding
>>  - [x] tier1 +UseAltGCForwarding
>>  - [x] tier2 -UseAltGCForwarding
>>  - [x] tier2 +UseAltGCForwarding
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comment/explanation at top of SlidingForwarding, thanks @shipilev

src/hotspot/share/gc/shared/slidingForwarding.cpp line 114:

> 112: }
> 113: 
> 114: size_t FallbackTable::home_index(HeapWord* from) {

What is the license for this code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180492253

From eosterlund at openjdk.org  Fri Apr 28 14:54:55 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 Apr 2023 14:54:55 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v10]
In-Reply-To: <s0K2mo7-h_mPuN_T_a8tw92a23P95SF76pTIVXL45Lk=.02c5f0f2-9dc4-4e75-83b7-84d041f29f82@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <1rB2fkk813I4tm8B-G2ArcAjSJxWzyYIgf8yBWBVGwc=.8dc9ecb5-24c0-4a86-bf29-4cf6408a1b1b@github.com>
 <ADMBY0hzCSrLO4FRHo4IPYJaagXAbwIGzYNei5hXjDo=.41034c46-b134-47df-b537-7e7c920b84db@github.com>
 <s0K2mo7-h_mPuN_T_a8tw92a23P95SF76pTIVXL45Lk=.02c5f0f2-9dc4-4e75-83b7-84d041f29f82@github.com>
Message-ID: <lhEjl1ow056a6CFsWlh6kQ7O_QjNA1q6sBWHhLb3ozk=.bbe03982-c7c5-48e0-b6f5-c6758990d39f@github.com>

On Fri, 28 Apr 2023 14:00:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Nice work @rkennke. Do you have any data on the RSS impact of using the alt forwarding table for some programs? Naturally, as the main motivation of the change is to allow a memory optimization, we shouldn't be too wasteful with memory to enable said memory optimization.
>
>> Nice work @rkennke. Do you have any data on the RSS impact of using the alt forwarding table for some programs? Naturally, as the main motivation of the change is to allow a memory optimization, we shouldn't be too wasteful with memory to enable said memory optimization.
> 
> It only allocates a relatively small side-table that is number-of-regions * 2words. For G1 and Shenandoah, it uses the 'natural' GC regions. A typical number of regions would be 2048, so we'd get a side-table of 4096 * 2 * 8 = 64KB. If we assume a region-size of 2M (which seems at the lower end of the spectrum) then that heap would be 4GB. That's an overhead of 0.0016% if I counted correctly. Ultimately it depends on the workload, but I believe it is an acceptable overhead.
> 
> Also, the 'memory optimization' (compact object headers) would be benefitial for the common operation, i.e. *all situations*. This GC forwarding change is only relevant for full-GCs which is an exceptional situation. At least in Shenandoah we try very hard to avoid it altogether, for Serial and G1 it tends to happen once in a while, but IMO not often enough that 0.0016% overhead would be a concern.

> > Nice work @rkennke. Do you have any data on the RSS impact of using the alt forwarding table for some programs? Naturally, as the main motivation of the change is to allow a memory optimization, we shouldn't be too wasteful with memory to enable said memory optimization.
> 
> It only allocates a relatively small side-table that is number-of-regions * 2words. For G1 and Shenandoah, it uses the 'natural' GC regions. A typical number of regions would be 2048, so we'd get a side-table of 4096 * 2 * 8 = 64KB. If we assume a region-size of 2M (which seems at the lower end of the spectrum) then that heap would be 4GB. That's an overhead of 0.0016% if I counted correctly. Ultimately it depends on the workload, but I believe it is an acceptable overhead.
> 
> Also, the 'memory optimization' (compact object headers) would be benefitial for the common operation, i.e. _all situations_. This GC forwarding change is only relevant for full-GCs which is an exceptional situation. At least in Shenandoah we try very hard to avoid it altogether, for Serial and G1 it tends to happen once in a while, but IMO not often enough that 0.0016% overhead would be a concern.

Sounds good.

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

PR Comment: https://git.openjdk.org/jdk/pull/13582#issuecomment-1527672618

From rkennke at openjdk.org  Fri Apr 28 15:31:00 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 15:31:00 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v13]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <XZxjbOEjTH4urdGW6NIgqgwcb6lMC5KKXDtlhkBW3KE=.fdd1febb-cd6f-4d84-952b-f5a4f02113b1@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix pointer_delta() underflow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/f2804816..2f5b30e1

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

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

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

From rkennke at openjdk.org  Fri Apr 28 15:31:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 15:31:23 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v12]
In-Reply-To: <HhOyH1aEj9rQSQ50P4697AaHy2WWw1ZxCqLVdTOS6K8=.9f270054-3d02-4538-85d7-203250fe0251@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <7wh9oQNWTga_roKBanu2246zZ53TTL3HyoeAdnVQYpk=.f69973bf-821c-47dc-a8df-f4b47af1c9a6@github.com>
 <HhOyH1aEj9rQSQ50P4697AaHy2WWw1ZxCqLVdTOS6K8=.9f270054-3d02-4538-85d7-203250fe0251@github.com>
Message-ID: <QMCi19LusZq65zXPbPaS_6yNotcgRH7iryk7tDySj2I=.878337dd-b05f-4414-a9f8-fd7fa1a42e35@github.com>

On Fri, 28 Apr 2023 14:36:06 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve comment/explanation at top of SlidingForwarding, thanks @shipilev
>
> src/hotspot/share/gc/shared/slidingForwarding.cpp line 114:
> 
>> 112: }
>> 113: 
>> 114: size_t FallbackTable::home_index(HeapWord* from) {
> 
> What is the license for this code?

I've written that code using publicly available documentation. Do I need legal review to do that? Alternatively I would use the murmur3 mixer which is public domain.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180540425

From rkennke at openjdk.org  Fri Apr 28 15:39:53 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 15:39:53 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v12]
In-Reply-To: <QMCi19LusZq65zXPbPaS_6yNotcgRH7iryk7tDySj2I=.878337dd-b05f-4414-a9f8-fd7fa1a42e35@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <7wh9oQNWTga_roKBanu2246zZ53TTL3HyoeAdnVQYpk=.f69973bf-821c-47dc-a8df-f4b47af1c9a6@github.com>
 <HhOyH1aEj9rQSQ50P4697AaHy2WWw1ZxCqLVdTOS6K8=.9f270054-3d02-4538-85d7-203250fe0251@github.com>
 <QMCi19LusZq65zXPbPaS_6yNotcgRH7iryk7tDySj2I=.878337dd-b05f-4414-a9f8-fd7fa1a42e35@github.com>
Message-ID: <wDt_7jkCvvaVlQ369c5vxeT0V27BLQuV8n5uvaD40wI=.b14b020e-84ec-41d4-a13f-0192b501d150@github.com>

On Fri, 28 Apr 2023 15:20:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shared/slidingForwarding.cpp line 114:
>> 
>>> 112: }
>>> 113: 
>>> 114: size_t FallbackTable::home_index(HeapWord* from) {
>> 
>> What is the license for this code?
>
> I've written that code using publicly available documentation. Do I need legal review to do that? Alternatively I would use the murmur3 mixer which is public domain.

I changed that code to use the murmur3 mixer instead. This is PD and should hopefully not cause troubles.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180557219

From rkennke at openjdk.org  Fri Apr 28 16:00:54 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 16:00:54 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v14]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <A-jW2U6oIkni2wciP1mbYgSR2ac4g-sY3JTpprOK3k4=.7b52a8c4-1ce6-4839-9539-26ae50c530e4@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Use murmur3 hash-code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/2f5b30e1..31e90e42

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

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

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

From eosterlund at openjdk.org  Fri Apr 28 16:46:54 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 Apr 2023 16:46:54 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v12]
In-Reply-To: <wDt_7jkCvvaVlQ369c5vxeT0V27BLQuV8n5uvaD40wI=.b14b020e-84ec-41d4-a13f-0192b501d150@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <7wh9oQNWTga_roKBanu2246zZ53TTL3HyoeAdnVQYpk=.f69973bf-821c-47dc-a8df-f4b47af1c9a6@github.com>
 <HhOyH1aEj9rQSQ50P4697AaHy2WWw1ZxCqLVdTOS6K8=.9f270054-3d02-4538-85d7-203250fe0251@github.com>
 <QMCi19LusZq65zXPbPaS_6yNotcgRH7iryk7tDySj2I=.878337dd-b05f-4414-a9f8-fd7fa1a42e35@github.com>
 <wDt_7jkCvvaVlQ369c5vxeT0V27BLQuV8n5uvaD40wI=.b14b020e-84ec-41d4-a13f-0192b501d150@github.com>
Message-ID: <3H0IufrunNdAbYOGOTTp9oLepzSV7so-xIBrWUXoFkU=.980fe927-a804-48be-9c5a-aa7de4b8142e@github.com>

On Fri, 28 Apr 2023 15:35:31 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> I've written that code using publicly available documentation. Do I need legal review to do that? Alternatively I would use the murmur3 mixer which is public domain.
>
> I changed that code to use the murmur3 mixer instead. This is PD and should hopefully not cause troubles.

Is it used in hotspot already? The pragmatic thing would be to not introduce code with external licenses, whatever that license is, unless you want a ride in a legal slow path. We felt that pain with zHash. 1/10 would not recommend. Of course if you need it we can do it, but I'd think twice before going down that route.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180614053

From rkennke at openjdk.org  Fri Apr 28 16:47:23 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 16:47:23 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v12]
In-Reply-To: <3H0IufrunNdAbYOGOTTp9oLepzSV7so-xIBrWUXoFkU=.980fe927-a804-48be-9c5a-aa7de4b8142e@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <7wh9oQNWTga_roKBanu2246zZ53TTL3HyoeAdnVQYpk=.f69973bf-821c-47dc-a8df-f4b47af1c9a6@github.com>
 <HhOyH1aEj9rQSQ50P4697AaHy2WWw1ZxCqLVdTOS6K8=.9f270054-3d02-4538-85d7-203250fe0251@github.com>
 <QMCi19LusZq65zXPbPaS_6yNotcgRH7iryk7tDySj2I=.878337dd-b05f-4414-a9f8-fd7fa1a42e35@github.com>
 <wDt_7jkCvvaVlQ369c5vxeT0V27BLQuV8n5uvaD40wI=.b14b020e-84ec-41d4-a13f-0192b501d150@github.com>
 <3H0IufrunNdAbYOGOTTp9oLepzSV7so-xIBrWUXoFkU=.980fe927-a804-48be-9c5a-aa7de4b8142e@github.com>
Message-ID: <XrJOOTL7JWr7GbnxoTa58cKe4Y0Oadw9Jl4Qm4qzB5A=.687e4e45-c80b-4d00-853b-e59f5469ba57@github.com>

On Fri, 28 Apr 2023 16:37:33 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> I changed that code to use the murmur3 mixer instead. This is PD and should hopefully not cause troubles.
>
> Is it used in hotspot already? The pragmatic thing would be to not introduce code with external licenses, whatever that license is, unless you want a ride in a legal slow path. We felt that pain with zHash. 1/10 would not recommend. Of course if you need it we can do it, but I'd think twice before going down that route.

It seems to be used in a couple of places already:

grep -R ff51afd7ed558ccd src
src/jdk.jfr/share/classes/jdk/jfr/internal/EventWriterKey.java:        z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL;
src/java.base/share/classes/java/util/SplittableRandom.java:        z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL; // MurmurHash3 mix constants
src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java:        z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL;
src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java:        z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL;
src/hotspot/share/gc/shared/slidingForwarding.cpp:  val *= 0xff51afd7ed558ccdULL;
src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.cpp:  key *= UINT64_C(0xff51afd7ed558ccd);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180618557

From eosterlund at openjdk.org  Fri Apr 28 18:06:54 2023
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 28 Apr 2023 18:06:54 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v12]
In-Reply-To: <XrJOOTL7JWr7GbnxoTa58cKe4Y0Oadw9Jl4Qm4qzB5A=.687e4e45-c80b-4d00-853b-e59f5469ba57@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
 <7wh9oQNWTga_roKBanu2246zZ53TTL3HyoeAdnVQYpk=.f69973bf-821c-47dc-a8df-f4b47af1c9a6@github.com>
 <HhOyH1aEj9rQSQ50P4697AaHy2WWw1ZxCqLVdTOS6K8=.9f270054-3d02-4538-85d7-203250fe0251@github.com>
 <QMCi19LusZq65zXPbPaS_6yNotcgRH7iryk7tDySj2I=.878337dd-b05f-4414-a9f8-fd7fa1a42e35@github.com>
 <wDt_7jkCvvaVlQ369c5vxeT0V27BLQuV8n5uvaD40wI=.b14b020e-84ec-41d4-a13f-0192b501d150@github.com>
 <3H0IufrunNdAbYOGOTTp9oLepzSV7so-xIBrWUXoFkU=.980fe927-a804-48be-9c5a-aa7de4b8142e@github.com>
 <XrJOOTL7JWr7GbnxoTa58cKe4Y0Oadw9Jl4Qm4qzB5A=.687e4e45-c80b-4d00-853b-e59f5469ba57@github.com>
Message-ID: <Z8zghKTXI6ZoFUX3oGlsAALEQWZ7_hc-Lg0Oj6ILmL4=.4b3b3928-cc5c-4267-a0d0-2fdf3432dbca@github.com>

On Fri, 28 Apr 2023 16:42:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Is it used in hotspot already? The pragmatic thing would be to not introduce code with external licenses, whatever that license is, unless you want a ride in a legal slow path. We felt that pain with zHash. 1/10 would not recommend. Of course if you need it we can do it, but I'd think twice before going down that route.
>
> It seems to be used in a couple of places already:
> 
> grep -R ff51afd7ed558ccd src
> src/jdk.jfr/share/classes/jdk/jfr/internal/EventWriterKey.java:        z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL;
> src/java.base/share/classes/java/util/SplittableRandom.java:        z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL; // MurmurHash3 mix constants
> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java:        z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL;
> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java:        z = (z ^ (z >>> 33)) * 0xff51afd7ed558ccdL;
> src/hotspot/share/gc/shared/slidingForwarding.cpp:  val *= 0xff51afd7ed558ccdULL;
> src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.cpp:  key *= UINT64_C(0xff51afd7ed558ccd);

Sounds good then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13582#discussion_r1180673978

From rkennke at openjdk.org  Fri Apr 28 19:34:53 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 28 Apr 2023 19:34:53 GMT
Subject: RFR: 8305896: Alternative full GC forwarding [v15]
In-Reply-To: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
References: <yFs73BPFgB89xCPY4k63X4VTz13N8ELJf1lGQlE6UpA=.85ee4f25-a4ee-41d0-b4c2-ed9ff2cb1bb1@github.com>
Message-ID: <ZygXUNbwNLZmR7wks3TK_8jJnb53AgQAQqQlkzPeQIA=.5ddcb7ec-3681-459c-b21c-577e48ca70d9@github.com>

> Currently, the full-GC modes of Serial, Shenandoah and G1 GCs are forwarding objects by over-writing the object header with the new object location. Unfortunately, for compact object headers ([JDK-8294992](https://bugs.openjdk.org/browse/JDK-8294992)) this would not work, because the crucial class information is also stored in the header, and we could no longer iterate over objects until the headers would be restored. Also, the preserved-headers tables would grow quite large.
> 
> I propose to use an alternative algorithm for full-GC (sliding-GC) forwarding that uses a special encoding so that the forwarding information fits into the lowest 32 bits of the header.
> 
> It exploits the insight that, with sliding GCs, objects from one region will only ever be forwarded to one of two possible target regions. For this to work, we need to divide the heap into equal-sized regions. This is already the case for Shenandoah and G1, and can easily be overlaid for Serial GC, by assuming either the whole heap as a single region (if it fits) or by using SpaceAlignment-sized virtual regions.
> 
> We also build and maintain a table that has N elements, where N is the number of regions. Each entry is two addresses, which are the start-address of the possible target regions for each source region.
> 
> With this, forwarding information would be encoded like this:
>  - Bits 0 and 1: same as before, we put in '11' to indicate that the object is forwarded.
>  - Bit 2: Used for 'fallback'-forwarding (see below)
>  - Bit 3: Selects the target region 0 or 1. Look up the base address in the table (see above)
>  - Bits 4..31 The number of heap words from the target base address
> 
> This works well for all sliding GCs in Serial, G1 and Shenandoah. The exception is in G1, there is a special mode called 'serial compaction' which acts as a last-last-ditch effort to squeeze more space out of the heap by re-forwarding the tails of the compaction chains. Unfortunately, this breaks the assumption of the sliding-forwarding-table. When that happens, we initialize a fallback table, which is a simple open hash-table, and set the Bit 2 in the forwarding to indicate that we shall look up the forwardee in the fallback-table.
> 
> All the table accesses can be done unsynchronized because:
> - Serial GC is single-threaded anyway
> - In G1 and Shenandoah, GC worker threads divide up the work such that each worker does disjoint sets of regions.
> - G1 serial compaction is single-threaded
> 
> The change introduces a new (experimental) flag -XX:[+|-]UseAltGCForwarding. This flag is not really intended to be used by end-users. Instead, I intend to programatically enable it with compact object headers once they arrive (i.e. -XX:+UseCompactObjectHeaders would turn on -XX:+UseAltGCForwarding), and the flag is also useful for testing purposes. Once compact object headers become the default and only implementation, the flag and old implementation could be removed. Also, [JDK-8305898](https://bugs.openjdk.org/browse/JDK-8305898) would also use the same flag to enable an alternative self-forwarding approach (also in support of compact object headers).
> 
> The change also adds a utility class GCForwarding which calls the old or new implementation based on the flag. I think it would also be used for the self-forwarding change to be proposed soon (and separately).
> 
> I also experimented with a different forwarding approach that would use per-region hashtables, but shelved it for now, because performance was significantly worse than the sliding forwarding encoding. It will become useful later when we want to do 32bit compact object headers, because then, the sliding encoding will not be sufficient to hold forwarding pointers in the header.
> 
> Testing:
>  - [x] hotspot_gc -UseAltGCForwarding
>  - [x] hotspot_gc +UseAltGCForwarding
>  - [x] tier1 -UseAltGCForwarding
>  - [x] tier1 +UseAltGCForwarding
>  - [x] tier2 -UseAltGCForwarding
>  - [x] tier2 +UseAltGCForwarding

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Some more changes by @shipilev

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13582/files
  - new: https://git.openjdk.org/jdk/pull/13582/files/31e90e42..74d4ad1f

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

  Stats: 159 lines in 3 files changed: 29 ins; 45 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/13582.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13582/head:pull/13582

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