From ccheung at openjdk.org  Fri Jul  1 21:49:47 2022
From: ccheung at openjdk.org (Calvin Cheung)
Date: Fri, 1 Jul 2022 21:49:47 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v3]
In-Reply-To: <Z0lHSUzi5gdXlQ5_DMl6rO0hxg-b4rfeCX5hwZuHaHQ=.c267b32c-47bd-4efa-a248-aef033d64bf4@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <Z0lHSUzi5gdXlQ5_DMl6rO0hxg-b4rfeCX5hwZuHaHQ=.c267b32c-47bd-4efa-a248-aef033d64bf4@github.com>
Message-ID: <AVQXwvbd8IxMNBU7gF4NQ-M56hRQrq1Ar6r4Kfp9mAc=.01199773-f9b8-4fc8-99e5-6cdbe6f7f2e3@github.com>

On Tue, 28 Jun 2022 20:13:01 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There are only two implementations of these classes (one for windows, and one for posix):
>> 
>> - PlatformEvent
>> - PlatformParker
>> - PlatformMutex
>> - PlatformMonitor
>> - ThreadCrashProtection
>> 
>> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
>> 
>> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
>> 
>> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @coleenp comments

Looks good. Just one nit.

src/hotspot/share/runtime/mutex.cpp line 334:

> 332: }
> 333: 
> 334: 

Line 334 deleted by accident?

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

Marked as reviewed by ccheung (Reviewer).

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

From iklam at openjdk.org  Sat Jul  2 04:26:48 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 2 Jul 2022 04:26:48 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v4]
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>

> There are only two implementations of these classes (one for windows, and one for posix):
> 
> - PlatformEvent
> - PlatformParker
> - PlatformMutex
> - PlatformMonitor
> - ThreadCrashProtection
> 
> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
> 
> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
> 
> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).

Ioi Lam 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:

 - removed unrelated newline change
 - Merge branch 'master' into 8289230-move-Platform-classes-out-of-os-xxx-hpp
 - @coleenp comments
 - fixed comments
 - fixed windows
 - Moved PlatformMutex/PlatformMonitor
 - move-PlatformParker-out-of-os-xxx-hpp
 - Moved ThreadCrashProtection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9303/files
  - new: https://git.openjdk.org/jdk/pull/9303/files/9d502ffb..bafda85c

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

  Stats: 8540 lines in 227 files changed: 5586 ins; 1406 del; 1548 mod
  Patch: https://git.openjdk.org/jdk/pull/9303.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9303/head:pull/9303

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

From iklam at openjdk.org  Sat Jul  2 14:47:39 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 2 Jul 2022 14:47:39 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v2]
In-Reply-To: <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <w5TDyq4oZJ4rOc-5x9-qJ6JMCC2TO1LkAnbYR8KUUBM=.3183fcab-8465-4af3-8dfc-770704041d11@github.com>
 <eHmU_IW-A6Tnf8k4JPFSaJmc0rvg64i8LbgMKRNJ8H0=.3332ed30-5057-43b5-acee-3ea8ddc24a14@github.com>
Message-ID: <dCjeLmjfDmb-pcFUh7_Lp1COYwG-zWjBH2xK827Xpak=.082fba71-154b-4d0f-b207-6bfff08e734a@github.com>

On Tue, 28 Jun 2022 19:39:29 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed comments
>
> I very much like this incremental approach to reducing our over-inclusion.

Thanks @coleenp @calvinccheung @dholmes-ora for the review.

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

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

From iklam at openjdk.org  Sat Jul  2 14:47:40 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Sat, 2 Jul 2022 14:47:40 GMT
Subject: Integrated: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp
In-Reply-To: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
Message-ID: <vzewurbF5YHkstzu1cwTdlrG3lnxAACvS-RD0Qwj2l0=.f2dcb156-3799-4870-877a-2addc01ff4fc@github.com>

On Tue, 28 Jun 2022 06:16:21 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> There are only two implementations of these classes (one for windows, and one for posix):
> 
> - PlatformEvent
> - PlatformParker
> - PlatformMutex
> - PlatformMonitor
> - ThreadCrashProtection
> 
> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
> 
> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
> 
> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).

This pull request has now been integrated.

Changeset: cdf69792
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cdf697925953f62e17a7916ba611d7e789f09edf
Stats:     1172 lines in 36 files changed: 703 ins; 390 del; 79 mod

8289230: Move PlatformXXX class declarations out of os_xxx.hpp

Reviewed-by: coleenp, ccheung

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

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

From ysr at openjdk.org  Sat Jul  2 16:22:09 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 2 Jul 2022 16:22:09 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v2]
In-Reply-To: <WQrnsfdI662sSK3tamSfkr9nvq0_SG5AUsT5M1gMkdQ=.748dfc81-6bbf-4dce-b52c-00c2243e729a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
 <WQrnsfdI662sSK3tamSfkr9nvq0_SG5AUsT5M1gMkdQ=.748dfc81-6bbf-4dce-b52c-00c2243e729a@github.com>
Message-ID: <5JhbNlVOmwqBbccX9LCdSJMjE6QIMO8ZQJfFuTZFqRc=.03d53ad8-1426-41af-afeb-d79d9376ebaa@github.com>

On Tue, 28 Jun 2022 21:16:15 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This commit consolidates computations related to budgeting of reserves for old-gen evacuation and old-gen promotion within shenandoahGeneration::prepare_regions_and_collection_set().  Previously, these computations had been scattered between several functional units, including shenandoahHeuristics::choose_collection_set() and shenandoahOldHeuristics::prime_collection_set().  A previous pull request brought some of the redundant functionality into prepare_regions_and_collection_set().  This pull request removes the redundant computations from the other locations.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Isolate the code that reserves evacuation budgets into functions

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

> 222: }
> 223: 
> 224: void ShenandoahGeneration::compute_evacuation_budgets(ShenandoahHeap* heap, ShenandoahCollectionSet* collection_set,

The refactoring of the large chunks of code into the smaller methods is definitely a step in the right direction in making the code easier to follow.

Nit: Would it make the code more readable to consolidate the long sections of comments into a block comment at the top of each of the methods and have much shorter comments in the body of the methods?

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

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

From ysr at openjdk.org  Sat Jul  2 16:33:11 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 2 Jul 2022 16:33:11 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v2]
In-Reply-To: <WQrnsfdI662sSK3tamSfkr9nvq0_SG5AUsT5M1gMkdQ=.748dfc81-6bbf-4dce-b52c-00c2243e729a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
 <WQrnsfdI662sSK3tamSfkr9nvq0_SG5AUsT5M1gMkdQ=.748dfc81-6bbf-4dce-b52c-00c2243e729a@github.com>
Message-ID: <5_UoSoeQbbxD2UJtYImJi4VbunawMXSmlt8SpA4SAzk=.1e91b93f-71b4-4bd5-b529-578b875f6aaa@github.com>

On Tue, 28 Jun 2022 21:16:15 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This commit consolidates computations related to budgeting of reserves for old-gen evacuation and old-gen promotion within shenandoahGeneration::prepare_regions_and_collection_set().  Previously, these computations had been scattered between several functional units, including shenandoahHeuristics::choose_collection_set() and shenandoahOldHeuristics::prime_collection_set().  A previous pull request brought some of the redundant functionality into prepare_regions_and_collection_set().  This pull request removes the redundant computations from the other locations.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Isolate the code that reserves evacuation budgets into functions

Left a few minor syntactic/stylistic comments.

src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 114:

> 112:   void prepare_gc(bool do_old_gc_bootstrap);
> 113: 
> 114:   // Compute evacuation budgets prior to choosing collection set.

Do these methods need to be public? They looked more like helper methods in the way they are currently being used.

Another thing to think about is whether the reference parameters in one signature and regular ones in the other are potential sources of confusion or error in the future. I can see why they are like they are in their current use, but might indicate that perhaps a cleaner refactoring of the methods and the state that it uses or modifies, and where that state should reside.

Nothing to do at the moment, but worth thinking about.

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

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

From duke at openjdk.org  Sun Jul  3 00:59:46 2022
From: duke at openjdk.org (kristylee88)
Date: Sun, 3 Jul 2022 00:59:46 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v4]
In-Reply-To: <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>
Message-ID: <of343gVLCsk8FtdsT3zv3ilqPTHlOfs_2FKX2zciMvc=.018d10a7-3449-46e8-a4b3-c7d52895b0ee@github.com>

On Sat, 2 Jul 2022 04:26:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There are only two implementations of these classes (one for windows, and one for posix):
>> 
>> - PlatformEvent
>> - PlatformParker
>> - PlatformMutex
>> - PlatformMonitor
>> - ThreadCrashProtection
>> 
>> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
>> 
>> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
>> 
>> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).
>
> Ioi Lam 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:
> 
>  - removed unrelated newline change
>  - Merge branch 'master' into 8289230-move-Platform-classes-out-of-os-xxx-hpp
>  - @coleenp comments
>  - fixed comments
>  - fixed windows
>  - Moved PlatformMutex/PlatformMonitor
>  - move-PlatformParker-out-of-os-xxx-hpp
>  - Moved ThreadCrashProtection

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

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

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

From duke at openjdk.org  Sun Jul  3 01:28:44 2022
From: duke at openjdk.org (kristylee88)
Date: Sun, 3 Jul 2022 01:28:44 GMT
Subject: RFR: 8289230: Move PlatformXXX class declarations out of
 os_xxx.hpp [v4]
In-Reply-To: <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>
References: <0v7-TE5YMMz_zYMiuxdpTNpFcfCWqX-eG9l5R0uSvHk=.7b09cfd0-c85a-48bb-bf54-581496e2d996@github.com>
 <nEYbWc6VGfEWGjwWUlXM2kyHHuvZhqKTibRpcncuU3M=.1889c4f0-eed9-4dcf-81eb-25d2f5fc8fd0@github.com>
Message-ID: <0RDnszyg_IHLT64-8cM28uYDlMl1iJiUrnvUAzYtRu0=.2616eaaf-3baf-4c31-9b95-a181598046ec@github.com>

On Sat, 2 Jul 2022 04:26:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> There are only two implementations of these classes (one for windows, and one for posix):
>> 
>> - PlatformEvent
>> - PlatformParker
>> - PlatformMutex
>> - PlatformMonitor
>> - ThreadCrashProtection
>> 
>> Before this PR, these classes are declared in os_xxx.hpp. This causes excessive inclusion of the large header file os.hpp by popular headers such as mutex.hpp, which needs only the declaration of PlatformMutex but not the other stuff in os.hpp
>> 
>> This PR moves the declarations to park_posix.hpp, mutex_posix.hpp, etc.
>> 
>> Note:  ideally, the definition of PlatformParker/PlatformEvent should be moved to park_posix.cpp, and PlatformMutex/PlatformMonitor should be moved to mutex_posix.cpp. However, the definition of these 4 classes are intertwined, so I'll leave them inside os_posix.cpp for now. (Same for the Windows version).
>
> Ioi Lam 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:
> 
>  - removed unrelated newline change
>  - Merge branch 'master' into 8289230-move-Platform-classes-out-of-os-xxx-hpp
>  - @coleenp comments
>  - fixed comments
>  - fixed windows
>  - Moved PlatformMutex/PlatformMonitor
>  - move-PlatformParker-out-of-os-xxx-hpp
>  - Moved ThreadCrashProtection

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

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

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

From shade at openjdk.org  Mon Jul  4 07:42:49 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 4 Jul 2022 07:42:49 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v4]
In-Reply-To: <kawmCfep4sR3hXJ6_gaqYe5CnW1_tDjCxJ6aQpwcf5s=.95fc5e59-68b8-4c68-82fc-542c17f5189d@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
 <kawmCfep4sR3hXJ6_gaqYe5CnW1_tDjCxJ6aQpwcf5s=.95fc5e59-68b8-4c68-82fc-542c17f5189d@github.com>
Message-ID: <NGy35oXlq_iZ0rDhOAapl6X5POXjwbfAspc50ei9K_Q=.b42fea06-2901-4eb8-8991-48ee36ef1cdf@github.com>

On Thu, 30 Jun 2022 19:42:42 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated.
>> 
>> Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>
> Zhengyu Gu 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 10 additional commits since the last revision:
> 
>  - Aleksey's comment
>  - Merge branch 'master' into JDK-8287805-evac-updt-closures
>  - v1
>  - Remove unused impl
>  - Review feedback
>  - Merge branch 'master' into JDK-8287805-evac-updt-closures
>  - 8287805: Shenandoah: consolidate evacuate-update-root closures
>  - Merge branch 'master' into consolidate_evac_root_closures
>  - v0
>  - v0

Looks fine, with minor nits.

src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp line 145:

> 143: 
> 144:   Thread* thr = stable_thread ? _thread : Thread::current();
> 145:   assert(thr == Thread::current(), "Wrong thread");

I think we can move these lines down to the only use in this thread. This would keep `Thread::current()` out of the hotpath.

src/hotspot/share/gc/shenandoah/shenandoahClosures.inline.hpp line 148:

> 146: 
> 147:   T o = RawAccess<>::oop_load(p);
> 148:   if (! CompressedOops::is_null(o)) {

Redundant whitespace?

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

Marked as reviewed by shade (Reviewer).

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

From rkennke at openjdk.org  Mon Jul  4 15:46:27 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 4 Jul 2022 15:46:27 GMT
Subject: RFR: Young refproc test
In-Reply-To: <i1Ut07L-v1U4vwWgr7EDrCXV07dsYIt2FYugnUu_9qs=.f869cf09-f41f-4081-bfdb-db95fd4884fc@github.com>
References: <i1Ut07L-v1U4vwWgr7EDrCXV07dsYIt2FYugnUu_9qs=.f869cf09-f41f-4081-bfdb-db95fd4884fc@github.com>
Message-ID: <lHNDmF8UMC6lIr4rC6BS5gyAGzpWNQi6AtU69SEtzM0=.7f608cff-2098-4a7f-bed6-2d24c3be8e31@github.com>

On Thu, 20 May 2021 20:31:38 GMT, wadehenn <duke at openjdk.org> wrote:

> Young refproc test

Owner of PR is no longer an active contributor.

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

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

From rkennke at openjdk.org  Mon Jul  4 15:46:28 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 4 Jul 2022 15:46:28 GMT
Subject: Withdrawn: Young refproc test
In-Reply-To: <i1Ut07L-v1U4vwWgr7EDrCXV07dsYIt2FYugnUu_9qs=.f869cf09-f41f-4081-bfdb-db95fd4884fc@github.com>
References: <i1Ut07L-v1U4vwWgr7EDrCXV07dsYIt2FYugnUu_9qs=.f869cf09-f41f-4081-bfdb-db95fd4884fc@github.com>
Message-ID: <JksgV73iQ1Fwk3iWSW9X6x8WRSyrBE_KpVd1qsoqQak=.3c0245a6-5ccb-4ee0-b63b-3521e61e3fb1@github.com>

On Thu, 20 May 2021 20:31:38 GMT, wadehenn <duke at openjdk.org> wrote:

> Young refproc test

This pull request has been closed without being integrated.

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

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

From wkemper at openjdk.org  Tue Jul  5 17:00:26 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 5 Jul 2022 17:00:26 GMT
Subject: RFR: Coalesce and fill old, pinned regions after old gen final mark
Message-ID: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>

Pinned regions were not being coalesced and filled. This fixes a crash observed with the specjbb 2015 benchmark.

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

Commit messages:
 - remove TODO comment
 - Coalesce and fill old, pinned regions after old gen final mark

Changes: https://git.openjdk.org/shenandoah/pull/149/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=149&range=00
  Stats: 13 lines in 1 file changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/149.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/149/head:pull/149

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

From duke at openjdk.org  Tue Jul  5 17:02:30 2022
From: duke at openjdk.org (Joshua Cao)
Date: Tue, 5 Jul 2022 17:02:30 GMT
Subject: RFR: cli options for young/old ShenandoahMinFreeThreshold
Message-ID: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>

We currently can set only a single `ShenandoahMinFreeThreshold`, which will run a GC cycle if an allocation space fills up to a certain capacity. This PR allows us to specify separate thresholds for young and old generations.

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

Commit messages:
 - cli options for young/old ShenandoahMinFreeThreshold

Changes: https://git.openjdk.org/shenandoah/pull/150/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=150&range=00
  Stats: 20 lines in 6 files changed: 17 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/shenandoah/pull/150.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/150/head:pull/150

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

From ysr at openjdk.org  Tue Jul  5 20:37:08 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Jul 2022 20:37:08 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <-R1As5DnUiMKmIJm7WumAn7qXVGt8qgnKL9-bJHlNpI=.0c875cfa-52c8-4ac0-901d-fdec6302df45@github.com>

On Tue, 5 Jul 2022 16:54:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Pinned regions were not being coalesced and filled. This fixes a crash observed with the specjbb 2015 benchmark.

Other than the comment I left inline, the change looks good; great catch finding the bug!

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 215:

> 213:         region->begin_preemptible_coalesce_and_fill();
> 214:         candidates[cand_idx]._region = region;
> 215:         candidates[cand_idx]._garbage = 0;

Newbie question:

Assume that the object gets unpinned prior to the next marking, and assume hypothetically that the region in question had mostly garbage (let's pick 99% garbage for the sake of argument). At region unpinning, do we sort it into the right position of the garbage first list after recomputing its garbage field?

In other words, I am wondering if we make the `_garbage` field indicate the correct value, but skip adding a pinned region to the collection set when the collection set is built? It looks like the protocol for meaning of the state `_cset_pinned`already accounts for regions being in the collection set while being pinned, so won't that protocol handle this already without having to sort pinned regions to the bottom of the garbage-first list or avoiding adding them to the collection set?

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

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

From wkemper at openjdk.org  Wed Jul  6 00:33:08 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Jul 2022 00:33:08 GMT
Subject: RFR: cli options for young/old ShenandoahMinFreeThreshold
In-Reply-To: <iPaw4V-T1ZPOAThxEMEdkIP6vIV7QQ_CiHTZ-Nf6UaQ=.bbbb446c-34ff-4a5d-91c6-decc7d37a6a1@github.com>
References: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
 <iPaw4V-T1ZPOAThxEMEdkIP6vIV7QQ_CiHTZ-Nf6UaQ=.bbbb446c-34ff-4a5d-91c6-decc7d37a6a1@github.com>
Message-ID: <-2w2LvPgfmvLbTpigVBnsO7gzYKMpII_HE8ZdwWIgSI=.fa43fc08-4d96-44fc-b87b-728346f57c59@github.com>

On Wed, 6 Jul 2022 00:20:14 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> We currently can set only a single `ShenandoahMinFreeThreshold`, which will run a GC cycle if an allocation space fills up to a certain capacity. This PR allows us to specify separate thresholds for young and old generations.
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 122:
> 
>> 120:   product(uintx, ShenandoahOldMinFreeThreshold, 5, EXPERIMENTAL,            \
>> 121:           "Percentage of free heap memory below which most heuristics "     \
>> 122:           "old generation trigger collection independent of other   "       \
> 
> "Percentage of free old generation memory below which most heuristics will trigger its collection independent of other ..."
> 
> Similarly, I'd modify the documentation of "ShenandoahMinFreeThreshold" to state:
> "Percentage of free heap memory (or young generation memory, in
>  generational mode) below which most heuristics trigger its collection independent of ..."
> 
> ASIDE: I was thinking that these may be worth making "manageable" in the future, but I realize now that there is not precedent for that, e.g. in the case of InitiatingHeapOccupancyPercent. I do wonder why not though, since it can allow for some flexibility and external dynamic adaptation of the VM's settings.

I agree with the suggestions for the documentation changes.

The `SoftMaxHeapSize` is "manageable" and that is a factor when checking these thresholds. However, the soft capacity cannot be directly configured for each generation (it is calculated based on `NewSize`, `NewRatio`).

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

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

From kdnilsen at openjdk.org  Tue Jul  5 23:58:14 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 5 Jul 2022 23:58:14 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <zsmBcgq4JVrYf9WYVyyHYXbsosWMU5nptg5UVufyLWg=.c38aa0e1-5947-4fa4-9f8b-860d105edb4e@github.com>

On Tue, 5 Jul 2022 16:54:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Pinned regions were not being coalesced and filled. This fixes a crash observed with the specjbb 2015 benchmark.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 217:

> 215:         candidates[cand_idx]._garbage = 0;
> 216:         cand_idx++;
> 217:       }

Even when sorted to the end of the candidate list, it is still possible that the region might be selected as part of a mixed evacuation.  What's to prevent that from happening?  Also, as I contemplate this scenario, what will happen if an old-gen region is not pinned "now", but becomes pinned before it is included into the mixed-evacuation collection set?  Do we handle that case properly?

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

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

From wkemper at openjdk.org  Wed Jul  6 00:28:58 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Jul 2022 00:28:58 GMT
Subject: RFR: Windows compiler does not support variable length arrays [v2]
In-Reply-To: <txtu9xaJlEfmB7_Z-N3gUuaXL9CGuR_Mol3GwENEQBo=.b2275f84-950c-448c-9ed7-2a8b7f9e44de@github.com>
References: <txtu9xaJlEfmB7_Z-N3gUuaXL9CGuR_Mol3GwENEQBo=.b2275f84-950c-448c-9ed7-2a8b7f9e44de@github.com>
Message-ID: <jHYGPiMeLzYItNOtem-uvLMAr_ELmaQj6iK0ZBeFcZI=.e341b0f1-d194-42ad-8993-5b201efe14eb@github.com>

> Windows compiler does not support variable length arrays

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

  Avoid narrowing conversion

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/151/files
  - new: https://git.openjdk.org/shenandoah/pull/151/files/e56738e7..a14bc52f

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

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

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

From ysr at openjdk.org  Tue Jul  5 23:23:46 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Jul 2022 23:23:46 GMT
Subject: RFR: Windows compiler does not support variable length arrays
In-Reply-To: <txtu9xaJlEfmB7_Z-N3gUuaXL9CGuR_Mol3GwENEQBo=.b2275f84-950c-448c-9ed7-2a8b7f9e44de@github.com>
References: <txtu9xaJlEfmB7_Z-N3gUuaXL9CGuR_Mol3GwENEQBo=.b2275f84-950c-448c-9ed7-2a8b7f9e44de@github.com>
Message-ID: <4YsBP8vKeR7xU40k03EUm0OkkHfrY_jNo82Hay1VvpI=.8bb9997e-5b0e-488f-b580-584b77349b60@github.com>

On Tue, 5 Jul 2022 22:18:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Windows compiler does not support variable length arrays

LGTM

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

Marked as reviewed by ysr (no project role).

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

From ysr at openjdk.org  Tue Jul  5 22:40:38 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Jul 2022 22:40:38 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <H5jrNXEk1ppzJGr2DzNDrbX99LmmmVA4SN3T2-V51J4=.31e4faeb-8875-4966-99d4-781528b277b4@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <-R1As5DnUiMKmIJm7WumAn7qXVGt8qgnKL9-bJHlNpI=.0c875cfa-52c8-4ac0-901d-fdec6302df45@github.com>
 <H5jrNXEk1ppzJGr2DzNDrbX99LmmmVA4SN3T2-V51J4=.31e4faeb-8875-4966-99d4-781528b277b4@github.com>
Message-ID: <3VXnr9BR6ZXGkSqIPU3yQsPD_ztOAZcAtqAhKtVazws=.d976e2bb-91a5-4238-a7ea-971ccb2a0d8d@github.com>

On Tue, 5 Jul 2022 22:16:22 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 215:
>> 
>>> 213:         region->begin_preemptible_coalesce_and_fill();
>>> 214:         candidates[cand_idx]._region = region;
>>> 215:         candidates[cand_idx]._garbage = 0;
>> 
>> Newbie question:
>> 
>> Assume that the object gets unpinned prior to the next marking, and assume hypothetically that the region in question had mostly garbage (let's pick 99% garbage for the sake of argument). At region unpinning, do we sort it into the right position of the garbage first list after recomputing its garbage field?
>> 
>> In other words, I am wondering if we make the `_garbage` field indicate the correct value, but skip adding a pinned region to the collection set when the collection set is built? It looks like the protocol for meaning of the state `_cset_pinned`already accounts for regions being in the collection set while being pinned, so won't that protocol handle this already without having to sort pinned regions to the bottom of the garbage-first list or avoiding adding them to the collection set?
>
> Those are good questions and I thought about letting the pinned region sort naturally on the amount of actual garbage, but I rejected that for two reasons:
> * Shenandoah only updates the pin/unpinned status during a collection cycle. Once we have "candidates" for mixed collection, we won't run another old cycle before mixed collections are complete. This behavior could be changed, but it would be a much bigger change.
> * It's critical that we fill in the dead objects for regions that are not candidates for mixed collections. The remembered set scan will use the mark bit map to avoid dead objects only _while_ there are mixed collection candidates. We could make a change to fill dead objects when pinned regions are rejected from the mixed collection set, but that would add complexity to the mixed collection cycle. Sorting the pinned regions as though they had no garbage lumps them in nicely with other regions that need to be filled.

Re first bullet: fair enough; one can perhaps revisit later, in the fullness of time, to see if the collection set can be more dynamic even in the presence of pinning -- which might arguably help certain adversarial pinning scenarios.

Re second bullet, I didn't realize that for old regions in the (mixed) collection set we run a special scanning protocol that examines live objects only. Why make the distinction between members of the collection set vs those not in the collection set? I might have either always used the liveness information (whenever valid and available) for all regions, or (my preference) never do that and always use the fillers for dead objects which latter would therefore never produce cross-generation pointers (on account of being primitive arrays). May be there are advantages to making this distinction that I am missing.

If not already documented somewhere in the RS scanning code, this might be worth documenting, may be?

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

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

From ysr at openjdk.org  Wed Jul  6 00:43:00 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 6 Jul 2022 00:43:00 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <6VXYMDJv0uc_EljY2GIQjMkAEC9eH4DxGRPHw1YSpP4=.9c7d9878-b052-485a-b3a6-6d1a52ba3327@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <zsmBcgq4JVrYf9WYVyyHYXbsosWMU5nptg5UVufyLWg=.c38aa0e1-5947-4fa4-9f8b-860d105edb4e@github.com>
 <aOL9tWQnjY5nwr1hIxy22xC5QNT8M1WGOkVzJmddAcU=.e0159f9f-313e-4f02-a616-8896a19d5bfb@github.com>
 <6VXYMDJv0uc_EljY2GIQjMkAEC9eH4DxGRPHw1YSpP4=.9c7d9878-b052-485a-b3a6-6d1a52ba3327@github.com>
Message-ID: <SRqV0m9O5eyAaSidf4kZugKiB5EXfx8hPJu6ut_ix88=.2df9b7d2-5073-417a-ac66-9b6d330da71b@github.com>

On Wed, 6 Jul 2022 00:19:25 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> If it is selected as a candidate for an old evacuation, access to it will be protected by the mark bitmap (`heap->doing_mixed_evacuations()` will be true).
>> 
>> Hmm, we might not handle that case properly. Independent of the filling dead objects issue, I can see nothing to prevent old regions with a `pin_count() > 0` from being added to a mixed collection (which would be bad for other reasons). I shall convert this PR to draft until we have a solution that handles that scenario. Perhaps we can also address Ramki's concern that regions that become 'unpinned' before the mixed collection _should_ be included.
>
> The root of the issue is that mutator threads change `pin_count`, but only the gc threads transition (or synchronize) the pin count with `pinned` or `unpinned` states.

Modulo yr concerns re the transitions into and out of `_pinned` state, I'd have thought that `_cset_pinned` could be considered the moral equivalent of not being in `_cset`. I'd expect that if an attempt were made to pin an object in a region that is in state `_cset`, the caller (mutator) would be forced to evacuate the object and then pin the destination region before the pinning call returns?

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

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

From wkemper at openjdk.org  Wed Jul  6 00:23:12 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Jul 2022 00:23:12 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <aOL9tWQnjY5nwr1hIxy22xC5QNT8M1WGOkVzJmddAcU=.e0159f9f-313e-4f02-a616-8896a19d5bfb@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <zsmBcgq4JVrYf9WYVyyHYXbsosWMU5nptg5UVufyLWg=.c38aa0e1-5947-4fa4-9f8b-860d105edb4e@github.com>
 <aOL9tWQnjY5nwr1hIxy22xC5QNT8M1WGOkVzJmddAcU=.e0159f9f-313e-4f02-a616-8896a19d5bfb@github.com>
Message-ID: <6VXYMDJv0uc_EljY2GIQjMkAEC9eH4DxGRPHw1YSpP4=.9c7d9878-b052-485a-b3a6-6d1a52ba3327@github.com>

On Wed, 6 Jul 2022 00:18:02 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 217:
>> 
>>> 215:         candidates[cand_idx]._garbage = 0;
>>> 216:         cand_idx++;
>>> 217:       }
>> 
>> Even when sorted to the end of the candidate list, it is still possible that the region might be selected as part of a mixed evacuation.  What's to prevent that from happening?  Also, as I contemplate this scenario, what will happen if an old-gen region is not pinned "now", but becomes pinned before it is included into the mixed-evacuation collection set?  Do we handle that case properly?
>
> If it is selected as a candidate for an old evacuation, access to it will be protected by the mark bitmap (`heap->doing_mixed_evacuations()` will be true).
> 
> Hmm, we might not handle that case properly. Independent of the filling dead objects issue, I can see nothing to prevent old regions with a `pin_count() > 0` from being added to a mixed collection (which would be bad for other reasons). I shall convert this PR to draft until we have a solution that handles that scenario. Perhaps we can also address Ramki's concern that regions that become 'unpinned' before the mixed collection _should_ be included.

The root of the issue is that mutator threads change `pin_count`, but only the gc threads transition (or synchronize) the pin count with `pinned` or `unpinned` states.

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

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

From wkemper at openjdk.org  Wed Jul  6 00:02:14 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Jul 2022 00:02:14 GMT
Subject: RFR: cli options for young/old ShenandoahMinFreeThreshold
In-Reply-To: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
References: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
Message-ID: <Bqwau9UqcQDtSq_Hr9nM5KDaaYJ4oS6EQMJK5SfhjiM=.94a9c64c-9146-4de6-9c60-ba73666b439a@github.com>

On Tue, 5 Jul 2022 16:55:07 GMT, Joshua Cao <duke at openjdk.org> wrote:

> We currently can set only a single `ShenandoahMinFreeThreshold`, which will run a GC cycle if an allocation space fills up to a certain capacity. This PR allows us to specify separate thresholds for young and old generations.

Looks great! Thank you!

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

Marked as reviewed by wkemper (Committer).

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

From ysr at openjdk.org  Tue Jul  5 23:08:18 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Jul 2022 23:08:18 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <_2BZFkWgZs8uX-OshL3K0McQx6QJdsct6-plZBSfe0w=.6b1e6640-dfa3-406f-852a-9086d3e8ff76@github.com>

On Tue, 5 Jul 2022 16:54:43 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Pinned regions were not being coalesced and filled. This fixes a crash observed with the specjbb 2015 benchmark.

Marked as reviewed by ysr (no project role).

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

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

From wkemper at openjdk.org  Tue Jul  5 23:23:45 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 5 Jul 2022 23:23:45 GMT
Subject: RFR: Windows compiler does not support variable length arrays
Message-ID: <txtu9xaJlEfmB7_Z-N3gUuaXL9CGuR_Mol3GwENEQBo=.b2275f84-950c-448c-9ed7-2a8b7f9e44de@github.com>

Windows compiler does not support variable length arrays

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

Commit messages:
 - Windows compiler does not support variable length arrays

Changes: https://git.openjdk.org/shenandoah/pull/151/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=151&range=00
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/shenandoah/pull/151.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/151/head:pull/151

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

From wkemper at openjdk.org  Tue Jul  5 23:00:20 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 5 Jul 2022 23:00:20 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <3VXnr9BR6ZXGkSqIPU3yQsPD_ztOAZcAtqAhKtVazws=.d976e2bb-91a5-4238-a7ea-971ccb2a0d8d@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <-R1As5DnUiMKmIJm7WumAn7qXVGt8qgnKL9-bJHlNpI=.0c875cfa-52c8-4ac0-901d-fdec6302df45@github.com>
 <H5jrNXEk1ppzJGr2DzNDrbX99LmmmVA4SN3T2-V51J4=.31e4faeb-8875-4966-99d4-781528b277b4@github.com>
 <3VXnr9BR6ZXGkSqIPU3yQsPD_ztOAZcAtqAhKtVazws=.d976e2bb-91a5-4238-a7ea-971ccb2a0d8d@github.com>
Message-ID: <eOR2gabPpiJQWe3ZfcQrgcdjgU-hzMYb2gJNDi3xcGY=.ca2ebcc4-276a-4245-9e3f-b1e10fc46f5f@github.com>

On Tue, 5 Jul 2022 22:37:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Those are good questions and I thought about letting the pinned region sort naturally on the amount of actual garbage, but I rejected that for two reasons:
>> * Shenandoah only updates the pin/unpinned status during a collection cycle. Once we have "candidates" for mixed collection, we won't run another old cycle before mixed collections are complete. This behavior could be changed, but it would be a much bigger change.
>> * It's critical that we fill in the dead objects for regions that are not candidates for mixed collections. The remembered set scan will use the mark bit map to avoid dead objects only _while_ there are mixed collection candidates. We could make a change to fill dead objects when pinned regions are rejected from the mixed collection set, but that would add complexity to the mixed collection cycle. Sorting the pinned regions as though they had no garbage lumps them in nicely with other regions that need to be filled.
>
> Re first bullet: fair enough; one can perhaps revisit later, in the fullness of time, to see if the collection set can be more dynamic even in the presence of pinning -- which might arguably help certain adversarial pinning scenarios.
> 
> Re second bullet, I didn't realize that for old regions in the (mixed) collection set we run a special scanning protocol that examines live objects only. Why make the distinction between members of the collection set vs those not in the collection set? I might have either always used the liveness information (whenever valid and available) for all regions, or (my preference) never do that and always use the fillers for dead objects which latter would therefore never produce cross-generation pointers (on account of being primitive arrays). May be there are advantages to making this distinction that I am missing.
> 
> If not already documented somewhere in the RS scanning code, this might be worth documenting, may be?

I think I explained the remembered set scanning protocol poorly. It doesn't distinguish regions that are in the collection set. Rather, if there are mixed evacuations pending it "knows" the mark bitmap data is stable (i.e., marking of old regions is complete). The rset scan must use the bitmap here precisely because it _does not_ fill dead objects in old regions which are candidates for the mixed collection set. It expects these regions to eventually be reclaimed, so the effort of filling in the garbage would be wasted. Certainly, the code would be simpler if we always used the mark bitmap or always filled dead objects, but this hybrid approach has performance advantages:
 * It doesn't require a secondary bitmap during concurrent marking of old.
 * We don't fill in dead objects for regions that are destined to be reclaimed.
 
There is some discussion in [this comment from shenandoahScanRemembered]( https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp#L501).

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

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

From ysr at openjdk.org  Tue Jul  5 23:08:19 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Tue, 5 Jul 2022 23:08:19 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <eOR2gabPpiJQWe3ZfcQrgcdjgU-hzMYb2gJNDi3xcGY=.ca2ebcc4-276a-4245-9e3f-b1e10fc46f5f@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <-R1As5DnUiMKmIJm7WumAn7qXVGt8qgnKL9-bJHlNpI=.0c875cfa-52c8-4ac0-901d-fdec6302df45@github.com>
 <H5jrNXEk1ppzJGr2DzNDrbX99LmmmVA4SN3T2-V51J4=.31e4faeb-8875-4966-99d4-781528b277b4@github.com>
 <3VXnr9BR6ZXGkSqIPU3yQsPD_ztOAZcAtqAhKtVazws=.d976e2bb-91a5-4238-a7ea-971ccb2a0d8d@github.com>
 <eOR2gabPpiJQWe3ZfcQrgcdjgU-hzMYb2gJNDi3xcGY=.ca2ebcc4-276a-4245-9e3f-b1e10fc46f5f@github.com>
Message-ID: <2mGbAxoPKw6JjFB-bE3sbaKD5nlAB3CJGyIWPFvZYj0=.41326e93-e8ae-4327-92a3-da45765d4104@github.com>

On Tue, 5 Jul 2022 22:58:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Re first bullet: fair enough; one can perhaps revisit later, in the fullness of time, to see if the collection set can be more dynamic even in the presence of pinning -- which might arguably help certain adversarial pinning scenarios.
>> 
>> Re second bullet, I didn't realize that for old regions in the (mixed) collection set we run a special scanning protocol that examines live objects only. Why make the distinction between members of the collection set vs those not in the collection set? I might have either always used the liveness information (whenever valid and available) for all regions, or (my preference) never do that and always use the fillers for dead objects which latter would therefore never produce cross-generation pointers (on account of being primitive arrays). May be there are advantages to making this distinction that I am missing.
>> 
>> If not already documented somewhere in the RS scanning code, this might be worth documenting, may be?
>
> I think I explained the remembered set scanning protocol poorly. It doesn't distinguish regions that are in the collection set. Rather, if there are mixed evacuations pending it "knows" the mark bitmap data is stable (i.e., marking of old regions is complete). The rset scan must use the bitmap here precisely because it _does not_ fill dead objects in old regions which are candidates for the mixed collection set. It expects these regions to eventually be reclaimed, so the effort of filling in the garbage would be wasted. Certainly, the code would be simpler if we always used the mark bitmap or always filled dead objects, but this hybrid approach has performance advantages:
>  * It doesn't require a secondary bitmap during concurrent marking of old.
>  * We don't fill in dead objects for regions that are destined to be reclaimed.
>  
> There is some discussion in [this comment from shenandoahScanRemembered]( https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp#L501).

OK thanks for the patient explanation! The performance advantage of the hybrid scheme that you point out seems plausible for regions that are dominated by garbage.

The change looks good to me; reviewed!

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

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

From wkemper at openjdk.org  Wed Jul  6 00:23:12 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Jul 2022 00:23:12 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <zsmBcgq4JVrYf9WYVyyHYXbsosWMU5nptg5UVufyLWg=.c38aa0e1-5947-4fa4-9f8b-860d105edb4e@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <zsmBcgq4JVrYf9WYVyyHYXbsosWMU5nptg5UVufyLWg=.c38aa0e1-5947-4fa4-9f8b-860d105edb4e@github.com>
Message-ID: <aOL9tWQnjY5nwr1hIxy22xC5QNT8M1WGOkVzJmddAcU=.e0159f9f-313e-4f02-a616-8896a19d5bfb@github.com>

On Tue, 5 Jul 2022 17:56:49 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Pinned regions were not being coalesced and filled. This fixes a crash observed with the specjbb 2015 benchmark.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 217:
> 
>> 215:         candidates[cand_idx]._garbage = 0;
>> 216:         cand_idx++;
>> 217:       }
> 
> Even when sorted to the end of the candidate list, it is still possible that the region might be selected as part of a mixed evacuation.  What's to prevent that from happening?  Also, as I contemplate this scenario, what will happen if an old-gen region is not pinned "now", but becomes pinned before it is included into the mixed-evacuation collection set?  Do we handle that case properly?

If it is selected as a candidate for an old evacuation, access to it will be protected by the mark bitmap (`heap->doing_mixed_evacuations()` will be true).

Hmm, we might not handle that case properly. Independent of the filling dead objects issue, I can see nothing to prevent old regions with a `pin_count() > 0` from being added to a mixed collection (which would be bad for other reasons). I shall convert this PR to draft until we have a solution that handles that scenario. Perhaps we can also address Ramki's concern that regions that become 'unpinned' before the mixed collection _should_ be included.

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

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

From ysr at openjdk.org  Wed Jul  6 00:24:15 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 6 Jul 2022 00:24:15 GMT
Subject: RFR: cli options for young/old ShenandoahMinFreeThreshold
In-Reply-To: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
References: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
Message-ID: <iPaw4V-T1ZPOAThxEMEdkIP6vIV7QQ_CiHTZ-Nf6UaQ=.bbbb446c-34ff-4a5d-91c6-decc7d37a6a1@github.com>

On Tue, 5 Jul 2022 16:55:07 GMT, Joshua Cao <duke at openjdk.org> wrote:

> We currently can set only a single `ShenandoahMinFreeThreshold`, which will run a GC cycle if an allocation space fills up to a certain capacity. This PR allows us to specify separate thresholds for young and old generations.

Minor documentation suggestions. Otherwise looks good to me. Reviewed!

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

> 120:   product(uintx, ShenandoahOldMinFreeThreshold, 5, EXPERIMENTAL,            \
> 121:           "Percentage of free heap memory below which most heuristics "     \
> 122:           "old generation trigger collection independent of other   "       \

"Percentage of free old generation memory below which most heuristics will trigger its collection independent of other ..."

Similarly, I'd modify the documentation of "ShenandoahMinFreeThreshold" to state:
"Percentage of free heap memory (or young generation memory, in
 generational mode) below which most heuristics trigger its collection independent of ..."

ASIDE: I was thinking that these may be worth making "manageable" in the future, but I realize now that there is not precedent for that, e.g. in the case of InitiatingHeapOccupancyPercent. I do wonder why not though, since it can allow for some flexibility and external dynamic adaptation of the VM's settings.

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

Marked as reviewed by ysr (no project role).

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

From wkemper at openjdk.org  Tue Jul  5 22:20:01 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 5 Jul 2022 22:20:01 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <-R1As5DnUiMKmIJm7WumAn7qXVGt8qgnKL9-bJHlNpI=.0c875cfa-52c8-4ac0-901d-fdec6302df45@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <-R1As5DnUiMKmIJm7WumAn7qXVGt8qgnKL9-bJHlNpI=.0c875cfa-52c8-4ac0-901d-fdec6302df45@github.com>
Message-ID: <H5jrNXEk1ppzJGr2DzNDrbX99LmmmVA4SN3T2-V51J4=.31e4faeb-8875-4966-99d4-781528b277b4@github.com>

On Tue, 5 Jul 2022 20:31:03 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Pinned regions were not being coalesced and filled. This fixes a crash observed with the specjbb 2015 benchmark.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 215:
> 
>> 213:         region->begin_preemptible_coalesce_and_fill();
>> 214:         candidates[cand_idx]._region = region;
>> 215:         candidates[cand_idx]._garbage = 0;
> 
> Newbie question:
> 
> Assume that the object gets unpinned prior to the next marking, and assume hypothetically that the region in question had mostly garbage (let's pick 99% garbage for the sake of argument). At region unpinning, do we sort it into the right position of the garbage first list after recomputing its garbage field?
> 
> In other words, I am wondering if we make the `_garbage` field indicate the correct value, but skip adding a pinned region to the collection set when the collection set is built? It looks like the protocol for meaning of the state `_cset_pinned`already accounts for regions being in the collection set while being pinned, so won't that protocol handle this already without having to sort pinned regions to the bottom of the garbage-first list or avoiding adding them to the collection set?

Those are good questions and I thought about letting the pinned region sort naturally on the amount of actual garbage, but I rejected that for two reasons:
* Shenandoah only updates the pin/unpinned status during a collection cycle. Once we have "candidates" for mixed collection, we won't run another old cycle before mixed collections are complete. This behavior could be changed, but it would be a much bigger change.
* It's critical that we fill in the dead objects for regions that are not candidates for mixed collections. The remembered set scan will use the mark bit map to avoid dead objects only _while_ there are mixed collection candidates. We could make a change to fill dead objects when pinned regions are rejected from the mixed collection set, but that would add complexity to the mixed collection cycle. Sorting the pinned regions as though they had no garbage lumps them in nicely with other regions that need to be filled.

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

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

From duke at openjdk.org  Wed Jul  6 03:28:56 2022
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 6 Jul 2022 03:28:56 GMT
Subject: RFR: cli options for young/old ShenandoahMinFreeThreshold [v2]
In-Reply-To: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
References: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
Message-ID: <XOOLCsimAAZN__Kwi_1UeT1UuEISYpKVOQgiH9ciyZE=.16a0dcd2-cf6b-4eb9-aa7c-56f573037453@github.com>

> We currently can set only a single `ShenandoahMinFreeThreshold`, which will run a GC cycle if an allocation space fills up to a certain capacity. This PR allows us to specify separate thresholds for young and old generations.

Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:

  Update docs for Shenandoah minimum thresholds

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/150/files
  - new: https://git.openjdk.org/shenandoah/pull/150/files/92adffa0..2f7f9eb0

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

  Stats: 9 lines in 1 file changed: 1 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/shenandoah/pull/150.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/150/head:pull/150

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

From kdnilsen at openjdk.org  Wed Jul  6 17:32:21 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Jul 2022 17:32:21 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <jTyAc1rHB0OBFbWtATbLrTC8icj7qGiOP-eKhiM-q4g=.b403ed06-d877-4df2-bc6f-902fb03019ee@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <zsmBcgq4JVrYf9WYVyyHYXbsosWMU5nptg5UVufyLWg=.c38aa0e1-5947-4fa4-9f8b-860d105edb4e@github.com>
 <aOL9tWQnjY5nwr1hIxy22xC5QNT8M1WGOkVzJmddAcU=.e0159f9f-313e-4f02-a616-8896a19d5bfb@github.com>
 <6VXYMDJv0uc_EljY2GIQjMkAEC9eH4DxGRPHw1YSpP4=.9c7d9878-b052-485a-b3a6-6d1a52ba3327@github.com>
 <SRqV0m9O5eyAaSidf4kZugKiB5EXfx8hPJu6ut_ix88=.2df9b7d2-5073-417a-ac66-9b6d330da71b@github.com>
 <XmnCZa03p3sBd-E3-l7jo-qoN9Br8EfbXKm7SmUWrbs=.fb7c239e-45b8-4ecd-9e58-7b20870cc80a@github.com>
 <jTyAc1rHB0OBFbWtATbLrTC8icj7qGiOP-eKhiM-q4g=.b403ed06-d877-4df2-bc6f-902fb03019ee@github.com>
Message-ID: <dj1-bzBMxC9FelWBRRw_OjZLdiccNe1bhj_u4eiLB9M=.dad15f13-7176-42e6-83bf-ee39b2727b09@github.com>

On Wed, 6 Jul 2022 17:27:45 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> I would hope there is some existing code that rejects a region-pin request if the region has already been selected to be in the "cset".  Actually, this probably will never happen because once a region has been selected to be in cset, then the mutator can no longer see the objects residing within that region.  The mutator can only see the to-space replicas of these objects.  So the mutator may try to pin the destination region, but will never try to pin a from-space (cset) region.
>
> @kdnilsen - You're right that the mutator _should_ not be allowed to pin regions in the cset. The load barrier should evacuate the object and the to-space region would be pinned. However, if there is an OOM failure during the evacuation, the mutator will be able to reach the from-space object and pin its region. This scenario is [handled in the degenerated cycle](https://github.com/openjdk/shenandoah/blob/ca939b69f95db2cb8ead9c9459b2d7712909a4b6/src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp#L171):
> 
> 
>         // Before doing that, we need to make sure we never had any cset-pinned
>         // regions. This may happen if allocation failure happened when evacuating
>         // the about-to-be-pinned object, oom-evac protocol left the object in
>         // the collection set, and then the pin reached the cset region. If we continue
>         // the cycle here, we would trash the cset and alive objects in it. To avoid
>         // it, we fail degeneration right away and slide into Full GC to recover.

Good catch.  So we cannot entirely avoid this issue.

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

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

From wkemper at openjdk.org  Wed Jul  6 17:32:21 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Jul 2022 17:32:21 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <XmnCZa03p3sBd-E3-l7jo-qoN9Br8EfbXKm7SmUWrbs=.fb7c239e-45b8-4ecd-9e58-7b20870cc80a@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <zsmBcgq4JVrYf9WYVyyHYXbsosWMU5nptg5UVufyLWg=.c38aa0e1-5947-4fa4-9f8b-860d105edb4e@github.com>
 <aOL9tWQnjY5nwr1hIxy22xC5QNT8M1WGOkVzJmddAcU=.e0159f9f-313e-4f02-a616-8896a19d5bfb@github.com>
 <6VXYMDJv0uc_EljY2GIQjMkAEC9eH4DxGRPHw1YSpP4=.9c7d9878-b052-485a-b3a6-6d1a52ba3327@github.com>
 <SRqV0m9O5eyAaSidf4kZugKiB5EXfx8hPJu6ut_ix88=.2df9b7d2-5073-417a-ac66-9b6d330da71b@github.com>
 <XmnCZa03p3sBd-E3-l7jo-qoN9Br8EfbXKm7SmUWrbs=.fb7c239e-45b8-4ecd-9e58-7b20870cc80a@github.com>
Message-ID: <jTyAc1rHB0OBFbWtATbLrTC8icj7qGiOP-eKhiM-q4g=.b403ed06-d877-4df2-bc6f-902fb03019ee@github.com>

On Wed, 6 Jul 2022 17:13:45 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Modulo yr concerns re the transitions into and out of `_pinned` state, I'd have thought that `_cset_pinned` could be considered the moral equivalent of not being in `_cset`. I'd expect that if an attempt were made to pin an object in a region that is in state `_cset`, the caller (mutator) would be forced to evacuate the object and then pin the destination region before the pinning call returns?
>
> I would hope there is some existing code that rejects a region-pin request if the region has already been selected to be in the "cset".  Actually, this probably will never happen because once a region has been selected to be in cset, then the mutator can no longer see the objects residing within that region.  The mutator can only see the to-space replicas of these objects.  So the mutator may try to pin the destination region, but will never try to pin a from-space (cset) region.

@kdnilsen - You're right that the mutator _should_ not be allowed to pin regions in the cset. The load barrier should evacuate the object and the to-space region would be pinned. However, if there is an OOM failure during the evacuation, the mutator will be able to reach the from-space object and pin its region. This scenario is [handled in the degenerated cycle](https://github.com/openjdk/shenandoah/blob/ca939b69f95db2cb8ead9c9459b2d7712909a4b6/src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp#L171):


        // Before doing that, we need to make sure we never had any cset-pinned
        // regions. This may happen if allocation failure happened when evacuating
        // the about-to-be-pinned object, oom-evac protocol left the object in
        // the collection set, and then the pin reached the cset region. If we continue
        // the cycle here, we would trash the cset and alive objects in it. To avoid
        // it, we fail degeneration right away and slide into Full GC to recover.

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

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

From kdnilsen at openjdk.org  Wed Jul  6 17:17:23 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Jul 2022 17:17:23 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark
In-Reply-To: <SRqV0m9O5eyAaSidf4kZugKiB5EXfx8hPJu6ut_ix88=.2df9b7d2-5073-417a-ac66-9b6d330da71b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <zsmBcgq4JVrYf9WYVyyHYXbsosWMU5nptg5UVufyLWg=.c38aa0e1-5947-4fa4-9f8b-860d105edb4e@github.com>
 <aOL9tWQnjY5nwr1hIxy22xC5QNT8M1WGOkVzJmddAcU=.e0159f9f-313e-4f02-a616-8896a19d5bfb@github.com>
 <6VXYMDJv0uc_EljY2GIQjMkAEC9eH4DxGRPHw1YSpP4=.9c7d9878-b052-485a-b3a6-6d1a52ba3327@github.com>
 <SRqV0m9O5eyAaSidf4kZugKiB5EXfx8hPJu6ut_ix88=.2df9b7d2-5073-417a-ac66-9b6d330da71b@github.com>
Message-ID: <XmnCZa03p3sBd-E3-l7jo-qoN9Br8EfbXKm7SmUWrbs=.fb7c239e-45b8-4ecd-9e58-7b20870cc80a@github.com>

On Wed, 6 Jul 2022 00:40:01 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> The root of the issue is that mutator threads change `pin_count`, but only the gc threads transition (or synchronize) the pin count with `pinned` or `unpinned` states.
>
> Modulo yr concerns re the transitions into and out of `_pinned` state, I'd have thought that `_cset_pinned` could be considered the moral equivalent of not being in `_cset`. I'd expect that if an attempt were made to pin an object in a region that is in state `_cset`, the caller (mutator) would be forced to evacuate the object and then pin the destination region before the pinning call returns?

I would hope there is some existing code that rejects a region-pin request if the region has already been selected to be in the "cset".  Actually, this probably will never happen because once a region has been selected to be in cset, then the mutator can no longer see the objects residing within that region.  The mutator can only see the to-space replicas of these objects.  So the mutator may try to pin the destination region, but will never try to pin a from-space (cset) region.

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

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

From wkemper at openjdk.org  Wed Jul  6 17:18:21 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 6 Jul 2022 17:18:21 GMT
Subject: Integrated: Windows compiler does not support variable length arrays
In-Reply-To: <txtu9xaJlEfmB7_Z-N3gUuaXL9CGuR_Mol3GwENEQBo=.b2275f84-950c-448c-9ed7-2a8b7f9e44de@github.com>
References: <txtu9xaJlEfmB7_Z-N3gUuaXL9CGuR_Mol3GwENEQBo=.b2275f84-950c-448c-9ed7-2a8b7f9e44de@github.com>
Message-ID: <rJShCh3rrIBNUbaoXX-BDZ4Lg8b3OWvAuj8dk__OrNY=.e8d9d1ae-59e0-4547-8586-6d73ebdc87a1@github.com>

On Tue, 5 Jul 2022 22:18:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Windows compiler does not support variable length arrays

This pull request has now been integrated.

Changeset: 09d6ab57
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/09d6ab574ae84ae597948708c31f0d1c5df86830
Stats:     7 lines in 3 files changed: 2 ins; 1 del; 4 mod

Windows compiler does not support variable length arrays

Reviewed-by: ysr, kdnilsen

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

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

From kdnilsen at openjdk.org  Wed Jul  6 17:11:26 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 6 Jul 2022 17:11:26 GMT
Subject: RFR: Windows compiler does not support variable length arrays [v2]
In-Reply-To: <jHYGPiMeLzYItNOtem-uvLMAr_ELmaQj6iK0ZBeFcZI=.e341b0f1-d194-42ad-8993-5b201efe14eb@github.com>
References: <txtu9xaJlEfmB7_Z-N3gUuaXL9CGuR_Mol3GwENEQBo=.b2275f84-950c-448c-9ed7-2a8b7f9e44de@github.com>
 <jHYGPiMeLzYItNOtem-uvLMAr_ELmaQj6iK0ZBeFcZI=.e341b0f1-d194-42ad-8993-5b201efe14eb@github.com>
Message-ID: <-mZsyqhHXCcGLsyg60B6icsFKbV_yhTTOtRMjjZkgWU=.45ab2304-b10d-4e26-b2ec-76140a447167@github.com>

On Wed, 6 Jul 2022 00:28:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Windows compiler does not support variable length arrays
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid narrowing conversion

Marked as reviewed by kdnilsen (Committer).

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

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

From duke at openjdk.org  Wed Jul  6 16:25:58 2022
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 6 Jul 2022 16:25:58 GMT
Subject: Integrated: cli options for young/old ShenandoahMinFreeThreshold
In-Reply-To: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
References: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
Message-ID: <te4nykRW7BFVyUI3FlqRLlayLjq5dvKrZdwrTVh6MLc=.c8da999c-b528-490c-abac-2171e23e8d4f@github.com>

On Tue, 5 Jul 2022 16:55:07 GMT, Joshua Cao <duke at openjdk.org> wrote:

> We currently can set only a single `ShenandoahMinFreeThreshold`, which will run a GC cycle if an allocation space fills up to a certain capacity. This PR allows us to specify separate thresholds for young and old generations.

This pull request has now been integrated.

Changeset: 4de4c3eb
Author:    Joshua Cao <joshcao at amazon.com>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/4de4c3eb5c3713eb5c06be5247f76df37e0dc043
Stats:     25 lines in 6 files changed: 18 ins; 0 del; 7 mod

cli options for young/old ShenandoahMinFreeThreshold

Reviewed-by: wkemper, ysr

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

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

From duke at openjdk.org  Wed Jul  6 03:28:59 2022
From: duke at openjdk.org (Joshua Cao)
Date: Wed, 6 Jul 2022 03:28:59 GMT
Subject: RFR: cli options for young/old ShenandoahMinFreeThreshold [v2]
In-Reply-To: <iPaw4V-T1ZPOAThxEMEdkIP6vIV7QQ_CiHTZ-Nf6UaQ=.bbbb446c-34ff-4a5d-91c6-decc7d37a6a1@github.com>
References: <uFY1NbU1pqWPKT9bMuUw7ghTc-I5jqHSGtLV6fiMR0I=.7210ae8f-d417-4f43-90cf-279483cef0ac@github.com>
 <iPaw4V-T1ZPOAThxEMEdkIP6vIV7QQ_CiHTZ-Nf6UaQ=.bbbb446c-34ff-4a5d-91c6-decc7d37a6a1@github.com>
Message-ID: <9uFWY-_qlbecelSpo7kydo6LzF2UqbxSowQHH7w-KnE=.90133b36-6eed-4104-8e28-fce9cc1b4fab@github.com>

On Wed, 6 Jul 2022 00:20:14 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Joshua Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update docs for Shenandoah minimum thresholds
>
> src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 122:
> 
>> 120:   product(uintx, ShenandoahOldMinFreeThreshold, 5, EXPERIMENTAL,            \
>> 121:           "Percentage of free heap memory below which most heuristics "     \
>> 122:           "old generation trigger collection independent of other   "       \
> 
> "Percentage of free old generation memory below which most heuristics will trigger its collection independent of other ..."
> 
> Similarly, I'd modify the documentation of "ShenandoahMinFreeThreshold" to state:
> "Percentage of free heap memory (or young generation memory, in
>  generational mode) below which most heuristics trigger its collection independent of ..."
> 
> ASIDE: I was thinking that these may be worth making "manageable" in the future, but I realize now that there is not precedent for that, e.g. in the case of InitiatingHeapOccupancyPercent. I do wonder why not though, since it can allow for some flexibility and external dynamic adaptation of the VM's settings.

Updating docs based on @ysramakrishna's suggestions. Its not exactly word for word.

> Percentage of free old generation memory below which most heuristics will trigger its collection independent of other ..

I did not include the `will`.

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

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

From ysr at openjdk.org  Thu Jul  7 14:09:30 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 7 Jul 2022 14:09:30 GMT
Subject: RFR: Balance without cancel [v2]
In-Reply-To: <AV627DHc3T8QDaWkNpR55geXeh0LcDkoCCkw_YXyv48=.6b9430d5-bdd0-427d-9746-497ba47ac667@github.com>
References: <_l1IqN_QrbTy3hsL54uJQe4swcli1hnNlh0pL9HI5Uw=.467c66b0-4b21-4fcf-80de-71b11b1beb73@github.com>
 <AV627DHc3T8QDaWkNpR55geXeh0LcDkoCCkw_YXyv48=.6b9430d5-bdd0-427d-9746-497ba47ac667@github.com>
Message-ID: <7diIv7tKtIFjenxtVYSSfAkT59ZD4j19uuKrD8qFEZE=.81006944-9afb-424f-b06b-fa02f3afd7e2@github.com>

On Tue, 10 May 2022 23:14:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This commit does load balancing on remembered set scanning that happens during concurrent marking and during concurrent updating of references.  Experiments show that the concurrency of remembered set marking is now much closer to the number of concurrent GC threads (generally within 5%) whereas before this commit, the level of concurrency was often less than 1/4 of the number of concurrent GC threads.
>> 
>> An additional fix integrated in this commit is to not scan the entirety of humongous object arrays.  We only scan the portions of these arrays that overlay with dirty cards in the remembered set.
>
> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Enhance logging information
>  - Do not use shared allocation for promotions smaller than PLAB::min_size

Would it make sense to close this draft pull request since the plan seems to be to break this into smaller chunks? Or is there value in keeping it in the draft state for now? Thanks!

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

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

From wkemper at openjdk.org  Thu Jul  7 17:26:43 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 7 Jul 2022 17:26:43 GMT
Subject: RFR: Balance without cancel [v2]
In-Reply-To: <AV627DHc3T8QDaWkNpR55geXeh0LcDkoCCkw_YXyv48=.6b9430d5-bdd0-427d-9746-497ba47ac667@github.com>
References: <_l1IqN_QrbTy3hsL54uJQe4swcli1hnNlh0pL9HI5Uw=.467c66b0-4b21-4fcf-80de-71b11b1beb73@github.com>
 <AV627DHc3T8QDaWkNpR55geXeh0LcDkoCCkw_YXyv48=.6b9430d5-bdd0-427d-9746-497ba47ac667@github.com>
Message-ID: <ztPlA4jlglu2QDI9keawRq-NeiuG9zZ84oXuiJgdhlk=.088ea2e2-e3b1-41dd-8e89-5572be1e9868@github.com>

On Tue, 10 May 2022 23:14:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This commit does load balancing on remembered set scanning that happens during concurrent marking and during concurrent updating of references.  Experiments show that the concurrency of remembered set marking is now much closer to the number of concurrent GC threads (generally within 5%) whereas before this commit, the level of concurrency was often less than 1/4 of the number of concurrent GC threads.
>> 
>> An additional fix integrated in this commit is to not scan the entirety of humongous object arrays.  We only scan the portions of these arrays that overlay with dirty cards in the remembered set.
>
> Kelvin Nilsen has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Enhance logging information
>  - Do not use shared allocation for promotions smaller than PLAB::min_size

I think we should close it.

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

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

From lmesnik at openjdk.org  Fri Jul  8 00:53:43 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 8 Jul 2022 00:53:43 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <dGq1uotyXJlQ3HTcsiMP6dG6n-5Q3lzNG-b8kG29OUU=.523bd006-466d-40e4-8845-51f2768cd226@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

Marked as reviewed by lmesnik (Reviewer).

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

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

From coleenp at openjdk.org  Thu Jul  7 23:30:25 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Jul 2022 23:30:25 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
Message-ID: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>

This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
Tested with tiers1-6.

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

Commit messages:
 - 8271707: migrate tests to use jdk.test.whitebox.WhiteBox

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

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

From dholmes at openjdk.org  Fri Jul  8 06:15:42 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Jul 2022 06:15:42 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

I skimmed the diff and this seems fine.

Are we not going to remove the old WhiteBox at the same time?

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From coleenp at openjdk.org  Fri Jul  8 12:51:42 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 12:51:42 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
 <-l-lc8D0eUr1WpTplIgI8Zz2VDpvUEA_LCkxovQueek=.53c06318-45d5-4637-8fe4-adfcea65b121@github.com>
Message-ID: <Yrfv7H3auoYd296-igfoIn4LX5BpmuGxetYFtRrZzH8=.ea9f5a66-f00b-48d1-a465-0adb83acd4db@github.com>

On Fri, 8 Jul 2022 06:12:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
>> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
>> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
>> Tested with tiers1-6.
>
> I skimmed the diff and this seems fine.
> 
> Are we not going to remove the old WhiteBox at the same time?
> 
> Thanks.

@dholmes-ora We'll remove it with this patch JDK-8275662 and the other obsolete sun.hotspot test classes which will be easier to look at.
Thanks for reviewing.

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

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

From coleenp at openjdk.org  Fri Jul  8 15:58:32 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 15:58:32 GMT
Subject: Integrated: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <7OYMQYFZ2rIDV87GtSdBA2jbeOcjjsCVQq_GWOPfEoU=.846e9278-06ec-4428-83e9-d2a883a04e5f@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

This pull request has now been integrated.

Changeset: e7795851
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7795851d2e02389e63950fef939084b18ec4bfb
Stats:     2994 lines in 984 files changed: 6 ins; 0 del; 2988 mod

8271707: migrate tests to use jdk.test.whitebox.WhiteBox

Reviewed-by: lmesnik, dholmes

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

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

From coleenp at openjdk.org  Fri Jul  8 15:58:31 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 8 Jul 2022 15:58:31 GMT
Subject: RFR: 8271707: migrate tests to use jdk.test.whitebox.WhiteBox
In-Reply-To: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
References: <uv8QE7t3dTnuSnYUayEXl15jJ1DVxKew3jTpYyW00ng=.fa95b08a-c2bc-4d0e-a74f-674c3e89a4a9@github.com>
Message-ID: <2mTLTyDQH8b2csvKDlgLMlfVhSm7JJXvFcuNMeqnYO0=.ab170919-9813-40be-a097-43671975d984@github.com>

On Thu, 7 Jul 2022 20:43:09 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change uses sed to change sun.hotspot.WhiteBox to jdk.test.whitebox.Whitebox, and sun/hotspot/Whitebox similarly.  Due to indirect inclusions of some of the test libraries, changing a few wasn't a reliable option, and I need the new one for a different change I was looking at.
> The non-sed changes are for jdk/test/whitebox/WhiteBox to add some code for GC that was only added to the sun version.
> Also, the ClassFileInstaller has a label for sun.hotspot.Whitebox so that didn't change with the edit.
> Tested with tiers1-6.

Thanks Leonid!

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

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

From andrew at openjdk.org  Sun Jul 10 17:43:42 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Sun, 10 Jul 2022 17:43:42 GMT
Subject: RFR: 8290049: Committers should be able to review for Shenandoah 8u
Message-ID: <dz3hSAWqwPVfDHfLJgYhCzgkdEEgo6I3HAezQhLlMUU=.1b447200-1dba-4b4e-88c6-ccb13922f4ed@github.com>

According to @rkennke, "it is sufficient to be a Committer in order to officially review Shenandoah PRs"

We should change the `jcheck` configuration to reflect this.

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

Commit messages:
 - 8290049: Committers should be able to review for Shenandoah 8u

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/4

From tschatzl at openjdk.org  Mon Jul 11 07:48:00 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 11 Jul 2022 07:48:00 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests
Message-ID: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>

Hi all,

  can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?

As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
* duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
* adding additional `@requires`
* removing it in tests where it is not actually required

Testing: gha, running tests

Thanks,
  Thomas

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

Commit messages:
 - Merge branch 'master' into 8290023-remove-use-of-ignoreunrecognized
 - fix test
 - Merge fixes
 - Initial batch

Changes: https://git.openjdk.org/jdk/pull/9443/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9443&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290023
  Stats: 258 lines in 13 files changed: 189 ins; 26 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/9443.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9443/head:pull/9443

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

From ayang at openjdk.org  Mon Jul 11 10:08:47 2022
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Mon, 11 Jul 2022 10:08:47 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests
In-Reply-To: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
Message-ID: <ujdbyJrXWguSAIfoObn6DFdvgQlB4oU79uRoq_KuX9E=.d10f3df1-cf50-4eb2-af8d-34f6ea3fa89c@github.com>

On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
> 
> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
> * adding additional `@requires`
> * removing it in tests where it is not actually required
> 
> Testing: gha, running tests
> 
> Thanks,
>   Thomas

Marked as reviewed by ayang (Reviewer).

test/hotspot/jtreg/gc/metaspace/TestMetaspacePerfCounters.java line 153:

> 151:  *          java.management/sun.management
> 152:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
> 153:  * @run main/othervm -XX:+UsePerfData -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC gc.metaspace.TestMetaspacePerfCounters

It's unclear to me why `-XX:+UnlockExperimentalVMOptions` is needed in this file.

test/hotspot/jtreg/gc/metaspace/TestPerfCountersAndMemoryPools.java line 58:

> 56:  *          jdk.internal.jvmstat/sun.jvmstat.monitor
> 57:  * @run main/othervm -Xlog:class+load,class+unload=trace -XX:+UseSerialGC -XX:+UsePerfData -Xint gc.metaspace.TestPerfCountersAndMemoryPools
> 58:  * @run main/othervm -Xlog:class+load,class+unload=trace -XX:+UseSerialGC -XX:+UsePerfData -Xint gc.metaspace.TestPerfCountersAndMemoryPools

These two lines are identical; is this intended?

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

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

From lkorinth at openjdk.org  Mon Jul 11 12:55:38 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 11 Jul 2022 12:55:38 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests
In-Reply-To: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
Message-ID: <hdFVSJjktiU_s3xPTEdqpFKiBDhqUymFBx1ENXrEYNw=.bfcfd6e2-1f7f-4761-9530-ff98ac3c6adf@github.com>

On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
> 
> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
> * adding additional `@requires`
> * removing it in tests where it is not actually required
> 
> Testing: gha, running tests
> 
> Thanks,
>   Thomas

I have looked through the change, and it looks mostly good to me. TestEagerReclaimHumongousRegionsClearMarkBits after the change only runs in debug builds, is that made on purpose?

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

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

From tschatzl at openjdk.org  Mon Jul 11 13:08:43 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Mon, 11 Jul 2022 13:08:43 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests
In-Reply-To: <hdFVSJjktiU_s3xPTEdqpFKiBDhqUymFBx1ENXrEYNw=.bfcfd6e2-1f7f-4761-9530-ff98ac3c6adf@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
 <hdFVSJjktiU_s3xPTEdqpFKiBDhqUymFBx1ENXrEYNw=.bfcfd6e2-1f7f-4761-9530-ff98ac3c6adf@github.com>
Message-ID: <5dUXqi03xrDnZkyF4IKnhyAwSIJupNZkdoEBiwGqSYk=.3804b8b2-5cc0-452c-a495-5803fff4e2a5@github.com>

On Mon, 11 Jul 2022 12:52:17 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> I have looked through the change, and it looks mostly good to me. TestEagerReclaimHumongousRegionsClearMarkBits after the change only runs in debug builds, is that made on purpose?

TestEagerReclaimHumongousRegionsClearMarkBits is not going to crash due to bitmap verification error in product mode because that verification is debug mode only. At most it could crash due to other reasons, but I do not think it is worth running the test for random suspicion that something might be wrong that other tests would highly likely also pick up.

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

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

From rkennke at openjdk.org  Mon Jul 11 13:25:08 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 11 Jul 2022 13:25:08 GMT
Subject: RFR: 8290049: Committers should be able to review for Shenandoah
 8u
In-Reply-To: <dz3hSAWqwPVfDHfLJgYhCzgkdEEgo6I3HAezQhLlMUU=.1b447200-1dba-4b4e-88c6-ccb13922f4ed@github.com>
References: <dz3hSAWqwPVfDHfLJgYhCzgkdEEgo6I3HAezQhLlMUU=.1b447200-1dba-4b4e-88c6-ccb13922f4ed@github.com>
Message-ID: <oJ_RMxoVmefSWQi5TpIQo7RyxvGA3nJSpePcd9K2BXw=.7351b424-71b2-4dbf-b395-b3f8c7925749@github.com>

On Sun, 10 Jul 2022 17:37:59 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> According to @rkennke, "it is sufficient to be a Committer in order to officially review Shenandoah PRs"
> 
> We should change the `jcheck` configuration to reflect this.

Looks reasonable. Thank you!

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

Marked as reviewed by rkennke (Lead).

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/4

From zgu at openjdk.org  Mon Jul 11 14:23:25 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 11 Jul 2022 14:23:25 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v5]
In-Reply-To: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
Message-ID: <-gZIyL_HcxoALruUKy0_hg2nA-IrcjZA7SRsBtFOlfE=.46003d5a-3899-48dd-b5c7-b3df04389b4d@github.com>

> ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated.
> 
> Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Aleksey's comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9023/files
  - new: https://git.openjdk.org/jdk/pull/9023/files/f076e810..44f50839

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

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

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

From lkorinth at openjdk.org  Mon Jul 11 16:13:40 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Mon, 11 Jul 2022 16:13:40 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests
In-Reply-To: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
Message-ID: <zds1pb4BLmVWsOpVwdCYns_r9MtXQG80YXV_qcVlccA=.9afc837c-f238-4a4e-a7a0-94053085b5da@github.com>

On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
> 
> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
> * adding additional `@requires`
> * removing it in tests where it is not actually required
> 
> Testing: gha, running tests
> 
> Thanks,
>   Thomas

Looks good, and thanks for removing `-XX:+IgnoreUnrecognizedVMOptions` from our test cases.

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

Marked as reviewed by lkorinth (Reviewer).

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

From kbarrett at openjdk.org  Mon Jul 11 18:19:51 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 11 Jul 2022 18:19:51 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests
In-Reply-To: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
Message-ID: <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com>

On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
> 
> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
> * adding additional `@requires`
> * removing it in tests where it is not actually required
> 
> Testing: gha, running tests
> 
> Thanks,
>   Thomas

Changes requested by kbarrett (Reviewer).

test/hotspot/jtreg/gc/epsilon/TestAlignment.java line 40:

> 38:  *                   gc.epsilon.TestAlignment
> 39:  */
> 40: /**

Insert blank line.

test/hotspot/jtreg/gc/epsilon/TestAlignment.java line 41:

> 39:  */
> 40: /**
> 41:  * @test TestMaxTLAB

Wrong test name.

test/hotspot/jtreg/gc/g1/TestLargePageUseForAuxMemory.java line 121:

> 119:                                                  "-XX:" + (largePageEnabled ? "+" : "-") + "UseLargePages" });
> 120:         if (Platform.is64bit()) {
> 121:             vmOpts.add("-XX:ObjectAlignmentInBytes=8");

As 8 is the default value, I'm not sure why this option is being added.

test/hotspot/jtreg/gc/g1/TestVerificationInConcurrentCycle.java line 47:

> 45:  * @test TestVerificationInConcurrentCycle
> 46:  * @requires vm.gc.G1
> 47:  * @requires !vm.debug

Maybe add a comment that this leaves out debug-only G1VerifyBitmaps.

test/hotspot/jtreg/gc/metaspace/TestMetaspacePerfCounters.java line 100:

> 98:  */
> 99: 
> 100: /* @test TestMetaspacePerfCountersSerial

I think that throughout this test could use the new-ish `@test id=XXX` feature, so this could be `@test id=Serial32` and the earlier one for 64 bit could be `@test id=Serial64`.  This would give more information in failure report summaries.

test/hotspot/jtreg/gc/metaspace/TestMetaspacePerfCounters.java line 155:

> 153:  * @run main/othervm -XX:+UsePerfData -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC gc.metaspace.TestMetaspacePerfCounters
> 154:  */
> 155: 

Is this file missing entries for Epsilon?  That could be a followup RFE if appropriate.

test/hotspot/jtreg/gc/shenandoah/options/TestSelectiveBarrierFlags.java line 40:

> 38:  *          of barrier flags
> 39:  * @requires vm.gc.Shenandoah
> 40:  * @requires !vm.debug

Seems like it might be a bit simpler to have one `@test` with the first two `@run` lines and no `@requires` on `vm.debug`, and a second (debug-only) `@test` with the third `@run`.

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

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

From tschatzl at openjdk.org  Tue Jul 12 08:07:45 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 12 Jul 2022 08:07:45 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests
In-Reply-To: <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
 <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com>
Message-ID: <4v4M--0sO6QFYpsUwGienS6oPXfdkHT3HtmTKhn1m1E=.8b3d17b8-d9db-4a0a-aba7-ae40b121f1dd@github.com>

On Mon, 11 Jul 2022 17:52:08 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
>> 
>> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
>> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
>> * adding additional `@requires`
>> * removing it in tests where it is not actually required
>> 
>> Testing: gha, running tests
>> 
>> Thanks,
>>   Thomas
>
> test/hotspot/jtreg/gc/g1/TestLargePageUseForAuxMemory.java line 121:
> 
>> 119:                                                  "-XX:" + (largePageEnabled ? "+" : "-") + "UseLargePages" });
>> 120:         if (Platform.is64bit()) {
>> 121:             vmOpts.add("-XX:ObjectAlignmentInBytes=8");
> 
> As 8 is the default value, I'm not sure why this option is being added.

Idk, I removed it.

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

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

From tschatzl at openjdk.org  Tue Jul 12 08:36:59 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 12 Jul 2022 08:36:59 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests [v2]
In-Reply-To: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
Message-ID: <TuC8bMBz74cNRxNgI-RD3b1xq4-uF7C4YyMA3tpoET8=.52529682-96ab-4f21-9860-73d152c0d5ec@github.com>

> Hi all,
> 
>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
> 
> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
> * adding additional `@requires`
> * removing it in tests where it is not actually required
> 
> Testing: gha, running tests
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  ayang, kbarrett review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9443/files
  - new: https://git.openjdk.org/jdk/pull/9443/files/9848697e..279b99d9

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

  Stats: 36 lines in 6 files changed: 2 ins; 11 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/9443.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9443/head:pull/9443

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

From lkorinth at openjdk.org  Tue Jul 12 10:42:43 2022
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 12 Jul 2022 10:42:43 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests [v2]
In-Reply-To: <TuC8bMBz74cNRxNgI-RD3b1xq4-uF7C4YyMA3tpoET8=.52529682-96ab-4f21-9860-73d152c0d5ec@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
 <TuC8bMBz74cNRxNgI-RD3b1xq4-uF7C4YyMA3tpoET8=.52529682-96ab-4f21-9860-73d152c0d5ec@github.com>
Message-ID: <NjuYfSSkIT_mW9GuE_2iiH5j545hYpB9HBhZVGpwam8=.d714d70b-4320-46b6-bc87-1e69b755fd60@github.com>

On Tue, 12 Jul 2022 08:36:59 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
>> 
>> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
>> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
>> * adding additional `@requires`
>> * removing it in tests where it is not actually required
>> 
>> Testing: gha, running tests
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   ayang, kbarrett review

Looks good.

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

Marked as reviewed by lkorinth (Reviewer).

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

From tschatzl at openjdk.org  Tue Jul 12 14:46:51 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 12 Jul 2022 14:46:51 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests [v3]
In-Reply-To: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
Message-ID: <Z0IfQ86R-Uw4cNC3zCoMv69cSY8l17oZ2BudBA35rxY=.96f2aa1d-32ff-41f6-96e9-b4dfe07ee59e@github.com>

> Hi all,
> 
>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
> 
> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
> * adding additional `@requires`
> * removing it in tests where it is not actually required
> 
> Testing: gha, running tests
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  add Epsilongc tests for TestMetaspacePerfCounters.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9443/files
  - new: https://git.openjdk.org/jdk/pull/9443/files/279b99d9..1b530193

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

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

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

From tschatzl at openjdk.org  Tue Jul 12 14:46:52 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Tue, 12 Jul 2022 14:46:52 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests [v3]
In-Reply-To: <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
 <8SyH5BiSHjTA7Vms9C9Dyif7KK2UDANjxFjtaxFtwj0=.2ba63d86-970f-4ff7-9f6d-671ab6418eb5@github.com>
Message-ID: <7pWz4FpEoOYH_oiqq77R7LuMDSiL-rPh0efNMicRjsI=.3bcb61bb-bee9-48ad-b460-2cdc56ee851c@github.com>

On Mon, 11 Jul 2022 18:07:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add Epsilongc tests for TestMetaspacePerfCounters.java
>
> test/hotspot/jtreg/gc/metaspace/TestMetaspacePerfCounters.java line 155:
> 
>> 153:  * @run main/othervm -XX:+UsePerfData -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC gc.metaspace.TestMetaspacePerfCounters
>> 154:  */
>> 155: 
> 
> Is this file missing entries for Epsilon?  That could be a followup RFE if appropriate.

Added. Passes.

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

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

From kdnilsen at openjdk.org  Tue Jul 12 19:59:21 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 12 Jul 2022 19:59:21 GMT
Subject: RFR: Include a version identifier in region sampling protocol for
 visualizer
In-Reply-To: <Hk5llXbTXN1xQNBdd4SxzabPsJFKfUf_46VW0nj1WfA=.da1ae6a3-29dd-400e-a686-266b55a9ec8b@github.com>
References: <Hk5llXbTXN1xQNBdd4SxzabPsJFKfUf_46VW0nj1WfA=.da1ae6a3-29dd-400e-a686-266b55a9ec8b@github.com>
Message-ID: <ERDkxXbmg4cehMjLGTyiUe0wNckb1pSwGek5pgbgXnU=.7fa0656d-1051-4f9d-b1f2-7beb679d848a@github.com>

On Tue, 12 Jul 2022 16:32:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change adds a new variable to the PerfData for region sampling. With this change, the visualizer is able to identify the version of the encoding used in the communication protocol with Shenandoah. This allows the same visualizer to operate with the original unmodified Shenandoah and the generational mode Shenandoah.

Thanks.

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

Marked as reviewed by kdnilsen (Committer).

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

From wkemper at openjdk.org  Tue Jul 12 22:08:23 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 12 Jul 2022 22:08:23 GMT
Subject: Integrated: Include a version identifier in region sampling protocol
 for visualizer
In-Reply-To: <Hk5llXbTXN1xQNBdd4SxzabPsJFKfUf_46VW0nj1WfA=.da1ae6a3-29dd-400e-a686-266b55a9ec8b@github.com>
References: <Hk5llXbTXN1xQNBdd4SxzabPsJFKfUf_46VW0nj1WfA=.da1ae6a3-29dd-400e-a686-266b55a9ec8b@github.com>
Message-ID: <U_EtHbZPGSBYChFXjULo2o978bMy2N2nj3mM4Pg1pgs=.bc4e135c-cddd-4dba-a1a2-9bf4c754e840@github.com>

On Tue, 12 Jul 2022 16:32:28 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This change adds a new variable to the PerfData for region sampling. With this change, the visualizer is able to identify the version of the encoding used in the communication protocol with Shenandoah. This allows the same visualizer to operate with the original unmodified Shenandoah and the generational mode Shenandoah.

This pull request has now been integrated.

Changeset: 013b2f69
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/013b2f693834b0e5ed6c6d2d197ebfcf12b63ae5
Stats:     11 lines in 4 files changed: 6 ins; 0 del; 5 mod

Include a version identifier in region sampling protocol for visualizer

Co-authored-by: Celine Wu <cfumiwu at amazon.com>
Reviewed-by: kdnilsen

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

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

From kbarrett at openjdk.org  Wed Jul 13 08:35:43 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 13 Jul 2022 08:35:43 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests [v3]
In-Reply-To: <Z0IfQ86R-Uw4cNC3zCoMv69cSY8l17oZ2BudBA35rxY=.96f2aa1d-32ff-41f6-96e9-b4dfe07ee59e@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
 <Z0IfQ86R-Uw4cNC3zCoMv69cSY8l17oZ2BudBA35rxY=.96f2aa1d-32ff-41f6-96e9-b4dfe07ee59e@github.com>
Message-ID: <rTjGGoqmRMPe6BrqHyDLQ_GRC4Hqofi2OOUybVQwoIw=.4c5aacef-5ad3-49c5-9a19-77bc4ce950a8@github.com>

On Tue, 12 Jul 2022 14:46:51 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
>> 
>> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
>> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
>> * adding additional `@requires`
>> * removing it in tests where it is not actually required
>> 
>> Testing: gha, running tests
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add Epsilongc tests for TestMetaspacePerfCounters.java

Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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

From tschatzl at openjdk.org  Wed Jul 13 09:38:38 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 13 Jul 2022 09:38:38 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests [v4]
In-Reply-To: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
Message-ID: <oB3BeNLxcMVp6s-VOZP-uprlMKq5uMo8k00zDrMgcYo=.0c878c8c-2c33-4282-8d87-3d95c80cb333@github.com>

> Hi all,
> 
>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
> 
> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
> * adding additional `@requires`
> * removing it in tests where it is not actually required
> 
> Testing: gha, running tests
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  Fix x86 metaspaceperfcounters test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9443/files
  - new: https://git.openjdk.org/jdk/pull/9443/files/1b530193..4c5d78f6

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

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

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

From tschatzl at openjdk.org  Wed Jul 13 13:51:15 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 13 Jul 2022 13:51:15 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests [v5]
In-Reply-To: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
Message-ID: <PLS40sdeic4S9pAtI0gaT4xfwu4pbNOMtsBivbODyTs=.46e6e691-5f12-4375-80d3-4b3fa20e993b@github.com>

> Hi all,
> 
>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
> 
> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
> * adding additional `@requires`
> * removing it in tests where it is not actually required
> 
> Testing: gha, running tests
> 
> Thanks,
>   Thomas

Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:

  Epsilon needs UnlockExperimentalOptions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9443/files
  - new: https://git.openjdk.org/jdk/pull/9443/files/4c5d78f6..f94c5b5e

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

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

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

From kbarrett at openjdk.org  Wed Jul 13 14:03:11 2022
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 13 Jul 2022 14:03:11 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests [v5]
In-Reply-To: <PLS40sdeic4S9pAtI0gaT4xfwu4pbNOMtsBivbODyTs=.46e6e691-5f12-4375-80d3-4b3fa20e993b@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
 <PLS40sdeic4S9pAtI0gaT4xfwu4pbNOMtsBivbODyTs=.46e6e691-5f12-4375-80d3-4b3fa20e993b@github.com>
Message-ID: <3RMOjf00YO53Jz1gNOLYIHjETSazWQPT-sbpNnM-Ybk=.25f1c9b4-a806-424d-adc4-cf1714e70e83@github.com>

On Wed, 13 Jul 2022 13:51:15 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
>> 
>> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
>> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
>> * adding additional `@requires`
>> * removing it in tests where it is not actually required
>> 
>> Testing: gha, running tests
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Epsilon needs UnlockExperimentalOptions

Drat!  I meant to check for that and then forgot.  Looks good.

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

Marked as reviewed by kbarrett (Reviewer).

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

From kdnilsen at openjdk.org  Wed Jul 13 15:37:33 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Jul 2022 15:37:33 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v3]
In-Reply-To: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
Message-ID: <CIRTrNEPrVV4wjnnHzL74Qpdc1hizZaa8EJktbgcqcY=.e95bbc62-8e88-409b-804d-2359c69e6b92@github.com>

> This commit consolidates computations related to budgeting of reserves for old-gen evacuation and old-gen promotion within shenandoahGeneration::prepare_regions_and_collection_set().  Previously, these computations had been scattered between several functional units, including shenandoahHeuristics::choose_collection_set() and shenandoahOldHeuristics::prime_collection_set().  A previous pull request brought some of the redundant functionality into prepare_regions_and_collection_set().  This pull request removes the redundant computations from the other locations.

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

 - Fix typo in on-line documentation
 - Fixup traditional Shennadoah performance regressions
   
   1. Since young-gen is currently used in some contexts as another name
      for the GLOBAL generation (may fix this later), fix the size of
      young-generation when we are in non-generational mode.
   
   2. Restore a heuristic that allows regions smaller than the
      min-threshold to be added into the collection set.
 - Fix size of traditional Shenandoah GLOBAL generation
 - Remove instrumentation
 - Only check preselected in generational mode
 - Use old-evac reserve for GLOBAL max old cset
   
   Copy and paste error in previous commit was using young-evac reserve.
 - Global collections need to honor evacuation reservations
   
   This fixes up adaptive heuristic to distinguish between old and young
   evacuations and their respective budgets.
 - Heuristics should not overwrite old evacuation budget
   
   In refactored code, we shrink old evcacuation budget in
   ShenandoahdGeneration::adjust_evacuation_budgets() which executes after
   the call to ShenandoahHeuristics::choose_collection_set().
 - Fix two refactoring errors
   
   1. An off-by-one error in calculating aged-region promotion bias
   2. The stack-allocated preselection array needs to be established in a
      more outer context.
 - Fixup tenure bias for aged regions
   
   Also insert disabled instrumentation to assist with debugging.  This
   instrumentation will be removed in a subsequent commit if we pass
   regression testing.
 - ... and 2 more: https://git.openjdk.org/shenandoah/compare/be1fb125...60951ee2

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/148/files
  - new: https://git.openjdk.org/shenandoah/pull/148/files/be1fb125..60951ee2

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

  Stats: 363 lines in 10 files changed: 189 ins; 65 del; 109 mod
  Patch: https://git.openjdk.org/shenandoah/pull/148.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/148/head:pull/148

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

From kdnilsen at openjdk.org  Wed Jul 13 15:55:56 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Jul 2022 15:55:56 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v4]
In-Reply-To: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
Message-ID: <8j2UEAiYv8gzXAJGZEmrPdPK4eCaC6Kny4qmnZV3PtE=.0eed039a-ad6e-46ce-9f29-2b16a11fb13a@github.com>

> This commit consolidates computations related to budgeting of reserves for old-gen evacuation and old-gen promotion within shenandoahGeneration::prepare_regions_and_collection_set().  Previously, these computations had been scattered between several functional units, including shenandoahHeuristics::choose_collection_set() and shenandoahOldHeuristics::prime_collection_set().  A previous pull request brought some of the redundant functionality into prepare_regions_and_collection_set().  This pull request removes the redundant computations from the other locations.

Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Merge master
 - Fix typo in on-line documentation
 - Fixup traditional Shennadoah performance regressions
   
   1. Since young-gen is currently used in some contexts as another name
      for the GLOBAL generation (may fix this later), fix the size of
      young-generation when we are in non-generational mode.
   
   2. Restore a heuristic that allows regions smaller than the
      min-threshold to be added into the collection set.
 - Fix size of traditional Shenandoah GLOBAL generation
 - Remove instrumentation
 - Only check preselected in generational mode
 - Use old-evac reserve for GLOBAL max old cset
   
   Copy and paste error in previous commit was using young-evac reserve.
 - Global collections need to honor evacuation reservations
   
   This fixes up adaptive heuristic to distinguish between old and young
   evacuations and their respective budgets.
 - Heuristics should not overwrite old evacuation budget
   
   In refactored code, we shrink old evcacuation budget in
   ShenandoahdGeneration::adjust_evacuation_budgets() which executes after
   the call to ShenandoahHeuristics::choose_collection_set().
 - Fix two refactoring errors
   
   1. An off-by-one error in calculating aged-region promotion bias
   2. The stack-allocated preselection array needs to be established in a
      more outer context.
 - ... and 5 more: https://git.openjdk.org/shenandoah/compare/013b2f69...c1c37cbf

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

Changes: https://git.openjdk.org/shenandoah/pull/148/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=148&range=03
  Stats: 1190 lines in 11 files changed: 543 ins; 583 del; 64 mod
  Patch: https://git.openjdk.org/shenandoah/pull/148.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/148/head:pull/148

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

From tschatzl at openjdk.org  Wed Jul 13 16:10:04 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 13 Jul 2022 16:10:04 GMT
Subject: RFR: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests [v5]
In-Reply-To: <3RMOjf00YO53Jz1gNOLYIHjETSazWQPT-sbpNnM-Ybk=.25f1c9b4-a806-424d-adc4-cf1714e70e83@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
 <PLS40sdeic4S9pAtI0gaT4xfwu4pbNOMtsBivbODyTs=.46e6e691-5f12-4375-80d3-4b3fa20e993b@github.com>
 <3RMOjf00YO53Jz1gNOLYIHjETSazWQPT-sbpNnM-Ybk=.25f1c9b4-a806-424d-adc4-cf1714e70e83@github.com>
Message-ID: <CWjtSeaCw8RLyqKcIuTZbdOf756HacuzsHAoNibHEEQ=.400c9fb2-e6a0-42c9-9d2b-183d8788ed85@github.com>

On Wed, 13 Jul 2022 14:01:09 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Epsilon needs UnlockExperimentalOptions
>
> Drat!  I meant to check for that and then forgot.  Looks good.

Thanks @kimbarrett @albertnetymk @lkorinth for your reviews.

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

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

From tschatzl at openjdk.org  Wed Jul 13 16:11:23 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Wed, 13 Jul 2022 16:11:23 GMT
Subject: Integrated: 8290023: Remove use of IgnoreUnrecognizedVMOptions in gc
 tests
In-Reply-To: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
References: <cdLZBQbKmB9ZAmQlPiNbiiHg7pFBRpCqDjuu7557RqQ=.ab97eef7-5193-4b6b-b075-b18691b50872@github.com>
Message-ID: <MXZ50TTIBEyANonPOgj6L4uwl2JCg7iU9zMfmYAP4Hs=.d0169b9e-d135-4966-a0c7-a0b03cca632c@github.com>

On Mon, 11 Jul 2022 07:39:02 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Hi all,
> 
>   can I have reviews for removal of the use of `-XX:+IgnoreUnrecognizedVMOptions` for gc tests?
> 
> As per [JDK-8228493](https://bugs.openjdk.org/browse/JDK-8228493) use of that option has drawbacks wrt to test reliability, so trying to remove them by
> * duplicating `@test` blocks (mostly sme Shenandoah tests as I could not find a good way for them)
> * adding additional `@requires`
> * removing it in tests where it is not actually required
> 
> Testing: gha, running tests
> 
> Thanks,
>   Thomas

This pull request has now been integrated.

Changeset: 2583feb2
Author:    Thomas Schatzl <tschatzl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2583feb21bf5419afc3c1953d964cf89d65fe8a2
Stats:     282 lines in 13 files changed: 208 ins; 24 del; 50 mod

8290023: Remove use of IgnoreUnrecognizedVMOptions in gc tests

Reviewed-by: ayang, lkorinth, kbarrett

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

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

From kdnilsen at openjdk.org  Wed Jul 13 16:14:36 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Jul 2022 16:14:36 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v5]
In-Reply-To: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
Message-ID: <wXK5nXmy9BhA_Dq5wvK7tagwhCwqFM3or7zgG6I5uB0=.3d2ff5f0-09b7-4ced-8076-0574b00a281e@github.com>

> This commit consolidates computations related to budgeting of reserves for old-gen evacuation and old-gen promotion within shenandoahGeneration::prepare_regions_and_collection_set().  Previously, these computations had been scattered between several functional units, including shenandoahHeuristics::choose_collection_set() and shenandoahOldHeuristics::prime_collection_set().  A previous pull request brought some of the redundant functionality into prepare_regions_and_collection_set().  This pull request removes the redundant computations from the other locations.

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

  Fix white space

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/148/files
  - new: https://git.openjdk.org/shenandoah/pull/148/files/c1c37cbf..6c42841a

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

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

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

From kdnilsen at openjdk.org  Wed Jul 13 16:27:49 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Jul 2022 16:27:49 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v2]
In-Reply-To: <5JhbNlVOmwqBbccX9LCdSJMjE6QIMO8ZQJfFuTZFqRc=.03d53ad8-1426-41af-afeb-d79d9376ebaa@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
 <WQrnsfdI662sSK3tamSfkr9nvq0_SG5AUsT5M1gMkdQ=.748dfc81-6bbf-4dce-b52c-00c2243e729a@github.com>
 <5JhbNlVOmwqBbccX9LCdSJMjE6QIMO8ZQJfFuTZFqRc=.03d53ad8-1426-41af-afeb-d79d9376ebaa@github.com>
Message-ID: <pWhSMrHJWIVZcMc5h_1G82m1psITT9JqF2nz2QZmEns=.3b4911e5-d9b5-47ce-82ac-77d13cc68f66@github.com>

On Sat, 2 Jul 2022 16:20:04 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Isolate the code that reserves evacuation budgets into functions
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 224:
> 
>> 222: }
>> 223: 
>> 224: void ShenandoahGeneration::compute_evacuation_budgets(ShenandoahHeap* heap, ShenandoahCollectionSet* collection_set,
> 
> The refactoring of the large chunks of code into the smaller methods is definitely a step in the right direction in making the code easier to follow.
> 
> Nit: Would it make the code more readable to consolidate the long sections of comments into a block comment at the top of each of the methods and have much shorter comments in the body of the methods?

Thanks for your suggestion.  Maybe you can do a subsequent pass (in a future PR) to clean up the structure of comments.  I'm sure these can be made better.  Sometimes, a "reader" of the comments has the best perspective on how to make the comments more valuable to other readers.

> src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 114:
> 
>> 112:   void prepare_gc(bool do_old_gc_bootstrap);
>> 113: 
>> 114:   // Compute evacuation budgets prior to choosing collection set.
> 
> Do these methods need to be public? They looked more like helper methods in the way they are currently being used.
> 
> Another thing to think about is whether the reference parameters in one signature and regular ones in the other are potential sources of confusion or error in the future. I can see why they are like they are in their current use, but might indicate that perhaps a cleaner refactoring of the methods and the state that it uses or modifies, and where that state should reside.
> 
> Nothing to do at the moment, but worth thinking about.

Agree with suggestion to make compute_evacuation_budgets and adjust_evacuation_budgets private.  Done.

I welcome further refactoring improvements in the future.  Am eager to get this code integrated now (as is) so that we can proceed with other performance improvements.

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

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

From kdnilsen at openjdk.org  Wed Jul 13 16:33:03 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Jul 2022 16:33:03 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v6]
In-Reply-To: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
Message-ID: <7EjUaw2WWRovG53dCq39rccor-lTIZkDhlOQT4dh5Yo=.13ec021d-bac8-43da-8024-184f4c2661f5@github.com>

> This commit consolidates computations related to budgeting of reserves for old-gen evacuation and old-gen promotion within shenandoahGeneration::prepare_regions_and_collection_set().  Previously, these computations had been scattered between several functional units, including shenandoahHeuristics::choose_collection_set() and shenandoahOldHeuristics::prime_collection_set().  A previous pull request brought some of the redundant functionality into prepare_regions_and_collection_set().  This pull request removes the redundant computations from the other locations.

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

  Make helper methods private

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/148/files
  - new: https://git.openjdk.org/shenandoah/pull/148/files/6c42841a..93a16843

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

  Stats: 22 lines in 1 file changed: 12 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/shenandoah/pull/148.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/148/head:pull/148

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

From wkemper at openjdk.org  Wed Jul 13 16:59:48 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 13 Jul 2022 16:59:48 GMT
Subject: RFR: Refactor budgeting to make the logic cleaner [v6]
In-Reply-To: <7EjUaw2WWRovG53dCq39rccor-lTIZkDhlOQT4dh5Yo=.13ec021d-bac8-43da-8024-184f4c2661f5@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
 <7EjUaw2WWRovG53dCq39rccor-lTIZkDhlOQT4dh5Yo=.13ec021d-bac8-43da-8024-184f4c2661f5@github.com>
Message-ID: <FPS_mwhoIciR88EB9eBUoKMr8L1tmdg3R-DWxG4aa-U=.5d7c1f49-0cc8-4683-902d-1edacd2d3b76@github.com>

On Wed, 13 Jul 2022 16:33:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This commit consolidates computations related to budgeting of reserves for old-gen evacuation and old-gen promotion within shenandoahGeneration::prepare_regions_and_collection_set().  Previously, these computations had been scattered between several functional units, including shenandoahHeuristics::choose_collection_set() and shenandoahOldHeuristics::prime_collection_set().  A previous pull request brought some of the redundant functionality into prepare_regions_and_collection_set().  This pull request removes the redundant computations from the other locations.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make helper methods private

Marked as reviewed by wkemper (Committer).

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

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

From kdnilsen at openjdk.org  Wed Jul 13 17:02:19 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Jul 2022 17:02:19 GMT
Subject: Integrated: Refactor budgeting to make the logic cleaner
In-Reply-To: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
References: <LTCrUZbg83KmNa-GGCq73G-s_vFTjD3z8S4oRTngUEk=.f522b343-0ac2-4f7d-b6bf-3887a235121a@github.com>
Message-ID: <ct_Mi_seMIyCV9xLb_byAnxG3HZ-0psbD2DHBFQun00=.60d6fa67-ef22-4e50-8c18-6ed289d889d4@github.com>

On Tue, 28 Jun 2022 03:20:44 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This commit consolidates computations related to budgeting of reserves for old-gen evacuation and old-gen promotion within shenandoahGeneration::prepare_regions_and_collection_set().  Previously, these computations had been scattered between several functional units, including shenandoahHeuristics::choose_collection_set() and shenandoahOldHeuristics::prime_collection_set().  A previous pull request brought some of the redundant functionality into prepare_regions_and_collection_set().  This pull request removes the redundant computations from the other locations.

This pull request has now been integrated.

Changeset: d47c60ec
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/d47c60ecd81c05bda39191e44ee916a5aab22baa
Stats:     1191 lines in 11 files changed: 545 ins; 584 del; 62 mod

Refactor budgeting to make the logic cleaner

Reviewed-by: rkennke, wkemper

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

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

From zgu at openjdk.org  Wed Jul 13 18:48:42 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 13 Jul 2022 18:48:42 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
Message-ID: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>

Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature).

Test:
- [x] hotspot_gc_shenandoah
- [x] jdk_loom with Shenandoah + iu
- [x] hotspot_loom with Shenandoah + iu

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

Commit messages:
 - 8290250: Shenandoah: disable Loom for iu mode

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

PR: https://git.openjdk.org/jdk19/pull/140

From eosterlund at openjdk.org  Wed Jul 13 19:06:21 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 13 Jul 2022 19:06:21 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
Message-ID: <mfCXr-8VBzBHY9DyXRm7PBKS64BiokNJnoxb0ZR4vuQ=.7fdb7a1a-0cea-46ae-b8a2-19c5582263e8@github.com>

On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature).
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom with Shenandoah + iu
> - [x] hotspot_loom with Shenandoah + iu

Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.

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

PR: https://git.openjdk.org/jdk19/pull/140

From zgu at openjdk.org  Wed Jul 13 19:31:13 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 13 Jul 2022 19:31:13 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <mfCXr-8VBzBHY9DyXRm7PBKS64BiokNJnoxb0ZR4vuQ=.7fdb7a1a-0cea-46ae-b8a2-19c5582263e8@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
 <mfCXr-8VBzBHY9DyXRm7PBKS64BiokNJnoxb0ZR4vuQ=.7fdb7a1a-0cea-46ae-b8a2-19c5582263e8@github.com>
Message-ID: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com>

On Wed, 13 Jul 2022 19:02:39 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.

Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?

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

PR: https://git.openjdk.org/jdk19/pull/140

From rkennke at openjdk.org  Wed Jul 13 19:43:01 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Wed, 13 Jul 2022 19:43:01 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
Message-ID: <B3vnG8sI_ug23PBR7-0Ku5NUAofcmCI95_hWRAncJkY=.6bf6ac6b-ccef-4ff6-8822-c1c1e5cf9d2e@github.com>

On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature).
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom with Shenandoah + iu
> - [x] hotspot_loom with Shenandoah + iu

Yes, looks good. Thank you.

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

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/140

From eosterlund at openjdk.org  Wed Jul 13 20:04:58 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 13 Jul 2022 20:04:58 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
 <mfCXr-8VBzBHY9DyXRm7PBKS64BiokNJnoxb0ZR4vuQ=.7fdb7a1a-0cea-46ae-b8a2-19c5582263e8@github.com>
 <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com>
Message-ID: <VZHzVb5BCtJnCmraAB67IIHGF6tuWq70XF5zHEDe_kE=.cef9f7f8-6314-4ee6-bd48-2015607f930b@github.com>

On Wed, 13 Jul 2022 19:27:40 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
> 
> 
> 
> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
> 
> 

Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited. 

However, with an IU scheme, that property does not translate. 

Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.

So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.

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

PR: https://git.openjdk.org/jdk19/pull/140

From jiefu at openjdk.org  Wed Jul 13 23:16:36 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 13 Jul 2022 23:16:36 GMT
Subject: RFR: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to
 invalid tag: required after JDK-8290023
Message-ID: <kXgkRtwlRKi5WzJv1DLYTOPzNnRnR6TOFb50NdlE7oI=.598e8fa1-730d-4dee-ae1d-d7c11be73ac7@github.com>

Hi all,

Please review the trivial fix which fixes a typo (`required` --> `requires`).

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to invalid tag: required after JDK-8290023

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

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

From wkemper at openjdk.org  Thu Jul 14 00:15:03 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 14 Jul 2022 00:15:03 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark [v2]
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <gp7UiozBIwRlMALJV2UeiWZWAbN5c0eGS76ww-hwHd4=.1b702ba8-812a-439d-987f-608c2df22a31@github.com>

> Pinned regions were not being coalesced and filled. This fixes a crash observed with the specjbb 2015 benchmark.

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

 - WIP: Add a "unit" test for exercising old pinned region code paths
 - WIP: Start changing mixed collections to handle pinned old regions
 - WIP: Restore ability to interrupt making old regions parseable
 - WIP: Factor filling old out of collection cycle. It needs to happen before bitmap is reset

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/149/files
  - new: https://git.openjdk.org/shenandoah/pull/149/files/cfb672d3..ade000aa

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

  Stats: 845 lines in 23 files changed: 444 ins; 261 del; 140 mod
  Patch: https://git.openjdk.org/shenandoah/pull/149.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/149/head:pull/149

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

From andrew at openjdk.org  Thu Jul 14 01:22:32 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Thu, 14 Jul 2022 01:22:32 GMT
Subject: Integrated: 8290049: Committers should be able to review for
 Shenandoah 8u
In-Reply-To: <dz3hSAWqwPVfDHfLJgYhCzgkdEEgo6I3HAezQhLlMUU=.1b447200-1dba-4b4e-88c6-ccb13922f4ed@github.com>
References: <dz3hSAWqwPVfDHfLJgYhCzgkdEEgo6I3HAezQhLlMUU=.1b447200-1dba-4b4e-88c6-ccb13922f4ed@github.com>
Message-ID: <vq0s0awruuTHc_AIYj74JnvcqzeeVRBqi8XQgY2YSaA=.66f71452-1ceb-4a36-9898-a4d6d240c26d@github.com>

On Sun, 10 Jul 2022 17:37:59 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> According to @rkennke, "it is sufficient to be a Committer in order to officially review Shenandoah PRs"
> 
> We should change the `jcheck` configuration to reflect this.

This pull request has now been integrated.

Changeset: 0d9c5615
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/0d9c56151513420508cdccc1d8d281b78a3e0f7f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8290049: Committers should be able to review for Shenandoah 8u

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/4

From tschatzl at openjdk.org  Thu Jul 14 07:55:08 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 14 Jul 2022 07:55:08 GMT
Subject: RFR: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to
 invalid tag: required after JDK-8290023
In-Reply-To: <kXgkRtwlRKi5WzJv1DLYTOPzNnRnR6TOFb50NdlE7oI=.598e8fa1-730d-4dee-ae1d-d7c11be73ac7@github.com>
References: <kXgkRtwlRKi5WzJv1DLYTOPzNnRnR6TOFb50NdlE7oI=.598e8fa1-730d-4dee-ae1d-d7c11be73ac7@github.com>
Message-ID: <YHVRJy3Rw-fJwgfxGVLRnikpn1trBrx-64Qh6NS-rNY=.569e5ced-bcef-4e2d-bf11-3c5bfe627422@github.com>

On Wed, 13 Jul 2022 23:09:19 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the trivial fix which fixes a typo (`required` --> `requires`).
> 
> Thanks.
> Best regards,
> Jie

Lgtm and trivial

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

Marked as reviewed by tschatzl (Reviewer).

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

From tschatzl at openjdk.org  Thu Jul 14 08:25:50 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 14 Jul 2022 08:25:50 GMT
Subject: RFR: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to
 invalid tag: required after JDK-8290023
In-Reply-To: <kXgkRtwlRKi5WzJv1DLYTOPzNnRnR6TOFb50NdlE7oI=.598e8fa1-730d-4dee-ae1d-d7c11be73ac7@github.com>
References: <kXgkRtwlRKi5WzJv1DLYTOPzNnRnR6TOFb50NdlE7oI=.598e8fa1-730d-4dee-ae1d-d7c11be73ac7@github.com>
Message-ID: <AM73UdTnnKSCg1kHt5fjVcIEPP-6clP7KFR7avsgmwE=.f1b2a0c4-a9f0-415c-8bfd-2a335fcd73c2@github.com>

On Wed, 13 Jul 2022 23:09:19 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the trivial fix which fixes a typo (`required` --> `requires`).
> 
> Thanks.
> Best regards,
> Jie

Also, apologies for the issue - I did not do release build runs with the change, and gha doesn't either.

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

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

From jiefu at openjdk.org  Thu Jul 14 08:34:05 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 14 Jul 2022 08:34:05 GMT
Subject: RFR: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due to
 invalid tag: required after JDK-8290023
In-Reply-To: <YHVRJy3Rw-fJwgfxGVLRnikpn1trBrx-64Qh6NS-rNY=.569e5ced-bcef-4e2d-bf11-3c5bfe627422@github.com>
References: <kXgkRtwlRKi5WzJv1DLYTOPzNnRnR6TOFb50NdlE7oI=.598e8fa1-730d-4dee-ae1d-d7c11be73ac7@github.com>
 <YHVRJy3Rw-fJwgfxGVLRnikpn1trBrx-64Qh6NS-rNY=.569e5ced-bcef-4e2d-bf11-3c5bfe627422@github.com>
Message-ID: <U7PdilHRbyb1Z8mWgVTYnQeh1hAY0sSISSuoZ8sQq4I=.5d1bd0fd-d364-4340-bd8d-5c686f3e1560@github.com>

On Thu, 14 Jul 2022 07:52:19 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

> Lgtm and trivial

Thanks @tschatzl for the review.

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

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

From jiefu at openjdk.org  Thu Jul 14 08:34:07 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 14 Jul 2022 08:34:07 GMT
Subject: Integrated: 8290269: gc/shenandoah/TestVerifyJCStress.java fails due
 to invalid tag: required after JDK-8290023
In-Reply-To: <kXgkRtwlRKi5WzJv1DLYTOPzNnRnR6TOFb50NdlE7oI=.598e8fa1-730d-4dee-ae1d-d7c11be73ac7@github.com>
References: <kXgkRtwlRKi5WzJv1DLYTOPzNnRnR6TOFb50NdlE7oI=.598e8fa1-730d-4dee-ae1d-d7c11be73ac7@github.com>
Message-ID: <w7PBgyFTMb_eb2nVaY3m2l4Fa8wwJPz5Yia969GLUG8=.853522b4-b594-4d26-a3bc-fd3bce6752c9@github.com>

On Wed, 13 Jul 2022 23:09:19 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Please review the trivial fix which fixes a typo (`required` --> `requires`).
> 
> Thanks.
> Best regards,
> Jie

This pull request has now been integrated.

Changeset: be58cbc4
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/be58cbc417ba5e08aa2118f9522c72c96c181a86
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8290269: gc/shenandoah/TestVerifyJCStress.java fails due to invalid tag: required after JDK-8290023

Reviewed-by: tschatzl

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

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

From zgu at openjdk.org  Thu Jul 14 14:03:25 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 14 Jul 2022 14:03:25 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
Message-ID: <twT4id6GxkSRpq_5fKbNw-E4QZa47FpodcmmmQFewIE=.5201e256-99fd-494c-99fa-0d7b172de5f0@github.com>

Please review this patch to fix Loom test crash with Shenandoah IU mode.

Test:

- [x] hotspot_gc_shenandoah
- [x] jdk_loom with Shenandoah + IU
- [x] hotspot_loom with Shenandoah + IU

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

Commit messages:
 - 8288129: Shenandoah: Skynet test crashed with iu + aggressive
 - Merge branch 'master' into JDK-8288129-iu-vthr
 - Merge branch 'master' into JDK-8288129-iu-vthr
 - v0

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

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

From zgu at openjdk.org  Thu Jul 14 15:34:47 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 14 Jul 2022 15:34:47 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
 [v2]
In-Reply-To: <twT4id6GxkSRpq_5fKbNw-E4QZa47FpodcmmmQFewIE=.5201e256-99fd-494c-99fa-0d7b172de5f0@github.com>
References: <twT4id6GxkSRpq_5fKbNw-E4QZa47FpodcmmmQFewIE=.5201e256-99fd-494c-99fa-0d7b172de5f0@github.com>
Message-ID: <ihptB_TXV9PuWZaXOppR-Szp07hYJMQ0ccjs64gf4MI=.5b283f0c-c6e2-45b6-b197-5c829bac6265@github.com>

> Please review this patch to fix Loom test crash with Shenandoah IU mode.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom with Shenandoah + IU
> - [x] hotspot_loom with Shenandoah + IU

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

 - Merge branch 'master' into JDK-8288129-iu-vthr
 - Fix
 - 8288129: Shenandoah: Skynet test crashed with iu + aggressive
 - Merge branch 'master' into JDK-8288129-iu-vthr
 - Merge branch 'master' into JDK-8288129-iu-vthr
 - v0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9494/files
  - new: https://git.openjdk.org/jdk/pull/9494/files/24cad3b5..6f901a74

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

  Stats: 996 lines in 46 files changed: 686 ins; 75 del; 235 mod
  Patch: https://git.openjdk.org/jdk/pull/9494.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9494/head:pull/9494

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

From zgu at openjdk.org  Thu Jul 14 15:57:17 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 14 Jul 2022 15:57:17 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
 [v3]
In-Reply-To: <twT4id6GxkSRpq_5fKbNw-E4QZa47FpodcmmmQFewIE=.5201e256-99fd-494c-99fa-0d7b172de5f0@github.com>
References: <twT4id6GxkSRpq_5fKbNw-E4QZa47FpodcmmmQFewIE=.5201e256-99fd-494c-99fa-0d7b172de5f0@github.com>
Message-ID: <RrFde7Ie5q8ZNUyx2sYiUYWgi0NJ4sTzfhK5-jM8P_U=.a2d478fb-87bb-4a9d-a8ff-f0e1d726e7a7@github.com>

> Please review this patch to fix Loom test crash with Shenandoah IU mode.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom with Shenandoah + IU
> - [x] hotspot_loom with Shenandoah + IU

Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:

  Always requires barrier for IU

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9494/files
  - new: https://git.openjdk.org/jdk/pull/9494/files/6f901a74..067b51eb

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

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

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

From zgu at openjdk.org  Thu Jul 14 16:41:03 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 14 Jul 2022 16:41:03 GMT
Subject: Withdrawn: 8288129: Shenandoah: Skynet test crashed with iu +
 aggressive
In-Reply-To: <twT4id6GxkSRpq_5fKbNw-E4QZa47FpodcmmmQFewIE=.5201e256-99fd-494c-99fa-0d7b172de5f0@github.com>
References: <twT4id6GxkSRpq_5fKbNw-E4QZa47FpodcmmmQFewIE=.5201e256-99fd-494c-99fa-0d7b172de5f0@github.com>
Message-ID: <24LBExD5WMSzWnymHEjzu8tUPCB4AG50qxbzRFJFweo=.25e9ef00-c7a1-45a6-8199-d55b03e5e993@github.com>

On Thu, 14 Jul 2022 13:54:35 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this patch to fix Loom test crash with Shenandoah IU mode.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom with Shenandoah + IU
> - [x] hotspot_loom with Shenandoah + IU

This pull request has been closed without being integrated.

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

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

From zgu at openjdk.org  Thu Jul 14 17:20:28 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 14 Jul 2022 17:20:28 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <VZHzVb5BCtJnCmraAB67IIHGF6tuWq70XF5zHEDe_kE=.cef9f7f8-6314-4ee6-bd48-2015607f930b@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
 <mfCXr-8VBzBHY9DyXRm7PBKS64BiokNJnoxb0ZR4vuQ=.7fdb7a1a-0cea-46ae-b8a2-19c5582263e8@github.com>
 <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com>
 <VZHzVb5BCtJnCmraAB67IIHGF6tuWq70XF5zHEDe_kE=.cef9f7f8-6314-4ee6-bd48-2015607f930b@github.com>
Message-ID: <Z5wmgtK0zFPtYopXJ0MRjsEjiMhpfMTN4M27m_tGBFM=.670281f9-d539-43c7-ac6b-4b88bd2f0060@github.com>

On Wed, 13 Jul 2022 20:01:51 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> > > Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
> > 
> > 
> > Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
> 
> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited.
> 
> However, with an IU scheme, that property does not translate.
> 
> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.
> 
> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.

Unfortunately, IU problem is beyond the barrier elision. Even I don't elide the barrier for IU, I still see failures.

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

PR: https://git.openjdk.org/jdk19/pull/140

From zgu at openjdk.org  Thu Jul 14 17:23:07 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Thu, 14 Jul 2022 17:23:07 GMT
Subject: [jdk19] Integrated: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
Message-ID: <5Aro-qPeLVOs5STFw3kaBl-XBDYinhkrKDldDGxL5eM=.4b5000b4-36ca-4c13-a8be-42837a393b46@github.com>

On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature).
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom with Shenandoah + iu
> - [x] hotspot_loom with Shenandoah + iu

This pull request has now been integrated.

Changeset: c8e03151
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/c8e03151142c444710321c2e8a41e242283922a4
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8290250: Shenandoah: disable Loom for iu mode

Reviewed-by: rkennke

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

PR: https://git.openjdk.org/jdk19/pull/140

From eosterlund at openjdk.org  Thu Jul 14 17:44:09 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 14 Jul 2022 17:44:09 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <Z5wmgtK0zFPtYopXJ0MRjsEjiMhpfMTN4M27m_tGBFM=.670281f9-d539-43c7-ac6b-4b88bd2f0060@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
 <mfCXr-8VBzBHY9DyXRm7PBKS64BiokNJnoxb0ZR4vuQ=.7fdb7a1a-0cea-46ae-b8a2-19c5582263e8@github.com>
 <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com>
 <VZHzVb5BCtJnCmraAB67IIHGF6tuWq70XF5zHEDe_kE=.cef9f7f8-6314-4ee6-bd48-2015607f930b@github.com>
 <Z5wmgtK0zFPtYopXJ0MRjsEjiMhpfMTN4M27m_tGBFM=.670281f9-d539-43c7-ac6b-4b88bd2f0060@github.com>
Message-ID: <jqp3lvicOmaXhF9KANGvhBJqhhD7dDWK_Ney6dvazzc=.b5d2fc0d-b539-4d0d-b7dd-237327eec448@github.com>

On Thu, 14 Jul 2022 17:17:49 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> > > > Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
> 
> > > 
> 
> > > 
> 
> > > Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
> 
> > 
> 
> > Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited.
> 
> > 
> 
> > However, with an IU scheme, that property does not translate.
> 
> > 
> 
> > Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.
> 
> > 
> 
> > So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.
> 
> 
> 
> Unfortunately, IU problem is beyond the barrier elision. Even I don't elide the barrier for IU, I still see failures.

Right. Loom assumes that write barriers are not needed on newly allocated objects, so that it can copy oops from the stack to the heap. Shenandoah with IU mode is the only collector where that is not true, due to the reason I outlined. What I'm saying isn't that turning off barrier elision in IU mode will fix your current loom crash. I'm saying that even without loom, the barrier elision is invalid in general. I thought I'd let you know, in case you want Shenandoah with IU mode to work reliably at all.

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

PR: https://git.openjdk.org/jdk19/pull/140

From rkennke at openjdk.org  Thu Jul 14 18:21:26 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Thu, 14 Jul 2022 18:21:26 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <jqp3lvicOmaXhF9KANGvhBJqhhD7dDWK_Ney6dvazzc=.b5d2fc0d-b539-4d0d-b7dd-237327eec448@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
 <mfCXr-8VBzBHY9DyXRm7PBKS64BiokNJnoxb0ZR4vuQ=.7fdb7a1a-0cea-46ae-b8a2-19c5582263e8@github.com>
 <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com>
 <VZHzVb5BCtJnCmraAB67IIHGF6tuWq70XF5zHEDe_kE=.cef9f7f8-6314-4ee6-bd48-2015607f930b@github.com>
 <Z5wmgtK0zFPtYopXJ0MRjsEjiMhpfMTN4M27m_tGBFM=.670281f9-d539-43c7-ac6b-4b88bd2f0060@github.com>
 <jqp3lvicOmaXhF9KANGvhBJqhhD7dDWK_Ney6dvazzc=.b5d2fc0d-b539-4d0d-b7dd-237327eec448@github.com>
Message-ID: <bL3Ma8IbUB3yDk-nmDhohaGeRmW_dNWpJNEI8YsvU_I=.bc48f97f-c4aa-494b-b4d7-f0eedcbe2cf7@github.com>

On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> > > Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
> > 
> > 
> > Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
> 
> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited.
> 
> However, with an IU scheme, that property does not translate.
> 
> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.
> 
> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.

IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem.

[1] https://www.cs.technion.ac.il/~yahave/papers/pldi06-cgc.pdf

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

PR: https://git.openjdk.org/jdk19/pull/140

From erik.osterlund at oracle.com  Thu Jul 14 19:10:13 2022
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Thu, 14 Jul 2022 19:10:13 +0000
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <bL3Ma8IbUB3yDk-nmDhohaGeRmW_dNWpJNEI8YsvU_I=.bc48f97f-c4aa-494b-b4d7-f0eedcbe2cf7@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
 <mfCXr-8VBzBHY9DyXRm7PBKS64BiokNJnoxb0ZR4vuQ=.7fdb7a1a-0cea-46ae-b8a2-19c5582263e8@github.com>
 <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com>
 <VZHzVb5BCtJnCmraAB67IIHGF6tuWq70XF5zHEDe_kE=.cef9f7f8-6314-4ee6-bd48-2015607f930b@github.com>
 <Z5wmgtK0zFPtYopXJ0MRjsEjiMhpfMTN4M27m_tGBFM=.670281f9-d539-43c7-ac6b-4b88bd2f0060@github.com>
 <jqp3lvicOmaXhF9KANGvhBJqhhD7dDWK_Ney6dvazzc=.b5d2fc0d-b539-4d0d-b7dd-237327eec448@github.com>
 <bL3Ma8IbUB3yDk-nmDhohaGeRmW_dNWpJNEI8YsvU_I=.bc48f97f-c4aa-494b-b4d7-f0eedcbe2cf7@github.com>
Message-ID: <44214571-5AAC-4FA1-B25B-A35F59C67D97@oracle.com>

Hi Roman,

The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked.

I will try to explain my example more clearly step by step.

1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B.

2. Marking starts. A is matked as a root, but before B is marked concurrently?

3. T1 loads B from the field of A.

4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers.

5. T1 allocates a new object C. It is implicitly alive and won?t be traced through.

6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash)

7. The root from T1 to B is discarded.

8. Concurrent marking traces from A but finds only null from step 4.

9. Marking terminates.

You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode.

Hope this helps.

/Erik

> On 14 Jul 2022, at 20:21, Roman Kennke <rkennke at openjdk.org> wrote:
> 
> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:
> 
>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
>>> 
>>> 
>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
>> 
>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited.
>> 
>> However, with an IU scheme, that property does not translate.
>> 
>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.
>> 
>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.
> 
> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem.
> 
> [1] https://www.cs.technion.ac.il/~yahave/papers/pldi06-cgc.pdf
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk19/pull/140

From rkennke at redhat.com  Thu Jul 14 19:49:15 2022
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 14 Jul 2022 21:49:15 +0200
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <44214571-5AAC-4FA1-B25B-A35F59C67D97@oracle.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
 <mfCXr-8VBzBHY9DyXRm7PBKS64BiokNJnoxb0ZR4vuQ=.7fdb7a1a-0cea-46ae-b8a2-19c5582263e8@github.com>
 <8feZES_PH8lVjyvstxOj8w2bxELPpbnsbCVDTP8NNrA=.03544e6d-3872-46c7-9180-1335770ee7e3@github.com>
 <VZHzVb5BCtJnCmraAB67IIHGF6tuWq70XF5zHEDe_kE=.cef9f7f8-6314-4ee6-bd48-2015607f930b@github.com>
 <Z5wmgtK0zFPtYopXJ0MRjsEjiMhpfMTN4M27m_tGBFM=.670281f9-d539-43c7-ac6b-4b88bd2f0060@github.com>
 <jqp3lvicOmaXhF9KANGvhBJqhhD7dDWK_Ney6dvazzc=.b5d2fc0d-b539-4d0d-b7dd-237327eec448@github.com>
 <bL3Ma8IbUB3yDk-nmDhohaGeRmW_dNWpJNEI8YsvU_I=.bc48f97f-c4aa-494b-b4d7-f0eedcbe2cf7@github.com>
 <44214571-5AAC-4FA1-B25B-A35F59C67D97@oracle.com>
Message-ID: <d3c0d11f-a97a-6bca-54de-b07a6aa31ce9@redhat.com>

Hey Erik,

I just had a closer look at the IU barriers again. First of all, we are 
*not* using the same barriers for IU and SATB. That's why disabling 
barrier elision does nothing. Instead, we emit a c2 node for the IU 
barrier, and optimize on that and expand it during barrier expansion 
pass (together with the LRBs). The barrier consumes and replaces values 
being stored into fields and array elements. If such a value is provably 
a newly created object, then we don't need the barrier there - the 
object is implicitely live already.

Another difference between IU and SATB is that we don't need to 
keep-alive referents when somebody calls Reference.get() during 
concurrent marking. If such a referent goes out of scope again, then 
it's fine trivially. If the referent is stored anywhere, we will catch 
it with the barrier. If it only remains in a local variable by the end 
of concurrent marking, we will catch it in final remark. Please punch 
holes into this reasoning if you find anything. ;-)

Thanks,
Roman


> Hi Roman,
> 
> The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked.
> 
> I will try to explain my example more clearly step by step.
> 
> 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B.
> 
> 2. Marking starts. A is matked as a root, but before B is marked concurrently?
> 
> 3. T1 loads B from the field of A.
> 
> 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers.
> 
> 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through.
> 
> 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash)
> 
> 7. The root from T1 to B is discarded.
> 
> 8. Concurrent marking traces from A but finds only null from step 4.
> 
> 9. Marking terminates.
> 
> You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode.
> 
> Hope this helps.
> 
> /Erik
> 
>> On 14 Jul 2022, at 20:21, Roman Kennke <rkennke at openjdk.org> wrote:
>>
>> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:
>>
>>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
>>>>
>>>>
>>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
>>>
>>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited.
>>>
>>> However, with an IU scheme, that property does not translate.
>>>
>>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.
>>>
>>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.
>>
>> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem.
>>
>> [1] https://www.cs.technion.ac.il/~yahave/papers/pldi06-cgc.pdf
>>
>> -------------
>>
>> PR: https://git.openjdk.org/jdk19/pull/140


From erik.osterlund at oracle.com  Thu Jul 14 20:03:35 2022
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Thu, 14 Jul 2022 20:03:35 +0000
Subject: [External] : Re: [jdk19] RFR: 8290250: Shenandoah: disable Loom
 for iu mode
In-Reply-To: <d3c0d11f-a97a-6bca-54de-b07a6aa31ce9@redhat.com>
References: <d3c0d11f-a97a-6bca-54de-b07a6aa31ce9@redhat.com>
Message-ID: <B520249B-3DBF-4752-B089-59207F63E356@oracle.com>

The problem is that when you store the edge from C to B in my example, at step 6, the newly allocated object C is implicitly live, but the new value being written to the field (B) is not implicitly live and needs to be explicitly kept alive in an IU model. But it isn?t if the barrier is elided. This is a difference to SATB where B is also implicitly live due to being part of the snapshot-at-the-beginning, which is why eliding the barrier has no effect with SATB.

/Erik

> On 14 Jul 2022, at 21:49, Roman Kennke <rkennke at redhat.com> wrote:
> 
> ?Hey Erik,
> 
> I just had a closer look at the IU barriers again. First of all, we are *not* using the same barriers for IU and SATB. That's why disabling barrier elision does nothing. Instead, we emit a c2 node for the IU barrier, and optimize on that and expand it during barrier expansion pass (together with the LRBs). The barrier consumes and replaces values being stored into fields and array elements. If such a value is provably a newly created object, then we don't need the barrier there - the object is implicitely live already.
> 
> Another difference between IU and SATB is that we don't need to keep-alive referents when somebody calls Reference.get() during concurrent marking. If such a referent goes out of scope again, then it's fine trivially. If the referent is stored anywhere, we will catch it with the barrier. If it only remains in a local variable by the end of concurrent marking, we will catch it in final remark. Please punch holes into this reasoning if you find anything. ;-)
> 
> Thanks,
> Roman
> 
> 
>> Hi Roman,
>> The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked.
>> I will try to explain my example more clearly step by step.
>> 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B.
>> 2. Marking starts. A is matked as a root, but before B is marked concurrently?
>> 3. T1 loads B from the field of A.
>> 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers.
>> 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through.
>> 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash)
>> 7. The root from T1 to B is discarded.
>> 8. Concurrent marking traces from A but finds only null from step 4.
>> 9. Marking terminates.
>> You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode.
>> Hope this helps.
>> /Erik
>>>> On 14 Jul 2022, at 20:21, Roman Kennke <rkennke at openjdk.org> wrote:
>>> 
>>> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:
>>> 
>>>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
>>>>> 
>>>>> 
>>>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
>>>> 
>>>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited.
>>>> 
>>>> However, with an IU scheme, that property does not translate.
>>>> 
>>>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.
>>>> 
>>>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.
>>> 
>>> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem.
>>> 
>>> [1] https://urldefense.com/v3/__https://www.cs.technion.ac.il/*yahave/papers/pldi06-cgc.pdf__;fg!!ACWV5N9M2RV99hQ!LsTZM-MExdpbuTsR32dxyaa5i0r_hGg6RUCZm_YoqDYChH9oqK-dpzVCb7nD-ZtT0hlRzSgDnXxLrSmkx7Q$ 
>>> -------------
>>> 
>>> PR: https://git.openjdk.org/jdk19/pull/140
> 

From rkennke at redhat.com  Thu Jul 14 20:11:31 2022
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 14 Jul 2022 22:11:31 +0200
Subject: [External] : Re: [jdk19] RFR: 8290250: Shenandoah: disable Loom
 for iu mode
In-Reply-To: <B520249B-3DBF-4752-B089-59207F63E356@oracle.com>
References: <d3c0d11f-a97a-6bca-54de-b07a6aa31ce9@redhat.com>
 <B520249B-3DBF-4752-B089-59207F63E356@oracle.com>
Message-ID: <5d556173-9092-9ff9-1376-c973841de353@redhat.com>

No wait. The barrier is elided when B is new, but when C is new. This 
works differently than SATB. Makes sense?

Roman


> The problem is that when you store the edge from C to B in my example, at step 6, the newly allocated object C is implicitly live, but the new value being written to the field (B) is not implicitly live and needs to be explicitly kept alive in an IU model. But it isn?t if the barrier is elided. This is a difference to SATB where B is also implicitly live due to being part of the snapshot-at-the-beginning, which is why eliding the barrier has no effect with SATB.
> 
> /Erik
> 
>> On 14 Jul 2022, at 21:49, Roman Kennke <rkennke at redhat.com> wrote:
>>
>> ?Hey Erik,
>>
>> I just had a closer look at the IU barriers again. First of all, we are *not* using the same barriers for IU and SATB. That's why disabling barrier elision does nothing. Instead, we emit a c2 node for the IU barrier, and optimize on that and expand it during barrier expansion pass (together with the LRBs). The barrier consumes and replaces values being stored into fields and array elements. If such a value is provably a newly created object, then we don't need the barrier there - the object is implicitely live already.
>>
>> Another difference between IU and SATB is that we don't need to keep-alive referents when somebody calls Reference.get() during concurrent marking. If such a referent goes out of scope again, then it's fine trivially. If the referent is stored anywhere, we will catch it with the barrier. If it only remains in a local variable by the end of concurrent marking, we will catch it in final remark. Please punch holes into this reasoning if you find anything. ;-)
>>
>> Thanks,
>> Roman
>>
>>
>>> Hi Roman,
>>> The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked.
>>> I will try to explain my example more clearly step by step.
>>> 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B.
>>> 2. Marking starts. A is matked as a root, but before B is marked concurrently?
>>> 3. T1 loads B from the field of A.
>>> 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers.
>>> 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through.
>>> 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash)
>>> 7. The root from T1 to B is discarded.
>>> 8. Concurrent marking traces from A but finds only null from step 4.
>>> 9. Marking terminates.
>>> You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode.
>>> Hope this helps.
>>> /Erik
>>>>> On 14 Jul 2022, at 20:21, Roman Kennke <rkennke at openjdk.org> wrote:
>>>>
>>>> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:
>>>>
>>>>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
>>>>>>
>>>>>>
>>>>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
>>>>>
>>>>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited.
>>>>>
>>>>> However, with an IU scheme, that property does not translate.
>>>>>
>>>>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.
>>>>>
>>>>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.
>>>>
>>>> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem.
>>>>
>>>> [1] https://urldefense.com/v3/__https://www.cs.technion.ac.il/*yahave/papers/pldi06-cgc.pdf__;fg!!ACWV5N9M2RV99hQ!LsTZM-MExdpbuTsR32dxyaa5i0r_hGg6RUCZm_YoqDYChH9oqK-dpzVCb7nD-ZtT0hlRzSgDnXxLrSmkx7Q$
>>>> -------------
>>>>
>>>> PR: https://git.openjdk.org/jdk19/pull/140
>>


From erik.osterlund at oracle.com  Thu Jul 14 21:07:36 2022
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Thu, 14 Jul 2022 21:07:36 +0000
Subject: [External] : Re: [jdk19] RFR: 8290250: Shenandoah: disable Loom
 for iu mode
In-Reply-To: <5d556173-9092-9ff9-1376-c973841de353@redhat.com>
References: <d3c0d11f-a97a-6bca-54de-b07a6aa31ce9@redhat.com>
 <B520249B-3DBF-4752-B089-59207F63E356@oracle.com>
 <5d556173-9092-9ff9-1376-c973841de353@redhat.com>
Message-ID: <C14C6DAD-103F-4602-BD9F-B3F9423F6F2E@oracle.com>

Hi Roman,

We seem to agree that eliding barriers purely on the basis that the containing object of a field is newly allocated, is invalid. But you seem to say that you do not elide barriers on e.g. initializing stores. If that is the case, all is well. However?
Last time I looked at the store capturing code of C2 for optimizing initializing stores, it emits normal stores with barriers and then in InitializeNode::capture_store it finds stores that are initializing stores for the new object (C), finds and clones the plain store (excluding barriers), and cuts out the old initializing store with IGVN, which should make the IU barrier not ?useful? (only used by dead code), and hence be removed in the useless barrier elimination phase, having the implicit effect of eliding barriers on initializing stores. I think that was indeed the intention of cloning the plain store, and cutting out the old store + barriers. But that isn?t legal with IU. If this works, I don?t see how. Did I miss something?

/Erik

> On 14 Jul 2022, at 22:11, Roman Kennke <rkennke at redhat.com> wrote:
> 
> ?No wait. The barrier is elided when B is new, but when C is new. This works differently than SATB. Makes sense?
> 
> Roman
> 
> 
>> The problem is that when you store the edge from C to B in my example, at step 6, the newly allocated object C is implicitly live, but the new value being written to the field (B) is not implicitly live and needs to be explicitly kept alive in an IU model. But it isn?t if the barrier is elided. This is a difference to SATB where B is also implicitly live due to being part of the snapshot-at-the-beginning, which is why eliding the barrier has no effect with SATB.
>> /Erik
>>>> On 14 Jul 2022, at 21:49, Roman Kennke <rkennke at redhat.com> wrote:
>>> 
>>> ?Hey Erik,
>>> 
>>> I just had a closer look at the IU barriers again. First of all, we are *not* using the same barriers for IU and SATB. That's why disabling barrier elision does nothing. Instead, we emit a c2 node for the IU barrier, and optimize on that and expand it during barrier expansion pass (together with the LRBs). The barrier consumes and replaces values being stored into fields and array elements. If such a value is provably a newly created object, then we don't need the barrier there - the object is implicitely live already.
>>> 
>>> Another difference between IU and SATB is that we don't need to keep-alive referents when somebody calls Reference.get() during concurrent marking. If such a referent goes out of scope again, then it's fine trivially. If the referent is stored anywhere, we will catch it with the barrier. If it only remains in a local variable by the end of concurrent marking, we will catch it in final remark. Please punch holes into this reasoning if you find anything. ;-)
>>> 
>>> Thanks,
>>> Roman
>>> 
>>> 
>>>> Hi Roman,
>>>> The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked.
>>>> I will try to explain my example more clearly step by step.
>>>> 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B.
>>>> 2. Marking starts. A is matked as a root, but before B is marked concurrently?
>>>> 3. T1 loads B from the field of A.
>>>> 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers.
>>>> 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through.
>>>> 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash)
>>>> 7. The root from T1 to B is discarded.
>>>> 8. Concurrent marking traces from A but finds only null from step 4.
>>>> 9. Marking terminates.
>>>> You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode.
>>>> Hope this helps.
>>>> /Erik
>>>>>> On 14 Jul 2022, at 20:21, Roman Kennke <rkennke at openjdk.org> wrote:
>>>>> 
>>>>> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:
>>>>> 
>>>>>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
>>>>>>> 
>>>>>>> 
>>>>>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
>>>>>> 
>>>>>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited.
>>>>>> 
>>>>>> However, with an IU scheme, that property does not translate.
>>>>>> 
>>>>>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.
>>>>>> 
>>>>>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.
>>>>> 
>>>>> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem.
>>>>> 
>>>>> [1] https://urldefense.com/v3/__https://www.cs.technion.ac.il/*yahave/papers/pldi06-cgc.pdf__;fg!!ACWV5N9M2RV99hQ!LsTZM-MExdpbuTsR32dxyaa5i0r_hGg6RUCZm_YoqDYChH9oqK-dpzVCb7nD-ZtT0hlRzSgDnXxLrSmkx7Q$
>>>>> -------------
>>>>> 
>>>>> PR: https://git.openjdk.org/jdk19/pull/140
>>> 
> 

From ysr at openjdk.org  Thu Jul 14 23:55:07 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 14 Jul 2022 23:55:07 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
Message-ID: <rma7aeqH8nCFraYk1Q3VTs536pKSbEPPd2EuqN6UwOw=.0bb884af-cf0f-4eab-96af-e74992e8888d@github.com>

On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature).
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom with Shenandoah + iu
> - [x] hotspot_loom with Shenandoah + iu

CMS collected only old gen, and direct allocations in old gen were grey, and so would updates of black objects in old gen. I assume new objects in Shenandoah would also be grey as would be updates of those objects? (That would be the classical IU scheme in my understanding.)

I should read the Vechev paper though. Is the Shenandoah treatment of new allocations described anywhere for the IU case?

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

PR: https://git.openjdk.org/jdk19/pull/140

From wkemper at openjdk.org  Fri Jul 15 00:48:10 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 15 Jul 2022 00:48:10 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark [v3]
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <qdCzjLRyR6AIzqElt57c-sdnuPfRsepM05n4T2V5co4=.74ea6a21-f907-4859-8316-3c638f6c4c62@github.com>

> Pinned regions were not being coalesced and filled. This fixes a crash observed with the specjbb 2015 benchmark.

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

 - WIP: Slide pinned regions to the front of collection set candidates
   
   There's an off-by-one error here that needs to be fixed.
 - Merge branch 'shenandoah-master' into fill-old-pinned
 - WIP: Add a "unit" test for exercising old pinned region code paths
 - WIP: Start changing mixed collections to handle pinned old regions
 - WIP: Restore ability to interrupt making old regions parseable
 - WIP: Factor filling old out of collection cycle. It needs to happen before bitmap is reset
 - remove TODO comment
 - Coalesce and fill old, pinned regions after old gen final mark

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

Changes: https://git.openjdk.org/shenandoah/pull/149/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=149&range=02
  Stats: 995 lines in 23 files changed: 557 ins; 299 del; 139 mod
  Patch: https://git.openjdk.org/shenandoah/pull/149.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/149/head:pull/149

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

From erik.osterlund at oracle.com  Fri Jul 15 06:04:44 2022
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Fri, 15 Jul 2022 06:04:44 +0000
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <rma7aeqH8nCFraYk1Q3VTs536pKSbEPPd2EuqN6UwOw=.0bb884af-cf0f-4eab-96af-e74992e8888d@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
 <rma7aeqH8nCFraYk1Q3VTs536pKSbEPPd2EuqN6UwOw=.0bb884af-cf0f-4eab-96af-e74992e8888d@github.com>
Message-ID: <68446895-002B-488F-B870-4378AD46BF1C@oracle.com>

Hi Ramki,

If memory serves well, CMS used ?deferred card marking?, to colour allocations into the old generation grey, at a subsequent allocation or in a subsequent safepoint. The important effect of that is that they were coloured grey, before marking terminates, yet importantly after the initializing stores I just described, which would have their barriers elided in C2. So the GC would read the fields after the initializing stores have become visible.

As for Shenandoah IU, I?m not sure if the approach is described somewhere. But my understanding is that instead of first writing a new value to a field, and then handing the address of the field to the GC, so that it can read this new value, Shenandoah hands the new value to the GC directly. So rather than colouring the containing object of the field grey, it colours the new value grey. New allocations are black. And that is fine if you don?t elide barriers on newly allocated objects. If initializing stores elide barriers though, the newly allocated object needs to be asynchronously grey, like CMS (due to deferred card marking for old objects and due to subsequent YC for young objects).

There is AFAICT no such code, and I think the assumption is that elisions are not happening on newly allocated objects, but I think that they are happening, for initializing stores in C2. At least I can?t see what would stop that machinery from removing the barriers.

/Erik

> On 15 Jul 2022, at 01:55, Y.Srinivas Ramakrishna <ysr at openjdk.org> wrote:
> 
> ?On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
> 
>> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature).
>> 
>> Test:
>> - [x] hotspot_gc_shenandoah
>> - [x] jdk_loom with Shenandoah + iu
>> - [x] hotspot_loom with Shenandoah + iu
> 
> CMS collected only old gen, and direct allocations in old gen were grey, and so would updates of black objects in old gen. I assume new objects in Shenandoah would also be grey as would be updates of those objects? (That would be the classical IU scheme in my understanding.)
> 
> I should read the Vechev paper though. Is the Shenandoah treatment of new allocations described anywhere for the IU case?
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk19/pull/140

From rkennke at redhat.com  Fri Jul 15 13:52:56 2022
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 15 Jul 2022 15:52:56 +0200
Subject: [External] : Re: [jdk19] RFR: 8290250: Shenandoah: disable Loom
 for iu mode
In-Reply-To: <C14C6DAD-103F-4602-BD9F-B3F9423F6F2E@oracle.com>
References: <d3c0d11f-a97a-6bca-54de-b07a6aa31ce9@redhat.com>
 <B520249B-3DBF-4752-B089-59207F63E356@oracle.com>
 <5d556173-9092-9ff9-1376-c973841de353@redhat.com>
 <C14C6DAD-103F-4602-BD9F-B3F9423F6F2E@oracle.com>
Message-ID: <f065aebd-4ac2-03cf-7cda-f1343a2b8cba@redhat.com>

Hi Erik,

> Hi Roman,
> 
> We seem to agree that eliding barriers purely on the basis that the containing object of a field is newly allocated, is invalid. But you seem to say that you do not elide barriers on e.g. initializing stores. If that is the case, all is well. However?
> Last time I looked at the store capturing code of C2 for optimizing initializing stores, it emits normal stores with barriers and then in InitializeNode::capture_store it finds stores that are initializing stores for the new object (C), finds and clones the plain store (excluding barriers), and cuts out the old initializing store with IGVN, which should make the IU barrier not ?useful? (only used by dead code), and hence be removed in the useless barrier elimination phase, having the implicit effect of eliding barriers on initializing stores. I think that was indeed the intention of cloning the plain store, and cutting out the old store + barriers. But that isn?t legal with IU. If this works, I don?t see how. Did I miss something?

Ok, this seems indeed problematic.

A way to get rid of it easily would be -XX:-ReduceFieldZeroing, right? 
But I suspect that does more than is needed. I need to think about this 
a little more.

Thanks for pointing this out!

/Roman


> /Erik
> 
>> On 14 Jul 2022, at 22:11, Roman Kennke <rkennke at redhat.com> wrote:
>>
>> ?No wait. The barrier is elided when B is new, but when C is new. This works differently than SATB. Makes sense?
>>
>> Roman
>>
>>
>>> The problem is that when you store the edge from C to B in my example, at step 6, the newly allocated object C is implicitly live, but the new value being written to the field (B) is not implicitly live and needs to be explicitly kept alive in an IU model. But it isn?t if the barrier is elided. This is a difference to SATB where B is also implicitly live due to being part of the snapshot-at-the-beginning, which is why eliding the barrier has no effect with SATB.
>>> /Erik
>>>>> On 14 Jul 2022, at 21:49, Roman Kennke <rkennke at redhat.com> wrote:
>>>>
>>>> ?Hey Erik,
>>>>
>>>> I just had a closer look at the IU barriers again. First of all, we are *not* using the same barriers for IU and SATB. That's why disabling barrier elision does nothing. Instead, we emit a c2 node for the IU barrier, and optimize on that and expand it during barrier expansion pass (together with the LRBs). The barrier consumes and replaces values being stored into fields and array elements. If such a value is provably a newly created object, then we don't need the barrier there - the object is implicitely live already.
>>>>
>>>> Another difference between IU and SATB is that we don't need to keep-alive referents when somebody calls Reference.get() during concurrent marking. If such a referent goes out of scope again, then it's fine trivially. If the referent is stored anywhere, we will catch it with the barrier. If it only remains in a local variable by the end of concurrent marking, we will catch it in final remark. Please punch holes into this reasoning if you find anything. ;-)
>>>>
>>>> Thanks,
>>>> Roman
>>>>
>>>>
>>>>> Hi Roman,
>>>>> The problem isn?t the new object itself. It?s dangling pointers created from it. Sure the new object will be kept alive. The problem is when you store the last reference to *another* object, into a field in the new object, but without barriers that would normally keep that other object alive, as I described in the example. Then you are kind of toast. With SATB anything you stored into the new object is already guaranteed to be kept alive as it is either a new object (implicitly live), or something from the snapshot, which pre-write barriers ensure is fully remembered. The pre-write barrier would only find null which by definition has no business being marked.
>>>>> I will try to explain my example more clearly step by step.
>>>>> 1. There is an object A, reachable from a root of thread T1. A has a field pointing at another object B.
>>>>> 2. Marking starts. A is matked as a root, but before B is marked concurrently?
>>>>> 3. T1 loads B from the field of A.
>>>>> 4. T1 stores null to the field of A. B is now only reachable from a private root of T1, and is not visible to concurrent marking, and storing null did not keep B alive with IU barriers.
>>>>> 5. T1 allocates a new object C. It is implicitly alive and won?t be traced through.
>>>>> 6. T1 stores a reference from C to B. No barriers are used as C is a new object. (This is the illegal part causing a potential crash)
>>>>> 7. The root from T1 to B is discarded.
>>>>> 8. Concurrent marking traces from A but finds only null from step 4.
>>>>> 9. Marking terminates.
>>>>> You now have a dangling pointer from C to B that has not been marked through, and the marking has terminated. As I said, the elision in CMS was only valid because the entire young generation was traced again when old marking terminates, which would have found the reference from C to B, and kept it alive. But you don?t do that, so it seems like it will crash instead. That?s why store barrier elision on newly allocated objects in general is seemingly unsound with Shenandoah IU mode.
>>>>> Hope this helps.
>>>>> /Erik
>>>>>>> On 14 Jul 2022, at 20:21, Roman Kennke <rkennke at openjdk.org> wrote:
>>>>>>
>>>>>> ?On Thu, 14 Jul 2022 17:40:27 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:
>>>>>>
>>>>>>>>> Speaking of IU mode, how does Shenandoah IU mode deal with barrier elision on newly allocated objects? It was only valid in CMS because the entire young generation was traversed when terminating the concurrent marking, so that unvisited pointers could be found.
>>>>>>>>
>>>>>>>>
>>>>>>>> Shenandoah SATB/IU both elide barrier on newly allocated objects. SATB barrier should guarantee they can only refer marked objects. Do I miss anything?
>>>>>>>
>>>>>>> Yes, I believe so. For a SATB collector, it is okay to elide the barrier on newly allocated objects, because they were not part of the snapshot-of-the-beginning, and all new objects are implicitly alive and don't need to be visited.
>>>>>>>
>>>>>>> However, with an IU scheme, that property does not translate.
>>>>>>>
>>>>>>> Consider that you have a particular object graph when marking starts, then one mutator loads an object from the graph, and clears the field such that it is only reachable from the roots of said murator thread. Then the mutator writes the object to a newly allocated object without barriers and discards the root. Now, the reference is only reachable from the newly allocated object.
>>>>>>>
>>>>>>> So for this elision to be valid with IU, the GC has to visit newly allocated objects again before terminating, which e.g. CMS indeed did, by doing a young collection in the safepoint that terminated old marking, but I don't know that Shenandoah does anything like that.
>>>>>>
>>>>>> IIRC, in Shenandoah's IU mode we treat new objects as implicitely alive, much like we do with SATB mode. Therefore it should be good to elide the barriers there. I know that this is not the classical I-U scheme that I believe CMS followed. There has been a paper (I believe it is that paper [1]) that showed that it's orthogonal issues whether we follow new or old references and whether or not we treat new objects alive or not. Treating new objects as live has the advantage that it solves the termination problem.
>>>>>>
>>>>>> [1] https://urldefense.com/v3/__https://www.cs.technion.ac.il/*yahave/papers/pldi06-cgc.pdf__;fg!!ACWV5N9M2RV99hQ!LsTZM-MExdpbuTsR32dxyaa5i0r_hGg6RUCZm_YoqDYChH9oqK-dpzVCb7nD-ZtT0hlRzSgDnXxLrSmkx7Q$
>>>>>> -------------
>>>>>>
>>>>>> PR: https://git.openjdk.org/jdk19/pull/140
>>>>
>>


From zgu at openjdk.org  Fri Jul 15 17:30:14 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 15 Jul 2022 17:30:14 GMT
Subject: RFR: 8290374: Shenandoah: Remove inaccurate comment on
 SBS::load_reference_barrier()
Message-ID: <Q6ayYLf46xm6oscqZyaQjaRvdF2vKkKgfAfoHbEj10Q=.0d9c4025-d045-4066-8fcc-9f6f5ff72581@github.com>

Please review this trivial patch to remove inaccurate comment.

Even with separate mark-compact marking phase, we still need `is_evacuation_in_progress()` check to deal with the scenario that Full GC was upgraded from concurrent/degenerated GC.

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

Commit messages:
 - 8290374: Shenandoah: Remove inaccurate comment on SBS::load_reference_barrier()

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

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

From zgu at openjdk.org  Fri Jul 15 17:45:11 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Fri, 15 Jul 2022 17:45:11 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
Message-ID: <7AMezvvM8ja-VCJl-ZI_1J5ssxgHhdS0tq6S4IWn4jc=.67d4b473-0d63-46c0-83c5-4d49686caa45@github.com>

On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature).
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom with Shenandoah + iu
> - [x] hotspot_loom with Shenandoah + iu

The problem is beyond C2, `Skynet` fails with -`Xint`:


Referenced from:
  interior location: 0x00000000e4de6df0
  0x00000000e4de6dc8 - klass 0x0000000800036ec0 jdk.internal.vm.StackChunk
        allocated after mark start
    not after update watermark
        marked strong
        marked weak
    not in collection set
  mark: mark(is_neutral no_hash age=0)
  region: | 1335|R  |BTE     e4dc0000,     e4e00000,     e4e00000|TAMS     e4dc0000|UWM     e4e00000|U   256K|T   256K|G     0B|S     0B|L   256K|CP   0

Object:
  0x00000000e4c2e2b0 - klass 0x0000000800036ec0 jdk.internal.vm.StackChunk
    not allocated after mark start
    not after update watermark
    not marked strong
    not marked weak
    not in collection set
  mark: mark(is_neutral no_hash age=0)
  region: | 1328|R  |BTE     e4c00000,     e4c40000,     e4c40000|TAMS     e4c40000|UWM     e4c40000|U   256K|T   256K|G     0B|S     0B|L 93264B|CP   0

Forwardee:
  (the object itself)


So, it seems that IU mode either misses iu barrier on load or we need to treat new object as grey.

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

PR: https://git.openjdk.org/jdk19/pull/140

From erik.osterlund at oracle.com  Fri Jul 15 21:37:48 2022
From: erik.osterlund at oracle.com (Erik Osterlund)
Date: Fri, 15 Jul 2022 21:37:48 +0000
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <7AMezvvM8ja-VCJl-ZI_1J5ssxgHhdS0tq6S4IWn4jc=.67d4b473-0d63-46c0-83c5-4d49686caa45@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
 <7AMezvvM8ja-VCJl-ZI_1J5ssxgHhdS0tq6S4IWn4jc=.67d4b473-0d63-46c0-83c5-4d49686caa45@github.com>
Message-ID: <5816BFC1-D2E7-4D23-9F50-C38D3C69E63F@oracle.com>

Hi Zhengyu,

I suppose requires_barriers needs to return true when marking is active with IU, as you need barriers even on newly allocated objects then, as I was discussing.

/Erik

> On 15 Jul 2022, at 19:45, Zhengyu Gu <zgu at openjdk.org> wrote:
> 
> ?On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:
> 
>> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature).
>> 
>> Test:
>> - [x] hotspot_gc_shenandoah
>> - [x] jdk_loom with Shenandoah + iu
>> - [x] hotspot_loom with Shenandoah + iu
> 
> The problem is beyond C2, `Skynet` fails with -`Xint`:
> 
> 
> Referenced from:
>  interior location: 0x00000000e4de6df0
>  0x00000000e4de6dc8 - klass 0x0000000800036ec0 jdk.internal.vm.StackChunk
>        allocated after mark start
>    not after update watermark
>        marked strong
>        marked weak
>    not in collection set
>  mark: mark(is_neutral no_hash age=0)
>  region: | 1335|R  |BTE     e4dc0000,     e4e00000,     e4e00000|TAMS     e4dc0000|UWM     e4e00000|U   256K|T   256K|G     0B|S     0B|L   256K|CP   0
> 
> Object:
>  0x00000000e4c2e2b0 - klass 0x0000000800036ec0 jdk.internal.vm.StackChunk
>    not allocated after mark start
>    not after update watermark
>    not marked strong
>    not marked weak
>    not in collection set
>  mark: mark(is_neutral no_hash age=0)
>  region: | 1328|R  |BTE     e4c00000,     e4c40000,     e4c40000|TAMS     e4c40000|UWM     e4c40000|U   256K|T   256K|G     0B|S     0B|L 93264B|CP   0
> 
> Forwardee:
>  (the object itself)
> 
> 
> So, it seems that IU mode either misses iu barrier on load or we need to treat new object as grey.
> 
> -------------
> 
> PR: https://git.openjdk.org/jdk19/pull/140

From jwilhelm at openjdk.org  Sat Jul 16 12:36:44 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sat, 16 Jul 2022 12:36:44 GMT
Subject: RFR: Merge jdk19
Message-ID: <jvUKm0p7HP4OHMNZ4M6L2SeS8AoOm-1MwMa0-rFqH8Y=.848544d6-fb88-48f5-8a49-2310a413576f@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8281969: Bad result for the snippet @link tag if substring/regex consists of whitespace
 - 8290250: Shenandoah: disable Loom for iu mode
 - 8290252: Add TEST.properties to java/nio/channels/FileChannel and move tests out of largeMemory sub-dir

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9526&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9526&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9526/files
  Stats: 68 lines in 7 files changed: 34 ins; 12 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/9526.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9526/head:pull/9526

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

From jwilhelm at openjdk.org  Sun Jul 17 15:15:03 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Sun, 17 Jul 2022 15:15:03 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <jvUKm0p7HP4OHMNZ4M6L2SeS8AoOm-1MwMa0-rFqH8Y=.848544d6-fb88-48f5-8a49-2310a413576f@github.com>
References: <jvUKm0p7HP4OHMNZ4M6L2SeS8AoOm-1MwMa0-rFqH8Y=.848544d6-fb88-48f5-8a49-2310a413576f@github.com>
Message-ID: <a1hgBvqHoSm90BDxFNA0bTpwHggUXLXc3germYs3B-0=.b7672865-df29-45b5-b613-20ba7bbd3759@github.com>

On Sat, 16 Jul 2022 12:26:23 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 522b6574
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/522b65743ca10fcba0a27d25b8fa11319999e228
Stats:     68 lines in 7 files changed: 34 ins; 12 del; 22 mod

Merge

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

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

From zgu at openjdk.org  Sun Jul 17 23:55:13 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Sun, 17 Jul 2022 23:55:13 GMT
Subject: [jdk19] RFR: 8290250: Shenandoah: disable Loom for iu mode
In-Reply-To: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
References: <BiXn1Cj6z4rcyqO1h2phmi41jAQhcg7xV6RUkgIXqBs=.61cc5e29-718c-4585-a919-edcf35e532d3@github.com>
Message-ID: <_pU_wj7BaFUmMUyWClA7R8zby8Yqg74mcC_NLfLLyJE=.97ac9d30-6612-4f12-adb8-e265bf4b17ea@github.com>

On Wed, 13 Jul 2022 18:39:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to disable Loom for Shenandoah iu mode (an experimental feature).
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] jdk_loom with Shenandoah + iu
> - [x] hotspot_loom with Shenandoah + iu

> _Mailing list message from [Erik Osterlund](mailto:erik.osterlund at oracle.com) on [shenandoah-dev](mailto:shenandoah-dev at mail.openjdk.org):_
> 
> Hi Zhengyu,
> 
> I suppose requires_barriers needs to return true when marking is active with IU, as you need barriers even on newly allocated objects then, as I was discussing.
> 
> /Erik

Tried that, still not working.
I can not see how it can be Loom specific? but seems it's only exposed by `Skynet`

Thanks,

-Zhengyu

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

PR: https://git.openjdk.org/jdk19/pull/140

From rkennke at openjdk.org  Mon Jul 18 11:31:48 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Mon, 18 Jul 2022 11:31:48 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
 [v3]
In-Reply-To: <RrFde7Ie5q8ZNUyx2sYiUYWgi0NJ4sTzfhK5-jM8P_U=.a2d478fb-87bb-4a9d-a8ff-f0e1d726e7a7@github.com>
References: <twT4id6GxkSRpq_5fKbNw-E4QZa47FpodcmmmQFewIE=.5201e256-99fd-494c-99fa-0d7b172de5f0@github.com>
 <RrFde7Ie5q8ZNUyx2sYiUYWgi0NJ4sTzfhK5-jM8P_U=.a2d478fb-87bb-4a9d-a8ff-f0e1d726e7a7@github.com>
Message-ID: <SB64QFEaeAy8_hhRS7q-DGjA8vEXJDyhU7gVyhaUJfE=.1b32202a-3bb1-40fd-a610-8bb30d6099bb@github.com>

On Thu, 14 Jul 2022 15:57:17 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Please review this patch to fix Loom test crash with Shenandoah IU mode.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>> - [x] jdk_loom with Shenandoah + IU
>> - [x] hotspot_loom with Shenandoah + IU
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Always requires barrier for IU

Looks good to me.

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

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

From zgu at openjdk.org  Mon Jul 18 12:42:00 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 18 Jul 2022 12:42:00 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
 [v3]
In-Reply-To: <SB64QFEaeAy8_hhRS7q-DGjA8vEXJDyhU7gVyhaUJfE=.1b32202a-3bb1-40fd-a610-8bb30d6099bb@github.com>
References: <twT4id6GxkSRpq_5fKbNw-E4QZa47FpodcmmmQFewIE=.5201e256-99fd-494c-99fa-0d7b172de5f0@github.com>
 <RrFde7Ie5q8ZNUyx2sYiUYWgi0NJ4sTzfhK5-jM8P_U=.a2d478fb-87bb-4a9d-a8ff-f0e1d726e7a7@github.com>
 <SB64QFEaeAy8_hhRS7q-DGjA8vEXJDyhU7gVyhaUJfE=.1b32202a-3bb1-40fd-a610-8bb30d6099bb@github.com>
Message-ID: <cD6g15CtZ64cw4K-87j0FLcK96lWTDsUvQi9VSGKbGg=.b214f6bb-a2e2-47e4-9760-da15a17b24ac@github.com>

On Mon, 18 Jul 2022 11:28:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Looks good to me.

I closed it. Unfortunately, the fix can still fail ...

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

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

From zgu at openjdk.org  Mon Jul 18 13:10:05 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 18 Jul 2022 13:10:05 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v6]
In-Reply-To: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
Message-ID: <vDe0QsmCLYZyWkfmbZdPdznCP1timTvYcRloKSpfhcQ=.9e7f848a-b47c-4205-85bf-808438f6dda8@github.com>

> ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated.
> 
> Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah

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

 - Merge branch 'master' into JDK-8287805-evac-updt-closures
 - Move get thread closer to the use
 - Aleksey's comment
 - Aleksey's comment
 - Merge branch 'master' into JDK-8287805-evac-updt-closures
 - v1
 - Remove unused impl
 - Review feedback
 - Merge branch 'master' into JDK-8287805-evac-updt-closures
 - 8287805: Shenandoah: consolidate evacuate-update-root closures
 - ... and 3 more: https://git.openjdk.org/jdk/compare/3fc125de...8c12588d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9023/files
  - new: https://git.openjdk.org/jdk/pull/9023/files/44f50839..8c12588d

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

  Stats: 98651 lines in 2162 files changed: 52824 ins; 28883 del; 16944 mod
  Patch: https://git.openjdk.org/jdk/pull/9023.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9023/head:pull/9023

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

From shade at openjdk.org  Mon Jul 18 13:10:05 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Jul 2022 13:10:05 GMT
Subject: RFR: 8287805: Shenandoah: consolidate evacuate-update-root
 closures [v6]
In-Reply-To: <vDe0QsmCLYZyWkfmbZdPdznCP1timTvYcRloKSpfhcQ=.9e7f848a-b47c-4205-85bf-808438f6dda8@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
 <vDe0QsmCLYZyWkfmbZdPdznCP1timTvYcRloKSpfhcQ=.9e7f848a-b47c-4205-85bf-808438f6dda8@github.com>
Message-ID: <jeDOHioWhD94nFLnyg9HNwXrQgck8xdV2CZF0k6bwCo=.801a6abd-7907-44ff-bf11-59d4f595ccc3@github.com>

On Mon, 18 Jul 2022 13:05:01 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated.
>> 
>> Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>
> Zhengyu Gu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8287805-evac-updt-closures
>  - Move get thread closer to the use
>  - Aleksey's comment
>  - Aleksey's comment
>  - Merge branch 'master' into JDK-8287805-evac-updt-closures
>  - v1
>  - Remove unused impl
>  - Review feedback
>  - Merge branch 'master' into JDK-8287805-evac-updt-closures
>  - 8287805: Shenandoah: consolidate evacuate-update-root closures
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/3fc125de...8c12588d

Marked as reviewed by shade (Reviewer).

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

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

From zgu at openjdk.org  Mon Jul 18 16:58:02 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Mon, 18 Jul 2022 16:58:02 GMT
Subject: Integrated: 8287805: Shenandoah: consolidate evacuate-update-root
 closures
In-Reply-To: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
References: <TJwL4GZIpMoVBY-yyWOCn_1-tFwvtbJfmKUMFoEtDnI=.68cb7d70-1f27-4347-a3f5-08000a67f4ac@github.com>
Message-ID: <QQNwz6uZGNg4wT-_aPRCGqiG1_S_HL7aXk-ZxOdAg8w=.b7f676d5-c798-494e-b4c3-ef718f74cb85@github.com>

On Fri, 3 Jun 2022 19:00:01 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahEvacuateUpdateMetadataClosure and ShenandoahEvacuateUpdateRootsClosure are mostly same, can be consolidated.
> 
> Also, only uses of ShenandoahEvacuateUpdateMetadataClosure all pass MO_UNORDERED template parameter, so it can be eliminated.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: b2010a74
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2010a748137d17f4968659503e0579ea8558afd
Stats:     113 lines in 4 files changed: 15 ins; 68 del; 30 mod

8287805: Shenandoah: consolidate evacuate-update-root closures

Reviewed-by: shade

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

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

From duke at openjdk.org  Tue Jul 19 22:46:55 2022
From: duke at openjdk.org (Cesar Soares)
Date: Tue, 19 Jul 2022 22:46:55 GMT
Subject: RFR: 8241503: C2: Share MacroAssembler between mach nodes during
 code emission [v4]
In-Reply-To: <3YuxRKFw0wOTbkB3kvVxbggYB4FRRWoHY3xOaD7xOUc=.9c100fcb-14ba-442d-b221-7851a9d8eb75@github.com>
References: <-Q8DJD8lCN4calr3RAAv0vepUN8s_LE00kPPn9GPxNg=.d01d7d7a-c18c-4764-ae75-b15306bc7b3f@github.com>
 <3YuxRKFw0wOTbkB3kvVxbggYB4FRRWoHY3xOaD7xOUc=.9c100fcb-14ba-442d-b221-7851a9d8eb75@github.com>
Message-ID: <KP-yUpOcy7qwY25rQrds6jOZIj33zJ4P8_ypR83zfvo=.d1a67425-b06e-4deb-8c43-c48e17668197@github.com>

On Tue, 14 Jun 2022 03:56:47 GMT, Cesar Soares <duke at openjdk.org> wrote:

>> Hi there, can I please get some reviews on this change? The patch is to make the code reuse the same C2_MacroAssembler object during the emission of CPU instructions of a given compilation.
>> 
>> As you'll see the change affects all backends. I've done my best to keep the changes minimal/simple.
>> 
>> I tested this locally on Linux x86_64, x86_32 and MacOS Arm32, and ARM64.
>> 
>> **I need help testing the changes on PPC, S390, and RISCV**. I cross-compiled the JVM locally and the builds are all succeeding, but I couldn't use an emulator (yet) or any real hardware (no access to one) to test the changes on these platforms. I see that GitHub actions do some tests on S390 and PPC but the tests seem to not be extensive.
>> 
>> Thanks in advance,
>> Cesar
>
> Cesar Soares has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix merge

I'll resolve the conflicts and continue working on this. Any help testing will be appreciated.

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

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

From shade at openjdk.org  Wed Jul 20 12:25:10 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 20 Jul 2022 12:25:10 GMT
Subject: RFR: 8290374: Shenandoah: Remove inaccurate comment on
 SBS::load_reference_barrier()
In-Reply-To: <Q6ayYLf46xm6oscqZyaQjaRvdF2vKkKgfAfoHbEj10Q=.0d9c4025-d045-4066-8fcc-9f6f5ff72581@github.com>
References: <Q6ayYLf46xm6oscqZyaQjaRvdF2vKkKgfAfoHbEj10Q=.0d9c4025-d045-4066-8fcc-9f6f5ff72581@github.com>
Message-ID: <QVqymR-o_W4C_X9ORTBRiLQEuUYkGdTbw7BtkqZmjS0=.9b6fcb13-c9c4-4f39-a50a-81dce35b897f@github.com>

On Fri, 15 Jul 2022 17:17:11 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to remove inaccurate comment.
> 
> Even with separate mark-compact marking phase, we still need `is_evacuation_in_progress()` check to deal with the scenario that Full GC was upgraded from concurrent/degenerated GC.

OK, right. Looks good.

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

Marked as reviewed by shade (Reviewer).

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

From zgu at openjdk.org  Wed Jul 20 12:47:03 2022
From: zgu at openjdk.org (Zhengyu Gu)
Date: Wed, 20 Jul 2022 12:47:03 GMT
Subject: Integrated: 8290374: Shenandoah: Remove inaccurate comment on
 SBS::load_reference_barrier()
In-Reply-To: <Q6ayYLf46xm6oscqZyaQjaRvdF2vKkKgfAfoHbEj10Q=.0d9c4025-d045-4066-8fcc-9f6f5ff72581@github.com>
References: <Q6ayYLf46xm6oscqZyaQjaRvdF2vKkKgfAfoHbEj10Q=.0d9c4025-d045-4066-8fcc-9f6f5ff72581@github.com>
Message-ID: <T4pUN0SJ9LeHLUMmwX6U5I945x3Z2NOCRTOj-Faq5ts=.91d4c147-64dd-4f4c-8930-717e98cc04c2@github.com>

On Fri, 15 Jul 2022 17:17:11 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Please review this trivial patch to remove inaccurate comment.
> 
> Even with separate mark-compact marking phase, we still need `is_evacuation_in_progress()` check to deal with the scenario that Full GC was upgraded from concurrent/degenerated GC.

This pull request has now been integrated.

Changeset: 011958d3
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/011958d30b275f0f6a2de097938ceeb34beb314d
Stats:     7 lines in 1 file changed: 0 ins; 5 del; 2 mod

8290374: Shenandoah: Remove inaccurate comment on SBS::load_reference_barrier()

Reviewed-by: shade

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

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

From kdnilsen at openjdk.org  Wed Jul 20 14:15:45 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 20 Jul 2022 14:15:45 GMT
Subject: Withdrawn: Balance without cancel
In-Reply-To: <_l1IqN_QrbTy3hsL54uJQe4swcli1hnNlh0pL9HI5Uw=.467c66b0-4b21-4fcf-80de-71b11b1beb73@github.com>
References: <_l1IqN_QrbTy3hsL54uJQe4swcli1hnNlh0pL9HI5Uw=.467c66b0-4b21-4fcf-80de-71b11b1beb73@github.com>
Message-ID: <1VEeJpUMwOPQPUSrqovQ3LqQJ3duHeqMaZBaFixWGQM=.31f1a4e9-460e-4375-92bc-516e2d9a6919@github.com>

On Thu, 28 Apr 2022 04:12:58 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This commit does load balancing on remembered set scanning that happens during concurrent marking and during concurrent updating of references.  Experiments show that the concurrency of remembered set marking is now much closer to the number of concurrent GC threads (generally within 5%) whereas before this commit, the level of concurrency was often less than 1/4 of the number of concurrent GC threads.
> 
> An additional fix integrated in this commit is to not scan the entirety of humongous object arrays.  We only scan the portions of these arrays that overlay with dirty cards in the remembered set.

This pull request has been closed without being integrated.

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

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

From eosterlund at openjdk.org  Wed Jul 20 17:01:32 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 20 Jul 2022 17:01:32 GMT
Subject: RFR: 8290700: Optimize AArch64 nmethod entry barriers
Message-ID: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>

The original nmethod entry barrier supported only concurrent patching of data and was used by ZGC to solve concurrent class unloading problems. Now it is starting to see more uses. Notably, loom uses nmethod entry barriers to figure out what nmethods have been seen on-stack, needed to remove nmethods safely. However, the concurrent data patching variation was too slow for loom (showed a few regressions), so I brought over a faster nmethod entry barrier that we use in the generational ZGC repo, which additionally handles concurrent patching of data and instructions, which is needed there. 
However, I still see some small regressions. So for the uses in loom, the classic GCs don't really patch anything interesting concurrently. This leads to the following possible enhancements to improve the situation: 

1. Make a dedicated nmethod entry barrier for GCs that don't patch data nor code concurrently, consisting of basically only a conditional branch. There is no need to penalize STW GCs with seat belts protecting against concurrent races that simply do not exist.

2. Move the "guard" word and call into the VM trampoline, to an out-of-line stub towards the end of the nmethod, ensuring instruction caches are not polluted by non-hot instructions at the nmethod entry. Some machines also better optimize the branch-not-taken path of conditional branches.

With these optimizations, the small regressions did go away.

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

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

Commit messages:
 - 8290700: Optimize AArch64 nmethod entry barriers

Changes: https://git.openjdk.org/jdk/pull/9574/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9574&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290700
  Stats: 178 lines in 14 files changed: 120 ins; 22 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/9574.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9574/head:pull/9574

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

From eosterlund at openjdk.org  Wed Jul 20 17:09:03 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 20 Jul 2022 17:09:03 GMT
Subject: RFR: 8290700: Optimize AArch64 nmethod entry barriers
In-Reply-To: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
References: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
Message-ID: <ZoVVroUiHVtiAcObahHjp1Qszh8LkwUZFckSqC-c7N4=.38b9e374-faf1-4a53-9ec9-0aa38363b07e@github.com>

On Wed, 20 Jul 2022 16:54:53 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The original nmethod entry barrier supported only concurrent patching of data and was used by ZGC to solve concurrent class unloading problems. Now it is starting to see more uses. Notably, loom uses nmethod entry barriers to figure out what nmethods have been seen on-stack, needed to remove nmethods safely. However, the concurrent data patching variation was too slow for loom (showed a few regressions), so I brought over a faster nmethod entry barrier that we use in the generational ZGC repo, which additionally handles concurrent patching of data and instructions, which is needed there. 
> However, I still see some small regressions. So for the uses in loom, the classic GCs don't really patch anything interesting concurrently. This leads to the following possible enhancements to improve the situation: 
> 
> 1. Make a dedicated nmethod entry barrier for GCs that don't patch data nor code concurrently, consisting of basically only a conditional branch. There is no need to penalize STW GCs with seat belts protecting against concurrent races that simply do not exist.
> 
> 2. Move the "guard" word and call into the VM trampoline, to an out-of-line stub towards the end of the nmethod, ensuring instruction caches are not polluted by non-hot instructions at the nmethod entry. Some machines also better optimize the branch-not-taken path of conditional branches.
> 
> With these optimizations, the small regressions did go away.

Note that this PR is dependent on https://github.com/openjdk/jdk/pull/9569/

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

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

From eosterlund at openjdk.org  Fri Jul 22 14:53:43 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 22 Jul 2022 14:53:43 GMT
Subject: RFR: 8290700: Optimize AArch64 nmethod entry barriers [v2]
In-Reply-To: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
References: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
Message-ID: <xx-Xgmk8gCzw4uKAjgpIdHNJhpAmH3ygz7cJMV7Nzvs=.68858b52-8580-407f-acab-a0a757cffec5@github.com>

> The original nmethod entry barrier supported only concurrent patching of data and was used by ZGC to solve concurrent class unloading problems. Now it is starting to see more uses. Notably, loom uses nmethod entry barriers to figure out what nmethods have been seen on-stack, needed to remove nmethods safely. However, the concurrent data patching variation was too slow for loom (showed a few regressions), so I brought over a faster nmethod entry barrier that we use in the generational ZGC repo, which additionally handles concurrent patching of data and instructions, which is needed there. 
> However, I still see some small regressions. So for the uses in loom, the classic GCs don't really patch anything interesting concurrently. This leads to the following possible enhancements to improve the situation: 
> 
> 1. Make a dedicated nmethod entry barrier for GCs that don't patch data nor code concurrently, consisting of basically only a conditional branch. There is no need to penalize STW GCs with seat belts protecting against concurrent races that simply do not exist.
> 
> 2. Move the "guard" word and call into the VM trampoline, to an out-of-line stub towards the end of the nmethod, ensuring instruction caches are not polluted by non-hot instructions at the nmethod entry. Some machines also better optimize the branch-not-taken path of conditional branches.
> 
> With these optimizations, the small regressions did go away.

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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9574/files
  - new: https://git.openjdk.org/jdk/pull/9574/files/58c98ac6..58c98ac6

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

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

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

From eosterlund at openjdk.org  Fri Jul 22 15:09:13 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 22 Jul 2022 15:09:13 GMT
Subject: RFR: 8290700: Optimize AArch64 nmethod entry barriers [v3]
In-Reply-To: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
References: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
Message-ID: <makbHXDht7fiQZTtOZe4qW2PnZUV75XevmIagEiiKkI=.2d781d41-60b3-4f07-926b-66085045e025@github.com>

> The original nmethod entry barrier supported only concurrent patching of data and was used by ZGC to solve concurrent class unloading problems. Now it is starting to see more uses. Notably, loom uses nmethod entry barriers to figure out what nmethods have been seen on-stack, needed to remove nmethods safely. However, the concurrent data patching variation was too slow for loom (showed a few regressions), so I brought over a faster nmethod entry barrier that we use in the generational ZGC repo, which additionally handles concurrent patching of data and instructions, which is needed there. 
> However, I still see some small regressions. So for the uses in loom, the classic GCs don't really patch anything interesting concurrently. This leads to the following possible enhancements to improve the situation: 
> 
> 1. Make a dedicated nmethod entry barrier for GCs that don't patch data nor code concurrently, consisting of basically only a conditional branch. There is no need to penalize STW GCs with seat belts protecting against concurrent races that simply do not exist.
> 
> 2. Move the "guard" word and call into the VM trampoline, to an out-of-line stub towards the end of the nmethod, ensuring instruction caches are not polluted by non-hot instructions at the nmethod entry. Some machines also better optimize the branch-not-taken path of conditional branches.
> 
> With these optimizations, the small regressions did go away.

Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into 8290700_faster_aarch64_entry_barriers
 - 8290700: Optimize AArch64 nmethod entry barriers
 - fixing 32 bit build again
 - fix 32 bit build again
 - 32 bit build fix
 - Optimize x86 nmethod entry barriers

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

Changes: https://git.openjdk.org/jdk/pull/9574/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9574&range=02
  Stats: 179 lines in 14 files changed: 121 ins; 22 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/9574.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9574/head:pull/9574

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

From kvn at openjdk.org  Fri Jul 22 19:13:20 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 22 Jul 2022 19:13:20 GMT
Subject: RFR: 8290700: Optimize AArch64 nmethod entry barriers [v3]
In-Reply-To: <makbHXDht7fiQZTtOZe4qW2PnZUV75XevmIagEiiKkI=.2d781d41-60b3-4f07-926b-66085045e025@github.com>
References: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
 <makbHXDht7fiQZTtOZe4qW2PnZUV75XevmIagEiiKkI=.2d781d41-60b3-4f07-926b-66085045e025@github.com>
Message-ID: <MB-teDZhoilr54GCKaFSNr0U3aFm9s0IoctMJaFzj-Q=.903b430d-f91c-40db-8193-4a158f0c9fe3@github.com>

On Fri, 22 Jul 2022 15:09:13 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The original nmethod entry barrier supported only concurrent patching of data and was used by ZGC to solve concurrent class unloading problems. Now it is starting to see more uses. Notably, loom uses nmethod entry barriers to figure out what nmethods have been seen on-stack, needed to remove nmethods safely. However, the concurrent data patching variation was too slow for loom (showed a few regressions), so I brought over a faster nmethod entry barrier that we use in the generational ZGC repo, which additionally handles concurrent patching of data and instructions, which is needed there. 
>> However, I still see some small regressions. So for the uses in loom, the classic GCs don't really patch anything interesting concurrently. This leads to the following possible enhancements to improve the situation: 
>> 
>> 1. Make a dedicated nmethod entry barrier for GCs that don't patch data nor code concurrently, consisting of basically only a conditional branch. There is no need to penalize STW GCs with seat belts protecting against concurrent races that simply do not exist.
>> 
>> 2. Move the "guard" word and call into the VM trampoline, to an out-of-line stub towards the end of the nmethod, ensuring instruction caches are not polluted by non-hot instructions at the nmethod entry. Some machines also better optimize the branch-not-taken path of conditional branches.
>> 
>> With these optimizations, the small regressions did go away.
>
> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into 8290700_faster_aarch64_entry_barriers
>  - 8290700: Optimize AArch64 nmethod entry barriers
>  - fixing 32 bit build again
>  - fix 32 bit build again
>  - 32 bit build fix
>  - Optimize x86 nmethod entry barriers

Looks reasonable to me.
Someone familiar with aarch64 code have to review it.

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

Marked as reviewed by kvn (Reviewer).

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

From eosterlund at openjdk.org  Fri Jul 22 19:52:01 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Fri, 22 Jul 2022 19:52:01 GMT
Subject: RFR: 8290700: Optimize AArch64 nmethod entry barriers [v3]
In-Reply-To: <MB-teDZhoilr54GCKaFSNr0U3aFm9s0IoctMJaFzj-Q=.903b430d-f91c-40db-8193-4a158f0c9fe3@github.com>
References: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
 <makbHXDht7fiQZTtOZe4qW2PnZUV75XevmIagEiiKkI=.2d781d41-60b3-4f07-926b-66085045e025@github.com>
 <MB-teDZhoilr54GCKaFSNr0U3aFm9s0IoctMJaFzj-Q=.903b430d-f91c-40db-8193-4a158f0c9fe3@github.com>
Message-ID: <IYY4gyiDrTElzxILt_gd75r3uUlUD1nUN4eLj365HUA=.ab201791-8235-4f0c-b1c1-82c2b608d1e6@github.com>

On Fri, 22 Jul 2022 19:09:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into 8290700_faster_aarch64_entry_barriers
>>  - 8290700: Optimize AArch64 nmethod entry barriers
>>  - fixing 32 bit build again
>>  - fix 32 bit build again
>>  - 32 bit build fix
>>  - Optimize x86 nmethod entry barriers
>
> Looks reasonable to me.
> Someone familiar with aarch64 code have to review it.

Thanks for the review, @vnkozlov!

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

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

From dlong at openjdk.org  Fri Jul 22 20:09:15 2022
From: dlong at openjdk.org (Dean Long)
Date: Fri, 22 Jul 2022 20:09:15 GMT
Subject: RFR: 8290700: Optimize AArch64 nmethod entry barriers [v3]
In-Reply-To: <makbHXDht7fiQZTtOZe4qW2PnZUV75XevmIagEiiKkI=.2d781d41-60b3-4f07-926b-66085045e025@github.com>
References: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
 <makbHXDht7fiQZTtOZe4qW2PnZUV75XevmIagEiiKkI=.2d781d41-60b3-4f07-926b-66085045e025@github.com>
Message-ID: <e6_CY7_mKozmJYZAOrUINvI4pHweAY2Sb2ojEDBuXXI=.aba5b721-39fa-47b8-b8ea-b3c5223a5061@github.com>

On Fri, 22 Jul 2022 15:09:13 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> The original nmethod entry barrier supported only concurrent patching of data and was used by ZGC to solve concurrent class unloading problems. Now it is starting to see more uses. Notably, loom uses nmethod entry barriers to figure out what nmethods have been seen on-stack, needed to remove nmethods safely. However, the concurrent data patching variation was too slow for loom (showed a few regressions), so I brought over a faster nmethod entry barrier that we use in the generational ZGC repo, which additionally handles concurrent patching of data and instructions, which is needed there. 
>> However, I still see some small regressions. So for the uses in loom, the classic GCs don't really patch anything interesting concurrently. This leads to the following possible enhancements to improve the situation: 
>> 
>> 1. Make a dedicated nmethod entry barrier for GCs that don't patch data nor code concurrently, consisting of basically only a conditional branch. There is no need to penalize STW GCs with seat belts protecting against concurrent races that simply do not exist.
>> 
>> 2. Move the "guard" word and call into the VM trampoline, to an out-of-line stub towards the end of the nmethod, ensuring instruction caches are not polluted by non-hot instructions at the nmethod entry. Some machines also better optimize the branch-not-taken path of conditional branches.
>> 
>> With these optimizations, the small regressions did go away.
>
> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into 8290700_faster_aarch64_entry_barriers
>  - 8290700: Optimize AArch64 nmethod entry barriers
>  - fixing 32 bit build again
>  - fix 32 bit build again
>  - 32 bit build fix
>  - Optimize x86 nmethod entry barriers

Marked as reviewed by dlong (Reviewer).

src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp line 85:

> 83:       }
> 84:       ShouldNotReachHere();
> 85:     }

I'm guessing this function is not performance-critical.  If it was, then we could consider adding a new field to the nmethod to keep track of the offset for the guard.

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

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

From eosterlund at openjdk.org  Sat Jul 23 03:05:08 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Sat, 23 Jul 2022 03:05:08 GMT
Subject: RFR: 8290700: Optimize AArch64 nmethod entry barriers [v3]
In-Reply-To: <e6_CY7_mKozmJYZAOrUINvI4pHweAY2Sb2ojEDBuXXI=.aba5b721-39fa-47b8-b8ea-b3c5223a5061@github.com>
References: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
 <makbHXDht7fiQZTtOZe4qW2PnZUV75XevmIagEiiKkI=.2d781d41-60b3-4f07-926b-66085045e025@github.com>
 <e6_CY7_mKozmJYZAOrUINvI4pHweAY2Sb2ojEDBuXXI=.aba5b721-39fa-47b8-b8ea-b3c5223a5061@github.com>
Message-ID: <io5BoKqXXuCPsPl5aJ6z4C5btvOGlSBw5OO_bIyqVoU=.871058fa-1721-42d2-8d20-02fbb46e02d5@github.com>

On Fri, 22 Jul 2022 20:06:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Erik ?sterlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into 8290700_faster_aarch64_entry_barriers
>>  - 8290700: Optimize AArch64 nmethod entry barriers
>>  - fixing 32 bit build again
>>  - fix 32 bit build again
>>  - 32 bit build fix
>>  - Optimize x86 nmethod entry barriers
>
> Marked as reviewed by dlong (Reviewer).

Thanks for the review @dean-long!

> src/hotspot/cpu/aarch64/gc/shared/barrierSetNMethod_aarch64.cpp line 85:
> 
>> 83:       }
>> 84:       ShouldNotReachHere();
>> 85:     }
> 
> I'm guessing this function is not performance-critical.  If it was, then we could consider adding a new field to the nmethod to keep track of the offset for the guard.

Yeah I thought about adding a new entry to CodeOffsets, but it seemed like this C2-only AArch64-only detail seemed a bit noisy in the shared code then. And it didn't seem warranted, given how cold this path is by design.

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

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

From eosterlund at openjdk.org  Mon Jul 25 07:12:49 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 25 Jul 2022 07:12:49 GMT
Subject: Integrated: 8290700: Optimize AArch64 nmethod entry barriers
In-Reply-To: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
References: <je2jnpHqfOEBDK9bTEiqCNaSmqzvaPwoYpwr9ukNTu4=.15113b50-8204-45e0-b234-3a30afb7f07a@github.com>
Message-ID: <PnURENxrFxDrl6DexZuf67h-jbW4XVRmYzNjy_lPD8s=.717d0890-1269-4837-ba1a-b47bbcab57e6@github.com>

On Wed, 20 Jul 2022 16:54:53 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The original nmethod entry barrier supported only concurrent patching of data and was used by ZGC to solve concurrent class unloading problems. Now it is starting to see more uses. Notably, loom uses nmethod entry barriers to figure out what nmethods have been seen on-stack, needed to remove nmethods safely. However, the concurrent data patching variation was too slow for loom (showed a few regressions), so I brought over a faster nmethod entry barrier that we use in the generational ZGC repo, which additionally handles concurrent patching of data and instructions, which is needed there. 
> However, I still see some small regressions. So for the uses in loom, the classic GCs don't really patch anything interesting concurrently. This leads to the following possible enhancements to improve the situation: 
> 
> 1. Make a dedicated nmethod entry barrier for GCs that don't patch data nor code concurrently, consisting of basically only a conditional branch. There is no need to penalize STW GCs with seat belts protecting against concurrent races that simply do not exist.
> 
> 2. Move the "guard" word and call into the VM trampoline, to an out-of-line stub towards the end of the nmethod, ensuring instruction caches are not polluted by non-hot instructions at the nmethod entry. Some machines also better optimize the branch-not-taken path of conditional branches.
> 
> With these optimizations, the small regressions did go away.

This pull request has now been integrated.

Changeset: 228e8e94
Author:    Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/228e8e94fe048e56d5513b150060c9b54f15642c
Stats:     179 lines in 14 files changed: 121 ins; 22 del; 36 mod

8290700: Optimize AArch64 nmethod entry barriers

Reviewed-by: kvn, dlong

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

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

From shade at openjdk.org  Tue Jul 26 19:00:26 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 26 Jul 2022 19:00:26 GMT
Subject: RFR: 8291000: C2: Purge LoadPLocked and Store*Conditional nodes
Message-ID: <awloAUdVcTOma10wG4gpxzvu3Rj89d92JiW4i04JfbU=.1318acb0-f328-46a5-a4cc-83d8ff28edc4@github.com>

The last uses for these nodes was the inline contiguous allocations. With [JDK-8290706](https://bugs.openjdk.org/browse/JDK-8290706), these nodes are not used anymore and can be cleaned up.

Testing:
 - [x] Linux x86_64 fastdebug tier1
 - [ ] Linux x86_32 fastdebug tier1
 - [ ] Linux AArch64 fastdebug tier1
 - [x] Linux x86_64 Zero build
 - [x] Linux AArch64 cross-build
 - [x] Linux ARM cross-build
 - [x] Linux S390X cross-build
 - [x] Linux PPC64 cross-build
 - [x] Linux RISC-V cross-build

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

Commit messages:
 - Fix

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

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

From andrew at openjdk.org  Tue Jul 26 19:05:31 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 26 Jul 2022 19:05:31 GMT
Subject: RFR: 8253424: Add support for running pre-submit testing using
 GitHub Actions [v2]
In-Reply-To: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
References: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
Message-ID: <hWpmNR0NrE6Z1whxVWAZ48mlDvNP1OUktMcDj_Uev1M=.0794e79d-95d6-4e13-b229-ffdb2d941151@github.com>

> Hi all,
> 
> This pull request contains a backport of commit [10029f78](https://github.com/openjdk/jdk8u-dev/commit/10029f784ef7be458a7b6ff3cc21649ff0abb6f3) from the [openjdk/jdk8u-dev](https://git.openjdk.java.net/jdk8u-dev) repository, which enables GitHub Actions for the Shenandoah 8u fork.
> 
> The commit being backported was authored by Andrew John Hughes on 6 Apr 2022 and was reviewed by Severin Gehwolf.
> 
> Thanks!

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

 - Merge remote-tracking branch 'origin/master' into JDK-8253424
 - Merge remote-tracking branch 'origin/master' into JDK-8253424
 - 8241768: git needs .gitattributes
   
   Reviewed-by: erikj, jvernee, ehelin
 - Remove specification of minor version and package release data from GCC dependency
 - Fix JCheck tag regex
 - Backport 10029f784ef7be458a7b6ff3cc21649ff0abb6f3

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

Changes:
  - all: https://git.openjdk.org/shenandoah-jdk8u/pull/3/files
  - new: https://git.openjdk.org/shenandoah-jdk8u/pull/3/files/0017a541..1cc5b2be

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

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/3

From andrew at openjdk.org  Tue Jul 26 19:05:31 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 26 Jul 2022 19:05:31 GMT
Subject: RFR: 8253424: Add support for running pre-submit testing using
 GitHub Actions
In-Reply-To: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
References: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
Message-ID: <2BWBHQ4CLkdEQ4GE62igS92lEptrydSB0XeANtL_GL0=.2f279aa2-8a25-4e45-b78d-15c58f6e113a@github.com>

On Sun, 17 Apr 2022 15:12:42 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [10029f78](https://github.com/openjdk/jdk8u-dev/commit/10029f784ef7be458a7b6ff3cc21649ff0abb6f3) from the [openjdk/jdk8u-dev](https://git.openjdk.java.net/jdk8u-dev) repository, which enables GitHub Actions for the Shenandoah 8u fork.
> 
> The commit being backported was authored by Andrew John Hughes on 6 Apr 2022 and was reviewed by Severin Gehwolf.
> 
> Thanks!

@rkennke @shade could one of you review this please? It's a pretty straight-forward backport of the 8u changes to setup GitHub Actions so we can run build tests on merges of 8u332 & 8u342. Thanks.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/3

From eosterlund at openjdk.org  Tue Jul 26 19:15:30 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 26 Jul 2022 19:15:30 GMT
Subject: RFR: 8291000: C2: Purge LoadPLocked and Store*Conditional nodes
In-Reply-To: <awloAUdVcTOma10wG4gpxzvu3Rj89d92JiW4i04JfbU=.1318acb0-f328-46a5-a4cc-83d8ff28edc4@github.com>
References: <awloAUdVcTOma10wG4gpxzvu3Rj89d92JiW4i04JfbU=.1318acb0-f328-46a5-a4cc-83d8ff28edc4@github.com>
Message-ID: <PFJXALZqZCTMzFFRE_KYL-ZlmIXfbBHNBX9bma4arMU=.d159a295-9502-4b33-a6b5-6f35ffc4f845@github.com>

On Tue, 26 Jul 2022 07:13:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The last uses for these nodes was the inline contiguous allocations. With [JDK-8290706](https://bugs.openjdk.org/browse/JDK-8290706), these nodes are not used anymore and can be cleaned up.
> 
> Testing:
>  - [x] Linux x86_64 fastdebug tier1
>  - [ ] Linux x86_32 fastdebug tier1
>  - [ ] Linux AArch64 fastdebug tier1
>  - [x] Linux x86_64 Zero build
>  - [x] Linux AArch64 cross-build
>  - [x] Linux ARM cross-build
>  - [x] Linux S390X cross-build
>  - [x] Linux PPC64 cross-build
>  - [x] Linux RISC-V cross-build

Nice change. Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

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

From kvn at openjdk.org  Tue Jul 26 20:03:17 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 26 Jul 2022 20:03:17 GMT
Subject: RFR: 8291000: C2: Purge LoadPLocked and Store*Conditional nodes
In-Reply-To: <awloAUdVcTOma10wG4gpxzvu3Rj89d92JiW4i04JfbU=.1318acb0-f328-46a5-a4cc-83d8ff28edc4@github.com>
References: <awloAUdVcTOma10wG4gpxzvu3Rj89d92JiW4i04JfbU=.1318acb0-f328-46a5-a4cc-83d8ff28edc4@github.com>
Message-ID: <piX_kTyjs_x7xzUxFO2YEzsYR_WsLbVqf-6hvUxonGc=.3909c26b-e365-4c84-b8fd-146c2d76be79@github.com>

On Tue, 26 Jul 2022 07:13:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The last uses for these nodes was the inline contiguous allocations. With [JDK-8290706](https://bugs.openjdk.org/browse/JDK-8290706), these nodes are not used anymore and can be cleaned up.
> 
> Testing:
>  - [x] Linux x86_64 fastdebug tier1
>  - [x] Linux x86_32 fastdebug tier1
>  - [ ] Linux AArch64 fastdebug tier1
>  - [x] Linux x86_64 Zero build
>  - [x] Linux AArch64 cross-build
>  - [x] Linux ARM cross-build
>  - [x] Linux S390X cross-build
>  - [x] Linux PPC64 cross-build
>  - [x] Linux RISC-V cross-build

Good.

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

Marked as reviewed by kvn (Reviewer).

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

From shade at openjdk.org  Wed Jul 27 16:06:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Jul 2022 16:06:11 GMT
Subject: RFR: 8253424: Add support for running pre-submit testing using
 GitHub Actions [v2]
In-Reply-To: <hWpmNR0NrE6Z1whxVWAZ48mlDvNP1OUktMcDj_Uev1M=.0794e79d-95d6-4e13-b229-ffdb2d941151@github.com>
References: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
 <hWpmNR0NrE6Z1whxVWAZ48mlDvNP1OUktMcDj_Uev1M=.0794e79d-95d6-4e13-b229-ffdb2d941151@github.com>
Message-ID: <4R7n1LH3iSUD5KqMYcMN-cSluaNAB4kt9P2W0Ic-A4Y=.35386ce5-b7df-417d-96dc-d62ba259e8c3@github.com>

On Tue, 26 Jul 2022 19:05:31 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

>> Hi all,
>> 
>> This pull request contains a backport of commit [10029f78](https://github.com/openjdk/jdk8u-dev/commit/10029f784ef7be458a7b6ff3cc21649ff0abb6f3) from the [openjdk/jdk8u-dev](https://git.openjdk.java.net/jdk8u-dev) repository, which enables GitHub Actions for the Shenandoah 8u fork.
>> 
>> The commit being backported was authored by Andrew John Hughes on 6 Apr 2022 and was reviewed by Severin Gehwolf.
>> 
>> Thanks!
>
> Andrew John Hughes has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8253424
>  - Merge remote-tracking branch 'origin/master' into JDK-8253424
>  - 8241768: git needs .gitattributes
>    
>    Reviewed-by: erikj, jvernee, ehelin
>  - Remove specification of minor version and package release data from GCC dependency
>  - Fix JCheck tag regex
>  - Backport 10029f784ef7be458a7b6ff3cc21649ff0abb6f3

Well, I don't see it running cleanly, so there seems to be no point in pushing it just yet. Was that intermittent? Can we run the GHA again for this PR?

There is also `.github/workflows/freetype.vcxproj` file in this PR, which seems superfluous.

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/3

From shade at openjdk.org  Wed Jul 27 17:26:05 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 27 Jul 2022 17:26:05 GMT
Subject: RFR: 8291000: C2: Purge LoadPLocked and Store*Conditional nodes
In-Reply-To: <awloAUdVcTOma10wG4gpxzvu3Rj89d92JiW4i04JfbU=.1318acb0-f328-46a5-a4cc-83d8ff28edc4@github.com>
References: <awloAUdVcTOma10wG4gpxzvu3Rj89d92JiW4i04JfbU=.1318acb0-f328-46a5-a4cc-83d8ff28edc4@github.com>
Message-ID: <b5LcJdZLzeFhN1HeO2VVpV9UcClsIwluiVtBAY2gHdI=.091713ed-48e5-4fe0-99b2-a646ca254568@github.com>

On Tue, 26 Jul 2022 07:13:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The last uses for these nodes was the inline contiguous allocations. With [JDK-8290706](https://bugs.openjdk.org/browse/JDK-8290706), these nodes are not used anymore and can be cleaned up.
> 
> Testing:
>  - [x] Linux x86_64 fastdebug tier1
>  - [x] Linux x86_32 fastdebug tier1
>  - [x] Linux AArch64 fastdebug tier1
>  - [x] Linux x86_64 Zero build
>  - [x] Linux AArch64 cross-build
>  - [x] Linux ARM cross-build
>  - [x] Linux S390X cross-build
>  - [x] Linux PPC64 cross-build
>  - [x] Linux RISC-V cross-build

Thank you, I'll be integrating soon, if there are no objections.

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

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

From kdnilsen at openjdk.org  Wed Jul 27 19:55:47 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 27 Jul 2022 19:55:47 GMT
Subject: RFR: Load balance remembered set scanning
Message-ID: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>

This branch divides remembered set scanning into smaller units of work so that multiple cores can more effectively share the workload between them.  The benefit is to reduce concurrent scan remembered set times and to increase the parallelism of this phase.

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

Commit messages:
 - Fix white space
 - Load balance remembered set scanning

Changes: https://git.openjdk.org/shenandoah/pull/153/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=153&range=00
  Stats: 649 lines in 8 files changed: 543 ins; 54 del; 52 mod
  Patch: https://git.openjdk.org/shenandoah/pull/153.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/153/head:pull/153

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

From wkemper at openjdk.org  Wed Jul 27 21:17:36 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 27 Jul 2022 21:17:36 GMT
Subject: RFR: Load balance remembered set scanning
In-Reply-To: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
Message-ID: <4QrJsnzwZOO8bue-bU0uxIIfYVgS1aZ6DMt3JOdqhIE=.a901353e-79e2-40c2-a79b-eb80517321a0@github.com>

On Wed, 27 Jul 2022 19:38:05 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This branch divides remembered set scanning into smaller units of work so that multiple cores can more effectively share the workload between them.  The benefit is to reduce concurrent scan remembered set times and to increase the parallelism of this phase.

Why do we want to group chunks? Why not let the worker threads grab chunks on a first-come-first-serve basis?

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 274:

> 272: }
> 273: 
> 274: ShenandoahRegionChunkIterator::ShenandoahRegionChunkIterator(ShenandoahHeap* heap, size_t worker_count) :

Can we use [constructor delegation](https://en.wikipedia.org/wiki/C++11#Object_construction_improvement) here to remove some duplicated code? Or could we just have clients always pass in the heap reference? One constructor is missing an assert.

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 1025:

> 1023: };
> 1024: 
> 1025: typedef struct ChunkOfRegion {

Why `typedef`? Could this just be `struct ShenandoahRegionChunk`?

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

Changes requested by wkemper (Committer).

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

From shade at openjdk.org  Thu Jul 28 08:20:07 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 28 Jul 2022 08:20:07 GMT
Subject: Integrated: 8291000: C2: Purge LoadPLocked and Store*Conditional nodes
In-Reply-To: <awloAUdVcTOma10wG4gpxzvu3Rj89d92JiW4i04JfbU=.1318acb0-f328-46a5-a4cc-83d8ff28edc4@github.com>
References: <awloAUdVcTOma10wG4gpxzvu3Rj89d92JiW4i04JfbU=.1318acb0-f328-46a5-a4cc-83d8ff28edc4@github.com>
Message-ID: <Fyx4AUzyg-TTqGTGsKXOM3bq6dMcBJD91pCiJWoyfCw=.ae2b7b3e-c0a8-4ed5-8d8d-0d39e2295a57@github.com>

On Tue, 26 Jul 2022 07:13:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The last uses for these nodes was the inline contiguous allocations. With [JDK-8290706](https://bugs.openjdk.org/browse/JDK-8290706), these nodes are not used anymore and can be cleaned up.
> 
> Testing:
>  - [x] Linux x86_64 fastdebug tier1
>  - [x] Linux x86_32 fastdebug tier1
>  - [x] Linux AArch64 fastdebug tier1
>  - [x] Linux x86_64 Zero build
>  - [x] Linux AArch64 cross-build
>  - [x] Linux ARM cross-build
>  - [x] Linux S390X cross-build
>  - [x] Linux PPC64 cross-build
>  - [x] Linux RISC-V cross-build

This pull request has now been integrated.

Changeset: dd69a68d
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd69a68d095a67b6ea1479d05285dd8be50bfbf2
Stats:     556 lines in 17 files changed: 0 ins; 552 del; 4 mod

8291000: C2: Purge LoadPLocked and Store*Conditional nodes

Reviewed-by: eosterlund, kvn

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

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

From kdnilsen at openjdk.org  Thu Jul 28 19:18:20 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Jul 2022 19:18:20 GMT
Subject: RFR: Load balance remembered set scanning [v2]
In-Reply-To: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
Message-ID: <JcpQhSgCKB3R6GTg8T-zU8xzfKPBo4RIpBN6sQIGamY=.95b956bc-3b72-4a93-b952-b6ffbf917fa4@github.com>

> This branch divides remembered set scanning into smaller units of work so that multiple cores can more effectively share the workload between them.  The benefit is to reduce concurrent scan remembered set times and to increase the parallelism of this phase.

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

  Respond to reviewer comments

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/153/files
  - new: https://git.openjdk.org/shenandoah/pull/153/files/0587940d..6b51cbf3

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

  Stats: 35 lines in 4 files changed: 4 ins; 24 del; 7 mod
  Patch: https://git.openjdk.org/shenandoah/pull/153.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/153/head:pull/153

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

From kdnilsen at openjdk.org  Thu Jul 28 19:18:21 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Jul 2022 19:18:21 GMT
Subject: RFR: Load balance remembered set scanning [v2]
In-Reply-To: <4QrJsnzwZOO8bue-bU0uxIIfYVgS1aZ6DMt3JOdqhIE=.a901353e-79e2-40c2-a79b-eb80517321a0@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <4QrJsnzwZOO8bue-bU0uxIIfYVgS1aZ6DMt3JOdqhIE=.a901353e-79e2-40c2-a79b-eb80517321a0@github.com>
Message-ID: <SCwjQaSuL_ncOESZm9auYCwviZlcoEIR9JGiZ58Zp8k=.89865611-a3ec-4079-8883-252a5c025aab@github.com>

On Wed, 27 Jul 2022 21:07:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to reviewer comments
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 274:
> 
>> 272: }
>> 273: 
>> 274: ShenandoahRegionChunkIterator::ShenandoahRegionChunkIterator(ShenandoahHeap* heap, size_t worker_count) :
> 
> Can we use [constructor delegation](https://en.wikipedia.org/wiki/C++11#Object_construction_improvement) here to remove some duplicated code? Or could we just have clients always pass in the heap reference? One constructor is missing an assert.

Thanks for this suggestion.  I've removed body of one constructor and replaced with constructor delegation.

> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.hpp line 1025:
> 
>> 1023: };
>> 1024: 
>> 1025: typedef struct ChunkOfRegion {
> 
> Why `typedef`? Could this just be `struct ShenandoahRegionChunk`?

Ok.  I've eliminated the typedef and replaced everywhere with struct ShenandoahRegionChunk.

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

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

From kdnilsen at openjdk.org  Thu Jul 28 19:19:55 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Jul 2022 19:19:55 GMT
Subject: RFR: Load balance remembered set scanning
In-Reply-To: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
Message-ID: <thC5nCcARzOiT_rWzrCmyre_-BDykTDWmen8sfAKfJg=.c6922064-696e-4cc1-b185-d5fb710a7aeb@github.com>

On Wed, 27 Jul 2022 19:38:05 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This branch divides remembered set scanning into smaller units of work so that multiple cores can more effectively share the workload between them.  The benefit is to reduce concurrent scan remembered set times and to increase the parallelism of this phase.

The reason to "group chunks" is to reduce the need for synchronized coordination between worker threads.  Dividing work into entire ShenandoahHeapRegions seems to work fairly well for some workloads.  The idea is to start out each remembered set scan effort with work assignments that are a "large number" chunks.  Then, as we get closer to the end of the total scanning effort, we began dividing the worker into smaller and smaller assignments.  This way, a thread that gets an early "dense" work assignment might only complete that single heavy assignment while other worker threads can each complete a large number of lighter worker assignments.

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

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

From kdnilsen at openjdk.org  Thu Jul 28 19:23:29 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 28 Jul 2022 19:23:29 GMT
Subject: RFR: Load balance remembered set scanning [v2]
In-Reply-To: <JcpQhSgCKB3R6GTg8T-zU8xzfKPBo4RIpBN6sQIGamY=.95b956bc-3b72-4a93-b952-b6ffbf917fa4@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <JcpQhSgCKB3R6GTg8T-zU8xzfKPBo4RIpBN6sQIGamY=.95b956bc-3b72-4a93-b952-b6ffbf917fa4@github.com>
Message-ID: <gZ9vIYoBuHstwRKl5EvIqrmr-qI4fRGEclN6TGrZFVk=.7ba90533-5e9b-4172-a0e4-6791e8c4bf4f@github.com>

On Thu, 28 Jul 2022 19:18:20 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This branch divides remembered set scanning into smaller units of work so that multiple cores can more effectively share the workload between them.  The benefit is to reduce concurrent scan remembered set times and to increase the parallelism of this phase.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to reviewer comments

I should also emphasize that there are other benefits besides reduced coordination overhead to scanning larger numbers of chunks at a time.  For example, the code that Ramki is working on can cache the starting location of a large object that spans multiple chunks most easily if the starting location is within the range of its current work assignment.

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

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

From wkemper at openjdk.org  Fri Jul 29 17:40:34 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 29 Jul 2022 17:40:34 GMT
Subject: RFR: Load balance remembered set scanning [v2]
In-Reply-To: <JcpQhSgCKB3R6GTg8T-zU8xzfKPBo4RIpBN6sQIGamY=.95b956bc-3b72-4a93-b952-b6ffbf917fa4@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <JcpQhSgCKB3R6GTg8T-zU8xzfKPBo4RIpBN6sQIGamY=.95b956bc-3b72-4a93-b952-b6ffbf917fa4@github.com>
Message-ID: <a8ccha-d9YzuPvL2mB51DDsidWxHMknAWhM6-CYRMB8=.7fdbd330-b986-45b0-83c5-e621ea0749eb@github.com>

On Thu, 28 Jul 2022 19:18:20 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This branch divides remembered set scanning into smaller units of work so that multiple cores can more effectively share the workload between them.  The benefit is to reduce concurrent scan remembered set times and to increase the parallelism of this phase.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to reviewer comments

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

> 2591:               // Future TODO: establish a second remembered set to identify which old-gen regions point to other old-gen
> 2592:               // regions which are in the collection set for a particular mixed evacuation.
> 2593:               if (start_of_range < end_of_range) {

Before this change, we had update references and marking share most of the card scanning code. Is it no longer possible to share the card scanning code as before? Could we put some of this code in the scanner?

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 155:

> 153:   // Last group does the remnant of heap, one _smallest_chunk_size at a time.
> 154:   // Round down.
> 155:   return _heap->num_regions() / 2;

I don't understand this comment. Is this a `TODO` comment? Or should this be `initial_group_size`?

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 216:

> 214:       num_groups++;
> 215: 
> 216:       if (num_groups >= _num_groups) {

This is somewhat confusing to read. Is `num_groups` really `groups_created`? and `_num_groups` a target number of groups?

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

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

From andrew at openjdk.org  Fri Jul 29 20:21:18 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Fri, 29 Jul 2022 20:21:18 GMT
Subject: RFR: 8253424: Add support for running pre-submit testing using
 GitHub Actions [v2]
In-Reply-To: <4R7n1LH3iSUD5KqMYcMN-cSluaNAB4kt9P2W0Ic-A4Y=.35386ce5-b7df-417d-96dc-d62ba259e8c3@github.com>
References: <_BPbOQ3zTilaR_N9QE2q00i5judlRefji0vuQBH4fEc=.a31d54ad-30ff-4236-8c14-f34e93a07da0@github.com>
 <hWpmNR0NrE6Z1whxVWAZ48mlDvNP1OUktMcDj_Uev1M=.0794e79d-95d6-4e13-b229-ffdb2d941151@github.com>
 <4R7n1LH3iSUD5KqMYcMN-cSluaNAB4kt9P2W0Ic-A4Y=.35386ce5-b7df-417d-96dc-d62ba259e8c3@github.com>
Message-ID: <YmKVkscgUIhhQB_b8NNG64p1ScfydTVNXkHg8sXSfJ0=.4c650134-93f3-429c-9d9f-5db5edba23d4@github.com>

On Wed, 27 Jul 2022 16:02:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Well, I don't see it running cleanly, so there seems to be no point in pushing it just yet. Was that intermittent? Can we run the GHA again for this PR?

Thanks for looking.

The Windows failure seems to be an intermittent failure in downloading Visual Studio and indeed it failed only for `release` and not `debug`.  It passed on an earlier run: https://github.com/gnu-andrew/shenandoah-jdk8u/actions/runs/2267320655 and the only recent changes have been to the `.jcheck` configuration.

The MacOS failure is a genuine failure in the Shenandoah 8u code on MacOS. I guess it's never been built there before. I think fixing that is either something to be done in a separate fix (not this backport) or we can decide to just exclude MacOS on Shenandoah 8u.

Failure is:

~~~

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

PR: https://git.openjdk.org/shenandoah-jdk8u/pull/3