From shade at openjdk.org  Mon Aug  1 17:09:44 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 17:09:44 GMT
Subject: RFR: 8291633: Build failures with GCC 11,
 Alpine 3 due to incompatible casts from nullptr
Message-ID: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>

Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. 

They fall into three categories:
  - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does;
  - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it;
  - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead.

Additional testing:
 - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15
 - [ ] Linux x86_64 fastdebug tier1 with GCC 9.3.0

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

Commit messages:
 - More work
 - Fix

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

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

From kdnilsen at openjdk.org  Mon Aug  1 18:08:45 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 1 Aug 2022 18:08:45 GMT
Subject: RFR: Load balance remembered set scanning [v2]
In-Reply-To: <a8ccha-d9YzuPvL2mB51DDsidWxHMknAWhM6-CYRMB8=.7fdbd330-b986-45b0-83c5-e621ea0749eb@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <JcpQhSgCKB3R6GTg8T-zU8xzfKPBo4RIpBN6sQIGamY=.95b956bc-3b72-4a93-b952-b6ffbf917fa4@github.com>
 <a8ccha-d9YzuPvL2mB51DDsidWxHMknAWhM6-CYRMB8=.7fdbd330-b986-45b0-83c5-e621ea0749eb@github.com>
Message-ID: <1t5pGbpuP3drkkENxd6fNkhKUCsHnFiTe6pmIAV21zk=.850fc6a2-5ef2-421c-8054-a239b7b934c4@github.com>

On Fri, 29 Jul 2022 16:51:51 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 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?

I'm adding a comment and changing num_groups local variable to spanned_groups.

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

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

From kdnilsen at openjdk.org  Mon Aug  1 18:19:46 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 1 Aug 2022 18:19:46 GMT
Subject: RFR: Load balance remembered set scanning [v2]
In-Reply-To: <a8ccha-d9YzuPvL2mB51DDsidWxHMknAWhM6-CYRMB8=.7fdbd330-b986-45b0-83c5-e621ea0749eb@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <JcpQhSgCKB3R6GTg8T-zU8xzfKPBo4RIpBN6sQIGamY=.95b956bc-3b72-4a93-b952-b6ffbf917fa4@github.com>
 <a8ccha-d9YzuPvL2mB51DDsidWxHMknAWhM6-CYRMB8=.7fdbd330-b986-45b0-83c5-e621ea0749eb@github.com>
Message-ID: <d2Z8JeqDOD3cnCsk-yjdH1t-WopGF6A1XjxhdUwOMv0=.7ff2de37-6433-4371-bc24-c98bc461fa77@github.com>

On Fri, 29 Jul 2022 16:54:45 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 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`?

I've rewritten the comment here in an attempt to make the intention more clear.

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

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

From kdnilsen at openjdk.org  Mon Aug  1 18:27:33 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 1 Aug 2022 18:27:33 GMT
Subject: RFR: Load balance remembered set scanning [v2]
In-Reply-To: <a8ccha-d9YzuPvL2mB51DDsidWxHMknAWhM6-CYRMB8=.7fdbd330-b986-45b0-83c5-e621ea0749eb@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <JcpQhSgCKB3R6GTg8T-zU8xzfKPBo4RIpBN6sQIGamY=.95b956bc-3b72-4a93-b952-b6ffbf917fa4@github.com>
 <a8ccha-d9YzuPvL2mB51DDsidWxHMknAWhM6-CYRMB8=.7fdbd330-b986-45b0-83c5-e621ea0749eb@github.com>
Message-ID: <XkeBhryNmRe-iUFK_8w_qogoZBXISAuBUUxokZkjX5M=.c708324e-c4e6-44ce-a0c5-3663225d8a17@github.com>

On Fri, 29 Jul 2022 17:36:34 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/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?

This is a good question.  Before, we had "if (!is_mixed) { heap->card_scan->process_region(); }  Now, in that case (the code is below), we have "else { ...  scanner->process_region_slice(); ...  }  This sharing of code still exists, but it is made a little more complicated because we don't always process entire regions at once, and I reordered the control flow.

The is_mixed case was always handled locally (unshared code) with explicit iteration over objects.  This is still handled locally, but it is also more complex in the new version of the code because we are working with "slices" of regions at a time.

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

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

From kdnilsen at openjdk.org  Mon Aug  1 19:28:47 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 1 Aug 2022 19:28:47 GMT
Subject: RFR: Load balance remembered set scanning [v3]
In-Reply-To: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
Message-ID: <ci_vSbhhddTSVdzdt6UnD-KJsF-vPuB9nDdzjaroNzs=.fa649abd-e2d4-46ac-aa89-dbd4dd080595@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:

  Changes suggested by reviewer feedback

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/153/files
  - new: https://git.openjdk.org/shenandoah/pull/153/files/6b51cbf3..a806698e

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

  Stats: 13 lines in 1 file changed: 6 ins; 0 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 stuefe at openjdk.org  Mon Aug  1 19:35:25 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 1 Aug 2022 19:35:25 GMT
Subject: RFR: 8291633: Build failures with GCC 11,
 Alpine 3 due to incompatible casts from nullptr
In-Reply-To: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
References: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
Message-ID: <MSOr0N0NTV9sIQE5H_o3AZamdchM1PtDWlOkNvkr0x4=.8e85629d-5094-4a38-820e-88d73b2b254e@github.com>

On Mon, 1 Aug 2022 17:01:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. 
> 
> They fall into three categories:
>   - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does;
>   - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it;
>   - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead.
> 
> Additional testing:
>  - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1
>  - [ ] Linux x86_64 fastdebug tier1 with GCC 9.3.0

LGTM

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

Marked as reviewed by stuefe (Reviewer).

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

From wkemper at openjdk.org  Mon Aug  1 19:41:47 2022
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 1 Aug 2022 19:41:47 GMT
Subject: RFR: Load balance remembered set scanning [v2]
In-Reply-To: <d2Z8JeqDOD3cnCsk-yjdH1t-WopGF6A1XjxhdUwOMv0=.7ff2de37-6433-4371-bc24-c98bc461fa77@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <JcpQhSgCKB3R6GTg8T-zU8xzfKPBo4RIpBN6sQIGamY=.95b956bc-3b72-4a93-b952-b6ffbf917fa4@github.com>
 <a8ccha-d9YzuPvL2mB51DDsidWxHMknAWhM6-CYRMB8=.7fdbd330-b986-45b0-83c5-e621ea0749eb@github.com>
 <d2Z8JeqDOD3cnCsk-yjdH1t-WopGF6A1XjxhdUwOMv0=.7ff2de37-6433-4371-bc24-c98bc461fa77@github.com>
Message-ID: <RIUTP17PuXvEcL1G95lnxBJNavLSwfHhQwMAtRyOJYM=.38f2f289-f464-4e48-abc2-de2ed90ffbd1@github.com>

On Mon, 1 Aug 2022 18:15:59 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> 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`?
>
> I've rewritten the comment here in an attempt to make the intention more clear.

I get it. I think it would be more clear if this method were called `initial_group_size` as the reduction of subsequent group sizes does not happen in this method.

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

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

From wkemper at openjdk.org  Mon Aug  1 20:25:21 2022
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 1 Aug 2022 20:25:21 GMT
Subject: RFR: Load balance remembered set scanning [v3]
In-Reply-To: <ci_vSbhhddTSVdzdt6UnD-KJsF-vPuB9nDdzjaroNzs=.fa649abd-e2d4-46ac-aa89-dbd4dd080595@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <ci_vSbhhddTSVdzdt6UnD-KJsF-vPuB9nDdzjaroNzs=.fa649abd-e2d4-46ac-aa89-dbd4dd080595@github.com>
Message-ID: <9y_8jzxfTgaYK_lmAaASAydDkmiHIbARh21T_s0UfzI=.b01e45d9-910f-4485-a9b8-ce4e12329594@github.com>

On Mon, 1 Aug 2022 19:28:47 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:
> 
>   Changes suggested by reviewer feedback

Marked as reviewed by wkemper (Committer).

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

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

From ysr at openjdk.org  Mon Aug  1 20:33:33 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 1 Aug 2022 20:33:33 GMT
Subject: RFR: Load balance remembered set scanning [v3]
In-Reply-To: <ci_vSbhhddTSVdzdt6UnD-KJsF-vPuB9nDdzjaroNzs=.fa649abd-e2d4-46ac-aa89-dbd4dd080595@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <ci_vSbhhddTSVdzdt6UnD-KJsF-vPuB9nDdzjaroNzs=.fa649abd-e2d4-46ac-aa89-dbd4dd080595@github.com>
Message-ID: <L2n399JerTwQxT5cvGQR94smQ6_mWIZTbnrmeYxb8e0=.76319103-f1e8-45c0-b30c-847729cea59b@github.com>

On Mon, 1 Aug 2022 19:28:47 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:
> 
>   Changes suggested by reviewer feedback

> 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.
> 

Are any specific or general performance numbers available to share for this change? Thanks!

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

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

From kdnilsen at openjdk.org  Mon Aug  1 21:56:10 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 1 Aug 2022 21:56:10 GMT
Subject: RFR: Load balance remembered set scanning [v4]
In-Reply-To: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
Message-ID: <oopj0ZmNp5Lkvp8rkQEOrZSnLmlfla_CemdI_fSD8v0=.a31239b8-8df5-4cf0-a1c7-d970e342832e@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:

  Fix white space

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/153/files
  - new: https://git.openjdk.org/shenandoah/pull/153/files/a806698e..9661d7ef

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

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 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  Mon Aug  1 22:17:02 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 1 Aug 2022 22:17:02 GMT
Subject: RFR: Load balance remembered set scanning [v3]
In-Reply-To: <L2n399JerTwQxT5cvGQR94smQ6_mWIZTbnrmeYxb8e0=.76319103-f1e8-45c0-b30c-847729cea59b@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <ci_vSbhhddTSVdzdt6UnD-KJsF-vPuB9nDdzjaroNzs=.fa649abd-e2d4-46ac-aa89-dbd4dd080595@github.com>
 <L2n399JerTwQxT5cvGQR94smQ6_mWIZTbnrmeYxb8e0=.76319103-f1e8-45c0-b30c-847729cea59b@github.com>
Message-ID: <xjEQjEyWAmGVvPGHlspTffapqItPoUblVnCfjZgvQ5c=.4b7d5bae-7cd3-4fb9-87ea-9d5c4eca853c@github.com>

On Mon, 1 Aug 2022 20:31:29 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> Are any specific or general performance numbers available to share for this change? Thanks!

In a 20-minute Extremem workload comparing mainline against this branch, the average time for remembered-set scanning was reduced from 28,634 microseconds to 21,810 microseconds, an improvement of 17.55%.  This was out of n = 1893 scans for the balanced branch and n = 1925 for the mainline.  I don't have a full analysis of why n is different between the two workloads.  I have seen previously that unbalanced scanning of remembered set sometimes has much more significant impact on GC completion times, and can result in allocation failures and degeneration.  On this workload, I don't see evidence of this.  But shorter GC times perhaps means less floating garbage, and that might be one reason we needed fewer total GC cycles.

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

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

From kdnilsen at openjdk.org  Mon Aug  1 22:18:13 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 1 Aug 2022 22:18:13 GMT
Subject: Integrated: 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: <VIjqFj1lB0gyx99x_179P81qRy3mNyvKll_GNZFzERY=.7610fe38-fc46-48d7-88b1-955f6df06886@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.

This pull request has now been integrated.

Changeset: 16a9ab63
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/16a9ab63be2591fd4133a204a000cb3406afdede
Stats:     633 lines in 8 files changed: 527 ins; 53 del; 53 mod

Load balance remembered set scanning

Reviewed-by: wkemper

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

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

From wkemper at openjdk.org  Mon Aug  1 23:54:57 2022
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 1 Aug 2022 23:54:57 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark [v4]
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <Z9A4gEHedIcqGfhk4FakrNa9Dqm59KCC9ZHqvA00V6E=.e871b34e-899e-441e-bd17-f2476597034a@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 18 commits:

 - Prepare for review
 - Merge branch 'shenandoah-master' into fill-old-pinned
 - Validate old gen state transitions
 - Make use of old generation without down casting
 - Make verifier aware of changes to old generation state machine
 - Make rset scan aware of changes to old generation state machine
 - Fix use of index as count and over-counting of garbage
 - Sort out phase timing, gc sessions and add missing state transititions
 - Fix fastdebug compilation error
 - Slide pinned regions to the front of collection set candidates
 - ... and 8 more: https://git.openjdk.org/shenandoah/compare/16a9ab63...561e5e90

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

Changes: https://git.openjdk.org/shenandoah/pull/149/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=149&range=03
  Stats: 1178 lines in 29 files changed: 741 ins; 274 del; 163 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 wkemper at openjdk.org  Tue Aug  2 00:04:58 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Aug 2022 00:04:58 GMT
Subject: RFR: Coalesce and fill old,
 pinned regions after old gen final mark [v5]
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <mntc1usdtBjVGMTomkJAuw71Ata4qtpLM5rs_NhD0Jo=.c4777477-0f36-43a1-9c1c-9576d264c9ff@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 one additional commit since the last revision:

  Fix whitespace

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/149/files
  - new: https://git.openjdk.org/shenandoah/pull/149/files/561e5e90..9f569892

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 mbaesken at openjdk.org  Tue Aug  2 06:38:59 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 2 Aug 2022 06:38:59 GMT
Subject: RFR: 8291633: Build failures with GCC 11,
 Alpine 3 due to incompatible casts from nullptr
In-Reply-To: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
References: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
Message-ID: <MOwx5Fbro8yaFXBx8TaMlagSwx3SBOFsO4Vhbv3csvc=.f222c381-4563-4741-b06b-489bf9953bd9@github.com>

On Mon, 1 Aug 2022 17:01:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. 
> 
> They fall into three categories:
>   - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does;
>   - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it;
>   - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead.
> 
> Additional testing:
>  - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1
>  - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0

Looks good to me, thanks for looking into it.

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

Marked as reviewed by mbaesken (Reviewer).

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

From nivanov at cloudlinux.com  Tue Aug  2 10:56:26 2022
From: nivanov at cloudlinux.com (Nikita Ivanov)
Date: Tue, 2 Aug 2022 13:56:26 +0300
Subject: Where is shenandoah-jdk8u currently maintained?
Message-ID: <CAAJ4Ao8uj9b418SKxVEt-8S17RDR9rgg+PF=8aSV=ZG6fV4Nfw@mail.gmail.com>

Hi!
As I see, the last 2 releases of jdk8u (332 and 342) were not ported to the
shenandoah-jdk8u repository so far (at least, on github).  At the same
time, vendors continue to provide updates to the java-1.8.0-openjdk
package. Are there any hidden repositories of shenandoah-jdk8u? Why were
backports to the github repository stopped?
-- 
Best Regards,
*Nikita Ivanov* | C developer
*Telephone:* +79140870696
*Telephone:* +79015053149
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/shenandoah-dev/attachments/20220802/17a94273/attachment.htm>

From wkemper at openjdk.org  Tue Aug  2 17:08:13 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Aug 2022 17:08:13 GMT
Subject: RFR: Merge openjdk/jdk:master
Message-ID: <ojStB4ymcBLN09maGUsUF0YnSKOfycLRzpZqCrA5J0k=.0b537794-ec70-46b4-9968-695dd9fb1530@github.com>

This pulls in the latest upstream commits from tip. There was a [small change](https://github.com/openjdk/shenandoah/pull/154/commits/f7a1353f7bff269f8bd2750bc60af85fb04f4eed) to handle notifications of mark start and mark end to make Loom aware of old generation marking.

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

Commit messages:
 - Merge branch 'shenandoah-master' into upstream-merge-test
 - Merge branch 'shenandoah-master' into upstream-merge-test
 - Do not 'end mark' if old marking is in progress
 - Merge branch 'openjdk-mainline' into upstream-merge-test
 - 8291048: x86: compiler/c2/irTests/TestAutoVectorization2DArray.java fails with lower SSE
 - 8290848: LoadLibraryUnload.java still fails with "Too few cleared WeakReferences"
 - Merge
 - 8291006: java/foreign/TestUnsupportedPlatform fails after JDK-8290455
 - 8290455: jck test api/java_lang/foreign/VaList/Empty.html fails on some platforms
 - 8290460: Alpine: disable some panama tests that rely on std::thread
 - ... and 2218 more: https://git.openjdk.org/shenandoah/compare/16a9ab63...32991b5f

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

Changes: https://git.openjdk.org/shenandoah/pull/154/files
  Stats: 1034164 lines in 11702 files changed: 672855 ins; 251524 del; 109785 mod
  Patch: https://git.openjdk.org/shenandoah/pull/154.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/154/head:pull/154

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

From rkennke at openjdk.org  Tue Aug  2 17:27:59 2022
From: rkennke at openjdk.org (Roman Kennke)
Date: Tue, 2 Aug 2022 17:27:59 GMT
Subject: RFR: Merge openjdk/jdk:master
In-Reply-To: <ojStB4ymcBLN09maGUsUF0YnSKOfycLRzpZqCrA5J0k=.0b537794-ec70-46b4-9968-695dd9fb1530@github.com>
References: <ojStB4ymcBLN09maGUsUF0YnSKOfycLRzpZqCrA5J0k=.0b537794-ec70-46b4-9968-695dd9fb1530@github.com>
Message-ID: <kOYwqU7sILEFEHRx5W6KXR5JNTdwOo4ZonOCefLfaAk=.cd12756b-5951-450b-a9cc-b12fbc8268a2@github.com>

On Mon, 1 Aug 2022 23:44:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This pulls in the latest upstream commits from tip. There was a [small change](https://github.com/openjdk/shenandoah/pull/154/commits/f7a1353f7bff269f8bd2750bc60af85fb04f4eed) to handle notifications of mark start and mark end to make Loom aware of old generation marking.

Marked as reviewed by rkennke (Lead).

Looks good. Thank you!

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

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

From wkemper at openjdk.org  Tue Aug  2 18:14:14 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Aug 2022 18:14:14 GMT
Subject: Integrated: Merge openjdk/jdk:master
In-Reply-To: <ojStB4ymcBLN09maGUsUF0YnSKOfycLRzpZqCrA5J0k=.0b537794-ec70-46b4-9968-695dd9fb1530@github.com>
References: <ojStB4ymcBLN09maGUsUF0YnSKOfycLRzpZqCrA5J0k=.0b537794-ec70-46b4-9968-695dd9fb1530@github.com>
Message-ID: <KJy6-Lx5JrFm0-6nJyCRWluJfoJSGHQIoBwIjzbWk9Y=.23ac2e87-d406-4343-a0bd-249b656ad177@github.com>

On Mon, 1 Aug 2022 23:44:52 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This pulls in the latest upstream commits from tip. There was a [small change](https://github.com/openjdk/shenandoah/pull/154/commits/f7a1353f7bff269f8bd2750bc60af85fb04f4eed) to handle notifications of mark start and mark end to make Loom aware of old generation marking.

This pull request has now been integrated.

Changeset: 60e43d04
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/60e43d04f533392e088ae2014d98c3701b29f1f1
Stats:     1034164 lines in 11702 files changed: 672855 ins; 251524 del; 109785 mod

Merge openjdk/jdk:master

Reviewed-by: rkennke

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

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

From wkemper at openjdk.org  Tue Aug  2 19:41:05 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Aug 2022 19:41:05 GMT
Subject: RFR: Use os::malloc instead of malloc
Message-ID: <SlxM_DfnC58LRn7SUHIbMPyd_Ioe3q8IADHBuer1AW4=.03b0c8b2-3b33-4ab1-87cb-32e90faf4551@github.com>

This fixes a compiler error with gcc-10.3.0 used by github actions

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

Commit messages:
 - Use os::malloc instead of malloc

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

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

From shade at openjdk.org  Tue Aug  2 22:21:43 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 Aug 2022 22:21:43 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: <WQlbTXAxyd_w812dGtXqvZhCPfPB_Bm99a7oIdWztWs=.e78c614f-0a9b-4225-a16a-ffe34a3c885e@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

Marked as reviewed by shade (Committer).

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

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

From wkemper at openjdk.org  Tue Aug  2 22:51:18 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Aug 2022 22:51:18 GMT
Subject: RFR: Handle old, pinned regions [v6]
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <XYm1tl3bEChDxSuBfHGc0lkASa1daShiRXeeW9A67DM=.2f658ceb-d5fb-4a2e-af2e-80f65821a19f@github.com>

> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
> 
> * Before adding old regions to the collection set, their pinned status is synchronized.
> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.

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

  Do not drop abbreviated argument when recording success concurrent cycle

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/149/files
  - new: https://git.openjdk.org/shenandoah/pull/149/files/9f569892..73fd90e8

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

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 wkemper at openjdk.org  Tue Aug  2 22:53:24 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 2 Aug 2022 22:53:24 GMT
Subject: RFR: Use os::malloc instead of malloc [v2]
In-Reply-To: <SlxM_DfnC58LRn7SUHIbMPyd_Ioe3q8IADHBuer1AW4=.03b0c8b2-3b33-4ab1-87cb-32e90faf4551@github.com>
References: <SlxM_DfnC58LRn7SUHIbMPyd_Ioe3q8IADHBuer1AW4=.03b0c8b2-3b33-4ab1-87cb-32e90faf4551@github.com>
Message-ID: <SiRKKWEjF6iQHNREwPnomEFI8-U5eb8pQ1FgkhdUjX4=.fcff46d3-5338-4582-af58-abe67fbc50be@github.com>

> This fixes a compiler error with gcc-10.3.0 used by github actions

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

  Update another use of global malloc/free

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/155/files
  - new: https://git.openjdk.org/shenandoah/pull/155/files/551d3a0b..f3473846

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

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

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

From wkemper at openjdk.org  Wed Aug  3 01:10:57 2022
From: wkemper at openjdk.org (William Kemper)
Date: Wed, 3 Aug 2022 01:10:57 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>

> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
> 
> * Before adding old regions to the collection set, their pinned status is synchronized.
> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.

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

 - Merge branch 'shenandoah-master' into fill-old-pinned
 - Do not drop abbreviated argument when recording success concurrent cycle
 - Fix whitespace
 - Prepare for review
 - Merge branch 'shenandoah-master' into fill-old-pinned
 - Validate old gen state transitions
 - Make use of old generation without down casting
 - Make verifier aware of changes to old generation state machine
 - Make rset scan aware of changes to old generation state machine
 - Fix use of index as count and over-counting of garbage
 - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6

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

Changes: https://git.openjdk.org/shenandoah/pull/149/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=149&range=06
  Stats: 1178 lines in 29 files changed: 741 ins; 274 del; 163 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 shade at openjdk.org  Wed Aug  3 08:19:46 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Aug 2022 08:19:46 GMT
Subject: RFR: 8291633: Build failures with GCC 11,
 Alpine 3 due to incompatible casts from nullptr
In-Reply-To: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
References: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
Message-ID: <w4gE2k-_EigU5TKPwn770rT2djxqJZTyTQuCAkhOaBU=.964a95fd-850f-42d9-b2dc-12a990f1d4ac@github.com>

On Mon, 1 Aug 2022 17:01:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. 
> 
> They fall into three categories:
>   - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does;
>   - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it;
>   - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead.
> 
> Additional testing:
>  - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1
>  - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0

Thank you! If there are no other reviews, I'll be integrating this soon.

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

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

From jiefu at openjdk.org  Wed Aug  3 08:40:41 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 3 Aug 2022 08:40:41 GMT
Subject: RFR: 8291633: Build failures with GCC 11,
 Alpine 3 due to incompatible casts from nullptr
In-Reply-To: <w4gE2k-_EigU5TKPwn770rT2djxqJZTyTQuCAkhOaBU=.964a95fd-850f-42d9-b2dc-12a990f1d4ac@github.com>
References: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
 <w4gE2k-_EigU5TKPwn770rT2djxqJZTyTQuCAkhOaBU=.964a95fd-850f-42d9-b2dc-12a990f1d4ac@github.com>
Message-ID: <9DN64MNNW_KH8OKweTt8ZYJqI9GbA5YkEyQDoL-YR0U=.9b8a829b-fe4a-40f3-9014-2d45df0a7911@github.com>

On Wed, 3 Aug 2022 08:15:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Thank you! If there are no other reviews, I'll be integrating this soon.

Maybe, we'd better update the copyright year of src/hotspot/cpu/x86/interpreterRT_x86_64.cpp before integration.
Thanks.

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

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

From shade at openjdk.org  Wed Aug  3 08:50:08 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Aug 2022 08:50:08 GMT
Subject: RFR: 8291633: Build failures with GCC 11,
 Alpine 3 due to incompatible casts from nullptr [v2]
In-Reply-To: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
References: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
Message-ID: <p_miIMrG_WFCBUaJmMGV6jFpqCMVz-zSbB5HCmS8imk=.3976c3d1-4794-457b-bd91-985ee8059a43@github.com>

> Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. 
> 
> They fall into three categories:
>   - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does;
>   - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it;
>   - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead.
> 
> Additional testing:
>  - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1
>  - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0

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

 - Copyright years
 - Merge branch 'master' into JDK-8291633-alpine3-nullptr
 - More work
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9705/files
  - new: https://git.openjdk.org/jdk/pull/9705/files/59f92b41..3d3dbc3c

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

  Stats: 1075 lines in 48 files changed: 648 ins; 260 del; 167 mod
  Patch: https://git.openjdk.org/jdk/pull/9705.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9705/head:pull/9705

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

From shade at openjdk.org  Wed Aug  3 11:27:47 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Aug 2022 11:27:47 GMT
Subject: RFR: 8291633: Build failures with GCC 11,
 Alpine 3 due to incompatible casts from nullptr
In-Reply-To: <9DN64MNNW_KH8OKweTt8ZYJqI9GbA5YkEyQDoL-YR0U=.9b8a829b-fe4a-40f3-9014-2d45df0a7911@github.com>
References: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
 <w4gE2k-_EigU5TKPwn770rT2djxqJZTyTQuCAkhOaBU=.964a95fd-850f-42d9-b2dc-12a990f1d4ac@github.com>
 <9DN64MNNW_KH8OKweTt8ZYJqI9GbA5YkEyQDoL-YR0U=.9b8a829b-fe4a-40f3-9014-2d45df0a7911@github.com>
Message-ID: <DX_zYiIT3NBtiqsZzemXlE9HKLxHEO7n6OY5p3PVUC0=.e8ebc299-9296-4ee9-8398-65a9864fe3b9@github.com>

On Wed, 3 Aug 2022 08:37:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Maybe, we'd better update the copyright year of src/hotspot/cpu/x86/interpreterRT_x86_64.cpp before integration. Thanks.

Did so in new commit.

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

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

From jiefu at openjdk.org  Wed Aug  3 11:48:51 2022
From: jiefu at openjdk.org (Jie Fu)
Date: Wed, 3 Aug 2022 11:48:51 GMT
Subject: RFR: 8291633: Build failures with GCC 11,
 Alpine 3 due to incompatible casts from nullptr [v2]
In-Reply-To: <p_miIMrG_WFCBUaJmMGV6jFpqCMVz-zSbB5HCmS8imk=.3976c3d1-4794-457b-bd91-985ee8059a43@github.com>
References: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
 <p_miIMrG_WFCBUaJmMGV6jFpqCMVz-zSbB5HCmS8imk=.3976c3d1-4794-457b-bd91-985ee8059a43@github.com>
Message-ID: <6XO_kN8TYlyxWqkcnMrTZGPkKGsLWmT5jBYVURF9AJg=.60c3a4a8-5d04-4556-9596-6f7cfc1a994d@github.com>

On Wed, 3 Aug 2022 08:50:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. 
>> 
>> They fall into three categories:
>>   - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does;
>>   - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it;
>>   - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1
>>  - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Copyright years
>  - Merge branch 'master' into JDK-8291633-alpine3-nullptr
>  - More work
>  - Fix

Thanks for the update.
LGTM

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

Marked as reviewed by jiefu (Reviewer).

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

From shade at openjdk.org  Wed Aug  3 17:26:34 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 Aug 2022 17:26:34 GMT
Subject: Integrated: 8291633: Build failures with GCC 11,
 Alpine 3 due to incompatible casts from nullptr
In-Reply-To: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
References: <GumJKsHcVYqvPbNPkVUfJS70KwAcSf6Kfu-PiantS0w=.06b8f014-a14c-4f2b-8147-cb9b2eb9d3fd@github.com>
Message-ID: <JxEWs30ntikfOiwBtBuyjLDDRWLM349BlWJONX65-6Q=.76d6211e-7994-4624-915e-831c1ebc3f07@github.com>

On Mon, 1 Aug 2022 17:01:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Looks like GCC and musl that ship in new Alpine 3.15 highlight that some casts from `NULL` and `nullptr` are risky/illegal. 
> 
> They fall into three categories:
>   - explicitly casting `NULL` to integral type; we can and should use `NULL_WORD` in these cases, like the rest of Hotspot does;
>   - using `NULL` in ternary expression when another side is integral type, thus implicitly casting it;
>   - `reinterpret_cast`-ing `NULL` to pointer type -- this is dangerous and rightfully breaks; we can use `static_cast` instead.
> 
> Additional testing:
>  - [x] Linux x86_64 {release, fastdebug, slowdebug} build with Alpine 3.15, GCC 11.2.1
>  - [x] Linux x86_64 fastdebug tier1 with GCC 9.3.0

This pull request has now been integrated.

Changeset: c89556f6
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c89556f6cd4d0b64f3e9e2f1dc7c51634522f205
Stats:     16 lines in 6 files changed: 0 ins; 0 del; 16 mod

8291633: Build failures with GCC 11, Alpine 3 due to incompatible casts from nullptr

Reviewed-by: stuefe, mbaesken, jiefu

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

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

From andrew at openjdk.org  Wed Aug  3 17:34:11 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Wed, 3 Aug 2022 17:34:11 GMT
Subject: Integrated: 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: <eBRLAS5p-eWhNoBwM4eK8PiQgEeQ5cpY1TXNT6JLn0Y=.fdfd47cb-3c4c-4d93-a2f0-fa5c36488259@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!

This pull request has now been integrated.

Changeset: 6305c6ff
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/6305c6ff95efbd6ec06c798f293f516367e64a88
Stats:     3402 lines in 4 files changed: 3402 ins; 0 del; 0 mod

8253424: Add support for running pre-submit testing using GitHub Actions
8253865: Pre-submit testing using GitHub Actions does not detect failures reliably
8254054: Pre-submit testing using GitHub Actions should not use the deprecated set-env command
8254173: Add Zero, Minimal hotspot targets to submit workflow
8254175: Build no-pch configuration in debug mode for submit checks
8254282: Add Linux x86_32 builds to submit workflow
8255373: Submit workflow artifact name is always "test-results_.zip"
8255895: Submit workflow artifacts miss hs_errs/replays due to ZIP include mismatch
8256127: Add cross-compiled foreign architectures builds to submit workflow
8256277: Github Action build on macOS should define OS and Xcode versions
8256354: Github Action build on Windows should define OS and MSVC versions
8256414: add optimized build to submit workflow
8256393: Github Actions build on Linux should define OS and GCC versions
8256747: GitHub Actions: decouple the hotspot build-only jobs from Linux x64 testing
8257056: Submit workflow should apt-get update to avoid package installation errors
8259924: GitHub actions fail on Linux x86_32 with "Could not configure libc6:i386"
8260460: GitHub actions still fail on Linux x86_32 with "Could not configure libc6:i386"
8263667: Avoid running GitHub actions on branches named pr/*
8255305: Add Linux x86_32 tier1 to submit workflow
8255352: Archive important test outputs in submit workflow
8282225: GHA: Allow one concurrent run per PR only
8241768: git needs .gitattributes
8284772: 8u GHA: Use GCC Major Version Dependencies Only

Reviewed-by: shade
Backport-of: 10029f784ef7be458a7b6ff3cc21649ff0abb6f3

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

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

From kdnilsen at openjdk.org  Thu Aug  4 21:51:20 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Thu, 4 Aug 2022 21:51:20 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
Message-ID: <sho9KSV_0cJxWJDwl4jLR-WNZ12YHN7-5szyD46QLqg=.9e660d43-05c4-4ae4-81d3-8679c7767f59@github.com>

On Wed, 3 Aug 2022 01:10:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
>> 
>> * Before adding old regions to the collection set, their pinned status is synchronized.
>> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
>> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Do not drop abbreviated argument when recording success concurrent cycle
>  - Fix whitespace
>  - Prepare for review
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Validate old gen state transitions
>  - Make use of old generation without down casting
>  - Make verifier aware of changes to old generation state machine
>  - Make rset scan aware of changes to old generation state machine
>  - Fix use of index as count and over-counting of garbage
>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6

Lot of code here.  Thanks for working through it.

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

> 347:   // Cannot start a new old-gen GC until previous one has finished.
> 348:   //
> 349:   // Future refinement: under certain circumstances, we might be more sophisticated about this choice.

This comment is stale, with the new implementation.  My thought when I wrote the comment was that we cannot "abandon" the identified set of old-gen collection candidates in order to start up a new old-gen collection until the mixed evacuations have completely processed all old-gen collection candidates.  That's because we would have to introduce a "new" phase to coalesce and fill these regions if we choose not to collect them.  But in the new design, it seems like we have the flexibility to decide for more reasons than just pinning that certain candidate regions will not be collected.  For example, if we have some reason to believe that a lot of old-gen memory has newly become garbage, then it might be "best" to abandon the collection set candidates as is and start a new old-gen marking effort.  Not asking for a lot of change here - maybe just a mention in the comment that we have new freedoms that we didn't use to have.

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

Marked as reviewed by kdnilsen (Committer).

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

From ysr at openjdk.org  Thu Aug  4 21:51:22 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Aug 2022 21:51:22 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
Message-ID: <79bDsiIHnlnlkoa4LOBb5lcWX80bEcjl_pAg6unieWA=.b178ea8f-96d7-4597-8e75-6601ba0e4806@github.com>

On Wed, 3 Aug 2022 01:10:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
>> 
>> * Before adding old regions to the collection set, their pinned status is synchronized.
>> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
>> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Do not drop abbreviated argument when recording success concurrent cycle
>  - Fix whitespace
>  - Prepare for review
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Validate old gen state transitions
>  - Make use of old generation without down casting
>  - Make verifier aware of changes to old generation state machine
>  - Make rset scan aware of changes to old generation state machine
>  - Fix use of index as count and over-counting of garbage
>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6

I am in the midst of the review (comments pending), but one question came up that I thought I'd get resolved first, so I had the right mental mode here.

The filler objects are overlaid over dead objects both for performance (being able to skip over them quickly), not having to scan zombie objects are processing stale pointers (safety), and also to be able to safely skip these zombie objects because their sizes may not be computable safely if their klass's have been unloaded. It's the last one that I worry about. If we delay the fillers until (well after) class unloading, will this not cause our scans to be potentially vulnerable to stumbling when trying to compute their size? Or does the use of the marking bitmap always ensure that our closures are never trying to walk over dead objects by trying to determine their size?

Thanks!

Apropos of my previous remark, it would be good, if not already the case to somehow be able to assert this of closures that might walk regions in this state.

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

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

From ysr at openjdk.org  Thu Aug  4 22:13:29 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Aug 2022 22:13:29 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
Message-ID: <cw5f7cz3Iwfp7To6a_dmVndGKWzx0f6Ox_YxGcNsNEQ=.62218863-a1dd-4c6b-810e-43cb6b2d8000@github.com>

On Wed, 3 Aug 2022 01:10:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
>> 
>> * Before adding old regions to the collection set, their pinned status is synchronized.
>> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
>> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Do not drop abbreviated argument when recording success concurrent cycle
>  - Fix whitespace
>  - Prepare for review
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Validate old gen state transitions
>  - Make use of old generation without down casting
>  - Make verifier aware of changes to old generation state machine
>  - Make rset scan aware of changes to old generation state machine
>  - Fix use of index as count and over-counting of garbage
>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6

Reviewed about half the code. Thought I'd release those pending review comments and then continue the rest of the review later today. Sorry for the slow pace of review because of my relative unfamiliarity with the minutiae and history of the code, and thanks for your patience!

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 85:

> 83:   ShenandoahOldHeuristics(ShenandoahOldGeneration* generation, ShenandoahHeuristics* trigger_heuristic);
> 84: 
> 85:   virtual void choose_collection_set(ShenandoahCollectionSet* collection_set, ShenandoahOldHeuristics* old_heuristics) override;

Not your code, but why pass a pointer to a ShenandoahHeuristics object to a method on that same object type? Are there multiple heuristics objects somehow being composed here via delegation or something?

src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp line 73:

> 71:   typedef enum {
> 72:     none,
> 73:     concurrent_normal,

In generational mode, is `concurrent_normal` mode a synonym for `servicing_young` mode (in your new `servicing_old` mode parlance?)

It would be good to somehow match these modes with those in ASCII art state transition diagram in ShenandoahControlThread::service_concurrent_cycle() (may be expressed as a morphism from that state transition graph to a `_mode` state transition graph here, in case such a correspondence exists).

src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp line 106:

> 104: 
> 105:   bool check_cancellation_or_degen(ShenandoahGC::ShenandoahDegenPoint point);
> 106:   bool resume_concurrent_old_cycle(ShenandoahGeneration* generation, GCCause::Cause cause);

For these methods returning a boolean result, please add a line of documentation stating what the return values represent, as done for `service_stw_degenerated_cycle` further below.

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

> 121:   void merge_write_table();
> 122: 
> 123:   // Used by concurrent and degenerated GC to reset regions.

The best way to write comments in a header file is to specify post-conditions of methods (and as appropriate any preconditions that callers must satisfy), saying as little as possible about what is done to accomplish the post-conditions. The latter documentation would belong in the implementation of the method.

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

> 124:   virtual void prepare_gc();
> 125: 
> 126:   // Return true iff prepared collection set includes at least one old-gen HeapRegion.

The comment about a return value seems outdated. A brief description of what the method is expected to do would be good here.

src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.cpp line 40:

> 38: void ShenandoahFinalMarkUpdateRegionStateClosure::heap_region_do(ShenandoahHeapRegion* r) {
> 39:   if (r->is_active()) {
> 40:     if (_ctx != nullptr) {

What are the possible circumstances when we might call here with `_ctx == nullptr` ?

May be a brief comment would be helpful.

src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.cpp line 70:

> 68:   } else {
> 69:     assert(!r->has_live(), "Region " SIZE_FORMAT " should have no live data", r->index());
> 70:     if (_ctx != nullptr) {

Nit: The `if` clause could be pulled into the assert as `_ctx == nullptr || ....`.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 399:

> 397: }
> 398: 
> 399: void ShenandoahOldGeneration::record_success_concurrent(bool abbreviated) {

Is the `abbreviated` parameter being deliberately ignored here? (Sometimes we specify that intent by naming the parm `ignored` or by specifying `/* ignored */` next to it.) The specification of the method in the corresponding header file should specify the semantics of the parameter and what is being recorded.

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 82:

> 80:   virtual void record_success_concurrent(bool abbreviated) override;
> 81: 
> 82:   enum State {

An intended state transition graph would be useful here as a documentation aid/device (or may be in `validate_transition` ?).

src/hotspot/share/gc/shenandoah/shenandoahYoungGeneration.cpp line 46:

> 44:   ShenandoahHeap* heap = ShenandoahHeap::heap();
> 45:   heap->set_concurrent_young_mark_in_progress(in_progress);
> 46:   if (_old_gen_task_queues != nullptr && in_progress && !heap->is_prepare_for_old_mark_in_progress()) {

Not a change, but what exactly is `_old_gen_task_queues != nullptr` checking? Is it checking if we are in a config where old gen is configured (i.e. generation shenandoah)? If so, this seems a bit subtle and fragile and might be made a more direct check? Indeed what would happen then if the the first conjunct were dropped entirely. I'd expect that the last would always return false and you'd get the desired result anyway?

It's of course likely I am misunderstanding the rationale behind that check. In which case, perhaps the comment below could be extended to address this.

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

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

From wkemper at openjdk.org  Thu Aug  4 22:13:31 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Aug 2022 22:13:31 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <sho9KSV_0cJxWJDwl4jLR-WNZ12YHN7-5szyD46QLqg=.9e660d43-05c4-4ae4-81d3-8679c7767f59@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
 <sho9KSV_0cJxWJDwl4jLR-WNZ12YHN7-5szyD46QLqg=.9e660d43-05c4-4ae4-81d3-8679c7767f59@github.com>
Message-ID: <9n49X7ncBeJoyBa598TS9idv3pSYPnxvH-tErAOnPqE=.2db90483-898f-4f8b-a7c3-68bcf4409788@github.com>

On Thu, 4 Aug 2022 21:33:42 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Lot of code here. Thanks for working through it.

Many of the changed files are just to have `ShenandoahHeap::old_generation()` return a `ShenandoahOldGeneration` pointer to eliminate a lot of ugly downcasts.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 349:
> 
>> 347:   // Cannot start a new old-gen GC until previous one has finished.
>> 348:   //
>> 349:   // Future refinement: under certain circumstances, we might be more sophisticated about this choice.
> 
> This comment is stale, with the new implementation.  My thought when I wrote the comment was that we cannot "abandon" the identified set of old-gen collection candidates in order to start up a new old-gen collection until the mixed evacuations have completely processed all old-gen collection candidates.  That's because we would have to introduce a "new" phase to coalesce and fill these regions if we choose not to collect them.  But in the new design, it seems like we have the flexibility to decide for more reasons than just pinning that certain candidate regions will not be collected.  For example, if we have some reason to believe that a lot of old-gen memory has newly become garbage, then it might be "best" to abandon the collection set candidates as is and start a new old-gen marking effort.  Not asking for a lot of change here - maybe just a mention in the comment that we have new freedoms that we didn't use to have.

Sure - I will update the comment.

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

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

From ysr at openjdk.org  Thu Aug  4 22:13:35 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Thu, 4 Aug 2022 22:13:35 GMT
Subject: RFR: Handle old, pinned regions [v5]
In-Reply-To: <mntc1usdtBjVGMTomkJAuw71Ata4qtpLM5rs_NhD0Jo=.c4777477-0f36-43a1-9c1c-9576d264c9ff@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <mntc1usdtBjVGMTomkJAuw71Ata4qtpLM5rs_NhD0Jo=.c4777477-0f36-43a1-9c1c-9576d264c9ff@github.com>
Message-ID: <hHVo0Ui4hrEflix11UDuyua-09p4e7Lwg5Cqn_iRj9w=.cc681ea0-b4f0-4b8e-85da-7a770ad909f0@github.com>

On Tue, 2 Aug 2022 00:04:58 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
>> 
>> * Before adding old regions to the collection set, their pinned status is synchronized.
>> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
>> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 47:

> 45:   // for pinned regions.
> 46: 
> 47:   // This points to the first candidate of the current mixed collection. This

There is an implied order in first, last, etc. but the criterion for the ordering isn't explained here. (May be it is later.) I think the comment would read better if the high level idea of maintaining this ordered set of candidates was made clear at the outset, and the criteria underlying the order.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 48:

> 46: 
> 47:   // This points to the first candidate of the current mixed collection. This
> 48:   // is only used for an assertion when handling pinned regions.

Protect field with `#ifdef ASSERT` in that case?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 53:

> 51:   // Pinned regions may not be included in the collection set. Any old regions
> 52:   // which were pinned at the time when old regions were added to the mixed
> 53:   // collection will have their pointers shifted down so that they are at the

"have their pointers shifted down" is not clear without more context. Nit: Also "pointers" sounds out of place here. You can identify the region pointers with the regions for the purpose of documentation comments here.

Also, I'd pick one consistent terminology, may be first and last (by index), rather than down and up, or left and right, which are more ambiguous (unless it's made clear).

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

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

From wkemper at openjdk.org  Thu Aug  4 22:22:09 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Aug 2022 22:22:09 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <79bDsiIHnlnlkoa4LOBb5lcWX80bEcjl_pAg6unieWA=.b178ea8f-96d7-4597-8e75-6601ba0e4806@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
 <79bDsiIHnlnlkoa4LOBb5lcWX80bEcjl_pAg6unieWA=.b178ea8f-96d7-4597-8e75-6601ba0e4806@github.com>
Message-ID: <Xfb66MdewSYckyY6Idxkv4lW9_Oku9-71clNUO6GtOk=.e3a323ba-e846-4636-84cc-7a37800278a4@github.com>

On Thu, 4 Aug 2022 21:39:01 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> 



> Or does the use of the marking bitmap always ensure that our closures are never trying to walk over dead objects by trying to determine their size?

Yes - exactly. The mark bitmap is used to prevent the remembered set scan from touching any unmarked (i.e., garbage) objects. Before we clear the bitmap for the next old generation mark, we make the old regions parseable (coalesce and fill).

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

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

From wkemper at openjdk.org  Thu Aug  4 22:22:13 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Aug 2022 22:22:13 GMT
Subject: RFR: Handle old, pinned regions [v5]
In-Reply-To: <hHVo0Ui4hrEflix11UDuyua-09p4e7Lwg5Cqn_iRj9w=.cc681ea0-b4f0-4b8e-85da-7a770ad909f0@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <mntc1usdtBjVGMTomkJAuw71Ata4qtpLM5rs_NhD0Jo=.c4777477-0f36-43a1-9c1c-9576d264c9ff@github.com>
 <hHVo0Ui4hrEflix11UDuyua-09p4e7Lwg5Cqn_iRj9w=.cc681ea0-b4f0-4b8e-85da-7a770ad909f0@github.com>
Message-ID: <Dad8UbKkqNeeq5lDLE4Xtz4jK7dKU4XthbKg_uQ1Nwk=.8c87709f-0250-4b7b-8ad5-61dea3555553@github.com>

On Wed, 3 Aug 2022 00:06:05 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 47:
> 
>> 45:   // for pinned regions.
>> 46: 
>> 47:   // This points to the first candidate of the current mixed collection. This
> 
> There is an implied order in first, last, etc. but the criterion for the ordering isn't explained here. (May be it is later.) I think the comment would read better if the high level idea of maintaining this ordered set of candidates was made clear at the outset, and the criteria underlying the order.

They're ordered from most to least garbage. I'll call that out explicitly in the comments.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 48:
> 
>> 46: 
>> 47:   // This points to the first candidate of the current mixed collection. This
>> 48:   // is only used for an assertion when handling pinned regions.
> 
> Protect field with `#ifdef ASSERT` in that case?

Will do.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 53:
> 
>> 51:   // Pinned regions may not be included in the collection set. Any old regions
>> 52:   // which were pinned at the time when old regions were added to the mixed
>> 53:   // collection will have their pointers shifted down so that they are at the
> 
> "have their pointers shifted down" is not clear without more context. Nit: Also "pointers" sounds out of place here. You can identify the region pointers with the regions for the purpose of documentation comments here.
> 
> Also, I'd pick one consistent terminology, may be first and last (by index), rather than down and up, or left and right, which are more ambiguous (unless it's made clear).

s/their pointers/the pointers to them ? In my head, I was mostly thinking in terms of left (most garbage) and right (least garbage). I will update the variables and comments for consistency.

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

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

From wkemper at openjdk.org  Thu Aug  4 22:33:32 2022
From: wkemper at openjdk.org (William Kemper)
Date: Thu, 4 Aug 2022 22:33:32 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <cw5f7cz3Iwfp7To6a_dmVndGKWzx0f6Ox_YxGcNsNEQ=.62218863-a1dd-4c6b-810e-43cb6b2d8000@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
 <cw5f7cz3Iwfp7To6a_dmVndGKWzx0f6Ox_YxGcNsNEQ=.62218863-a1dd-4c6b-810e-43cb6b2d8000@github.com>
Message-ID: <woT-txEp-YZdGKFljvX9RNJUkF792PkY_X5x1wrdqBU=.00de3a34-83ee-445a-a957-6cb0b82659ed@github.com>

On Wed, 3 Aug 2022 01:36:36 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'shenandoah-master' into fill-old-pinned
>>  - Do not drop abbreviated argument when recording success concurrent cycle
>>  - Fix whitespace
>>  - Prepare for review
>>  - Merge branch 'shenandoah-master' into fill-old-pinned
>>  - Validate old gen state transitions
>>  - Make use of old generation without down casting
>>  - Make verifier aware of changes to old generation state machine
>>  - Make rset scan aware of changes to old generation state machine
>>  - Fix use of index as count and over-counting of garbage
>>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 85:
> 
>> 83:   ShenandoahOldHeuristics(ShenandoahOldGeneration* generation, ShenandoahHeuristics* trigger_heuristic);
>> 84: 
>> 85:   virtual void choose_collection_set(ShenandoahCollectionSet* collection_set, ShenandoahOldHeuristics* old_heuristics) override;
> 
> Not your code, but why pass a pointer to a ShenandoahHeuristics object to a method on that same object type? Are there multiple heuristics objects somehow being composed here via delegation or something?

Yes, the `trigger_heuristic` is a delegate. The old heuristics have their own logic for choosing the collection set, but they delegate the trigger decision to the adaptive heuristic (by default).

> src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp line 73:
> 
>> 71:   typedef enum {
>> 72:     none,
>> 73:     concurrent_normal,
> 
> In generational mode, is `concurrent_normal` mode a synonym for `servicing_young` mode (in your new `servicing_old` mode parlance?)
> 
> It would be good to somehow match these modes with those in ASCII art state transition diagram in ShenandoahControlThread::service_concurrent_cycle() (may be expressed as a morphism from that state transition graph to a `_mode` state transition graph here, in case such a correspondence exists).

`concurrent_normal` could be a young or _global_ collection. I think the control thread could do with some sort of gc-request/parameter object to tie everything together.

> src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp line 106:
> 
>> 104: 
>> 105:   bool check_cancellation_or_degen(ShenandoahGC::ShenandoahDegenPoint point);
>> 106:   bool resume_concurrent_old_cycle(ShenandoahGeneration* generation, GCCause::Cause cause);
> 
> For these methods returning a boolean result, please add a line of documentation stating what the return values represent, as done for `service_stw_degenerated_cycle` further below.

Will do.

> src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.cpp line 40:
> 
>> 38: void ShenandoahFinalMarkUpdateRegionStateClosure::heap_region_do(ShenandoahHeapRegion* r) {
>> 39:   if (r->is_active()) {
>> 40:     if (_ctx != nullptr) {
> 
> What are the possible circumstances when we might call here with `_ctx == nullptr` ?
> 
> May be a brief comment would be helpful.

Will add a comment here.

> src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.cpp line 70:
> 
>> 68:   } else {
>> 69:     assert(!r->has_live(), "Region " SIZE_FORMAT " should have no live data", r->index());
>> 70:     if (_ctx != nullptr) {
> 
> Nit: The `if` clause could be pulled into the assert as `_ctx == nullptr || ....`.

Okay.

> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 399:
> 
>> 397: }
>> 398: 
>> 399: void ShenandoahOldGeneration::record_success_concurrent(bool abbreviated) {
> 
> Is the `abbreviated` parameter being deliberately ignored here? (Sometimes we specify that intent by naming the parm `ignored` or by specifying `/* ignored */` next to it.) The specification of the method in the corresponding header file should specify the semantics of the parameter and what is being recorded.

No, that is a mistake. I will fix it. Although, I do not think an old cycle can ever be abbreviated, it's a feature we should support one day.

> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp line 82:
> 
>> 80:   virtual void record_success_concurrent(bool abbreviated) override;
>> 81: 
>> 82:   enum State {
> 
> An intended state transition graph would be useful here as a documentation aid/device (or may be in `validate_transition` ?).

I created such a diagram with GraphViz, but haven't translated it to ascii. I will add a simplified diagram.

> src/hotspot/share/gc/shenandoah/shenandoahYoungGeneration.cpp line 46:
> 
>> 44:   ShenandoahHeap* heap = ShenandoahHeap::heap();
>> 45:   heap->set_concurrent_young_mark_in_progress(in_progress);
>> 46:   if (_old_gen_task_queues != nullptr && in_progress && !heap->is_prepare_for_old_mark_in_progress()) {
> 
> Not a change, but what exactly is `_old_gen_task_queues != nullptr` checking? Is it checking if we are in a config where old gen is configured (i.e. generation shenandoah)? If so, this seems a bit subtle and fragile and might be made a more direct check? Indeed what would happen then if the the first conjunct were dropped entirely. I'd expect that the last would always return false and you'd get the desired result anyway?
> 
> It's of course likely I am misunderstanding the rationale behind that check. In which case, perhaps the comment below could be extended to address this.

It's checking if this young collection is a "bootstrap" collection. The non-generational modes are meant to use the `GlobalGeneration` and should not even instantiate the young/old generations.

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

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

From ysr at openjdk.org  Fri Aug  5 08:44:40 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 5 Aug 2022 08:44:40 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
Message-ID: <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>

On Wed, 3 Aug 2022 01:10:57 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
>> 
>> * Before adding old regions to the collection set, their pinned status is synchronized.
>> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
>> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Do not drop abbreviated argument when recording success concurrent cycle
>  - Fix whitespace
>  - Prepare for review
>  - Merge branch 'shenandoah-master' into fill-old-pinned
>  - Validate old gen state transitions
>  - Make use of old generation without down casting
>  - Make verifier aware of changes to old generation state machine
>  - Make rset scan aware of changes to old generation state machine
>  - Fix use of index as count and over-counting of garbage
>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6

One thing I did not manage to figure out is how the work of coalesce and fill is resumed when it is interrupted. May be it can only be canceled and is never resumed after that point? I had expected to see some outer while loop or something repeatedly continuing the unfinished work if it were interrupted.

Thank you for your patient answers as this review was an opportunity to understand some of the code surrounding pinning & coalesce/fill, and their mutual interaction.

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

> 205:     }
> 206: 
> 207:     size_t garbage = region->garbage();

Is `_region_data` above basically a statically allocated scratchpad array that can be used for temporary storage and calculations, and guarantees that it's at least as big as the number of regions in the heap? Typically you use a subset of that array, e.g. in this case you use a prefix for storing collection set candidates.

Is there any sanity checking to ensure that different uses of it do not inadvertently stomp on each others' data? Perhaps there is some state checking somewhere for this in debug/assert mode? Otherwise, it would seem a bit fragile and might pose maintenance headaches down the line.

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

> 210:     if (region->is_regular() || region->is_pinned()) {
> 211:       if (!region->has_live()) {
> 212:         assert(!region->is_pinned(), "Pinned region should have live (pinned) objects.");

This comment pertains to lines 231-234 below for the case where the immediate_regions and immediate_garbage for the humongous regions are being counted. I think while it correctly counts the contribution of the Humongous Continuations, I believe because of the "else if" it misses the contribution of the first Humongous Starts region. 

This isn't a serious issue, however, since it's just a value that is logged rather than being used in guiding any steps/heuristics in the collection. Not your change, but thought I'd mention it.

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

> 272:                _last_old_collection_candidate,
> 273:                byte_size_in_proper_unit(collectable_garbage), proper_unit_for_byte_size(collectable_garbage),
> 274:                byte_size_in_proper_unit(immediate_garbage), proper_unit_for_byte_size(immediate_garbage));

See earlier comment about potentially underreporting `immediate_garbage`. Also, although `immediate_regions` is tracked, it doesn't seem to ever get used anywhere. May be it used to be reported at some point in the past but is no longer? Eliminate its tracking then?

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

Marked as reviewed by ysr (Author).

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

From ysr at openjdk.org  Fri Aug  5 08:44:41 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 5 Aug 2022 08:44:41 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
 <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
Message-ID: <iABbLwlpD8IWRXlCOFjC5Dj0PR0cs_8kid_IYk814LI=.f5eec2fb-e614-454a-a5ca-4b39316dcccd@github.com>

On Fri, 5 Aug 2022 07:22:37 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'shenandoah-master' into fill-old-pinned
>>  - Do not drop abbreviated argument when recording success concurrent cycle
>>  - Fix whitespace
>>  - Prepare for review
>>  - Merge branch 'shenandoah-master' into fill-old-pinned
>>  - Validate old gen state transitions
>>  - Make use of old generation without down casting
>>  - Make verifier aware of changes to old generation state machine
>>  - Make rset scan aware of changes to old generation state machine
>>  - Fix use of index as count and over-counting of garbage
>>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 207:
> 
>> 205:     }
>> 206: 
>> 207:     size_t garbage = region->garbage();
> 
> Is `_region_data` above basically a statically allocated scratchpad array that can be used for temporary storage and calculations, and guarantees that it's at least as big as the number of regions in the heap? Typically you use a subset of that array, e.g. in this case you use a prefix for storing collection set candidates.
> 
> Is there any sanity checking to ensure that different uses of it do not inadvertently stomp on each others' data? Perhaps there is some state checking somewhere for this in debug/assert mode? Otherwise, it would seem a bit fragile and might pose maintenance headaches down the line.

Also, may be this mode of use should be documented clearly (along with extending, as necessary, with sufficient state to detect and report stomping -- say in debug / assert mode).

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

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

From ysr at openjdk.org  Fri Aug  5 08:44:44 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Fri, 5 Aug 2022 08:44:44 GMT
Subject: RFR: Handle old, pinned regions [v5]
In-Reply-To: <Dad8UbKkqNeeq5lDLE4Xtz4jK7dKU4XthbKg_uQ1Nwk=.8c87709f-0250-4b7b-8ad5-61dea3555553@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <mntc1usdtBjVGMTomkJAuw71Ata4qtpLM5rs_NhD0Jo=.c4777477-0f36-43a1-9c1c-9576d264c9ff@github.com>
 <hHVo0Ui4hrEflix11UDuyua-09p4e7Lwg5Cqn_iRj9w=.cc681ea0-b4f0-4b8e-85da-7a770ad909f0@github.com>
 <Dad8UbKkqNeeq5lDLE4Xtz4jK7dKU4XthbKg_uQ1Nwk=.8c87709f-0250-4b7b-8ad5-61dea3555553@github.com>
Message-ID: <SCHiWdOGSq3Qzq_VVZNsvN0Cu0uo6eRGPw9_wSciocI=.33e8c982-4fee-4491-9755-f9cfadbbab57@github.com>

On Thu, 4 Aug 2022 22:18:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 47:
>> 
>>> 45:   // for pinned regions.
>>> 46: 
>>> 47:   // This points to the first candidate of the current mixed collection. This
>> 
>> There is an implied order in first, last, etc. but the criterion for the ordering isn't explained here. (May be it is later.) I think the comment would read better if the high level idea of maintaining this ordered set of candidates was made clear at the outset, and the criteria underlying the order.
>
> They're ordered from most to least garbage. I'll call that out explicitly in the comments.

Upon first reading, I had trouble figuring out what array these numbers were being used as indexes into. It would help to state that in a comment up fromt. Perhaps something like:

"Candidate regions for evacuation are maintained in the _region_data array. The following members are indexes into the array and help with tracking candidate regions, including pinned regions which may not be immediately available for evacuation. When ready they are sorted in order of decreasing garbage. Pinned regions are skipped and accumulate to the left of ... Pinned regions may become unpinned and are then available for evacuation.... Any candidates that were not evacuated before the commencement of a new marking cycle have their garbage payload maximally coalesced and overlaid by fillers to prevent scanning or walking dead objects."

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp line 53:
>> 
>>> 51:   // Pinned regions may not be included in the collection set. Any old regions
>>> 52:   // which were pinned at the time when old regions were added to the mixed
>>> 53:   // collection will have their pointers shifted down so that they are at the
>> 
>> "have their pointers shifted down" is not clear without more context. Nit: Also "pointers" sounds out of place here. You can identify the region pointers with the regions for the purpose of documentation comments here.
>> 
>> Also, I'd pick one consistent terminology, may be first and last (by index), rather than down and up, or left and right, which are more ambiguous (unless it's made clear).
>
> s/their pointers/the pointers to them ? In my head, I was mostly thinking in terms of left (most garbage) and right (least garbage). I will update the variables and comments for consistency.

I was suggesting dropping "pointers" entirely, but just talk about regions. But this, like many of my comments about documentation above, are quite subjective. So, please use your taste and judgement in these cases.

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

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

From kdnilsen at openjdk.org  Fri Aug  5 21:02:09 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 5 Aug 2022 21:02:09 GMT
Subject: RFR: Fix budgeting assertion
Message-ID: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>

An assertion failure revealed problems with evacuation budgeting computations.  Three changes are reflected in this pull request:

1. Memory set aside for the promotion reserve was not excluded from the allocation supplement
2. When the old evacuation reserve is larger than the memory consumed by old evacuation collection set, we loan the excess memory to allocation supplement to make sure this memory is not consumed by promotions.  The number of regions set aside from this reserve for the allocation supplement must be rounded down from the total excess memory.  (Before this patch, it was rounded up.)
3. The assertion test that was failing needed a <= comparison instead of a < comparison.

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

Commit messages:
 - Merge remote-tracking branch 'GitFarmBranch/fix-budgeting-assertion' into fix-budgeting-assertion
 - Remove instrumentation
 - Round down regions proactively loaned for evacuation supplement
 - Add some instrumentation to facilitate debugging
 - Remove promotion_reserve from memory available for allocation supplement

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

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

From wkemper at openjdk.org  Fri Aug  5 22:56:42 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 5 Aug 2022 22:56:42 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
 <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
Message-ID: <-qC4IeA1T_9XYukg3loLAMB0FwX22aFiMsHIwNppH58=.367f0498-3f48-49e4-bdc1-2f3cbb330879@github.com>

On Fri, 5 Aug 2022 08:40:31 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> One thing I did not manage to figure out is how the work of coalesce and fill is resumed when it is interrupted.

The outer loop that drives the state machine for the old generation marking is the `ShenandoahControlThread::run_service` loop. When this thread runs its loop it will inspect the state of things:
 * was there an allocation failure? 
 * was there a system.gc request?
 * is an old generation mark in progress?
When the control thread detects an old generation mark is still in progress, it will invoke `service_concurrent_old_cycle`, which will in turn either resume filling dead objects or marking live objects.

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

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

From wkemper at openjdk.org  Fri Aug  5 23:02:55 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 5 Aug 2022 23:02:55 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
 <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
Message-ID: <kD5Kq33rJoVcXaOR5NxtRX_4IDRPEIRiAK7FXqT-G4M=.1b3cce2e-a7c8-42cb-87f1-3cac4329976d@github.com>

On Fri, 5 Aug 2022 07:00:01 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'shenandoah-master' into fill-old-pinned
>>  - Do not drop abbreviated argument when recording success concurrent cycle
>>  - Fix whitespace
>>  - Prepare for review
>>  - Merge branch 'shenandoah-master' into fill-old-pinned
>>  - Validate old gen state transitions
>>  - Make use of old generation without down casting
>>  - Make verifier aware of changes to old generation state machine
>>  - Make rset scan aware of changes to old generation state machine
>>  - Fix use of index as count and over-counting of garbage
>>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 212:
> 
>> 210:     if (region->is_regular() || region->is_pinned()) {
>> 211:       if (!region->has_live()) {
>> 212:         assert(!region->is_pinned(), "Pinned region should have live (pinned) objects.");
> 
> This comment pertains to lines 231-234 below for the case where the immediate_regions and immediate_garbage for the humongous regions are being counted. I think while it correctly counts the contribution of the Humongous Continuations, I believe because of the "else if" it misses the contribution of the first Humongous Starts region. 
> 
> This isn't a serious issue, however, since it's just a value that is logged rather than being used in guiding any steps/heuristics in the collection. Not your change, but thought I'd mention it.

That's a good catch! Eventually we could have a threshold for the amount of `immediate_garbage` above which we would _not_ continue with the old collection (i.e., we found enough immediate garbage to skip mixed collections). I will open a separate PR to fix this.

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

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

From wkemper at openjdk.org  Fri Aug  5 23:07:43 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 5 Aug 2022 23:07:43 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <iABbLwlpD8IWRXlCOFjC5Dj0PR0cs_8kid_IYk814LI=.f5eec2fb-e614-454a-a5ca-4b39316dcccd@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
 <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
 <iABbLwlpD8IWRXlCOFjC5Dj0PR0cs_8kid_IYk814LI=.f5eec2fb-e614-454a-a5ca-4b39316dcccd@github.com>
Message-ID: <cA_OtHrbd2Uh9rK10jngOzYvA3bOp7TphQsS5EB24fQ=.237b24ca-dd5a-403e-86a9-bd8ea443fc61@github.com>

On Fri, 5 Aug 2022 07:30:19 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 207:
>> 
>>> 205:     }
>>> 206: 
>>> 207:     size_t garbage = region->garbage();
>> 
>> Is `_region_data` above basically a statically allocated scratchpad array that can be used for temporary storage and calculations, and guarantees that it's at least as big as the number of regions in the heap? Typically you use a subset of that array, e.g. in this case you use a prefix for storing collection set candidates.
>> 
>> Is there any sanity checking to ensure that different uses of it do not inadvertently stomp on each others' data? Perhaps there is some state checking somewhere for this in debug/assert mode? Otherwise, it would seem a bit fragile and might pose maintenance headaches down the line.
>
> Also, may be this mode of use should be documented clearly (along with extending, as necessary, with sufficient state to detect and report stomping -- say in debug / assert mode).

Yes, the `_region_data` is essentially a scratch pad for holding pointers to regions we want to include in mixed collections. The field is only used for this purpose though and it's encapsulated by the heuristic class.

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

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

From wkemper at openjdk.org  Fri Aug  5 23:07:55 2022
From: wkemper at openjdk.org (William Kemper)
Date: Fri, 5 Aug 2022 23:07:55 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
 <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
Message-ID: <ZqWqZeRmzv994V8Z_PiVYIKX20uy_KgUN4DbNqvreYY=.6c0dcde1-e71b-451a-821d-98d9b08c8f27@github.com>

On Fri, 5 Aug 2022 07:25:52 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
>> 
>>  - Merge branch 'shenandoah-master' into fill-old-pinned
>>  - Do not drop abbreviated argument when recording success concurrent cycle
>>  - Fix whitespace
>>  - Prepare for review
>>  - Merge branch 'shenandoah-master' into fill-old-pinned
>>  - Validate old gen state transitions
>>  - Make use of old generation without down casting
>>  - Make verifier aware of changes to old generation state machine
>>  - Make rset scan aware of changes to old generation state machine
>>  - Fix use of index as count and over-counting of garbage
>>  - ... and 11 more: https://git.openjdk.org/shenandoah/compare/60e43d04...bdda91d6
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 274:
> 
>> 272:                _last_old_collection_candidate,
>> 273:                byte_size_in_proper_unit(collectable_garbage), proper_unit_for_byte_size(collectable_garbage),
>> 274:                byte_size_in_proper_unit(immediate_garbage), proper_unit_for_byte_size(immediate_garbage));
> 
> See earlier comment about potentially underreporting `immediate_garbage`. Also, although `immediate_regions` is tracked, it doesn't seem to ever get used anywhere. May be it used to be reported at some point in the past but is no longer? Eliminate its tracking then?

I will report it in the log. We intend to use this value in the same fashion as young collections.

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

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

From wkemper at openjdk.org  Sat Aug  6 00:01:10 2022
From: wkemper at openjdk.org (William Kemper)
Date: Sat, 6 Aug 2022 00:01:10 GMT
Subject: RFR: Handle old, pinned regions [v8]
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <WTR4K-nTM6au0RJnDt4DaZuUNA83l3URepTYDFyXB1A=.b0911645-7f51-4471-ae69-a8e6361be20b@github.com>

> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
> 
> * Before adding old regions to the collection set, their pinned status is synchronized.
> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.

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

  Improve documentation, address review comments

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/149/files
  - new: https://git.openjdk.org/shenandoah/pull/149/files/bdda91d6..7b98bc2e

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

  Stats: 96 lines in 7 files changed: 67 ins; 7 del; 22 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 ysr at openjdk.org  Sat Aug  6 00:24:38 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 6 Aug 2022 00:24:38 GMT
Subject: RFR: Fix budgeting assertion
In-Reply-To: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
Message-ID: <l_quNy5TA1XxL6enClop7Bh7IKZyPDg0-0MebX8cAJ0=.420df927-a713-46cd-9b81-6e5ee04cc020@github.com>

On Fri, 5 Aug 2022 20:54:35 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> An assertion failure revealed problems with evacuation budgeting computations.  Three changes are reflected in this pull request:
> 
> 1. Memory set aside for the promotion reserve was not excluded from the allocation supplement
> 2. When the old evacuation reserve is larger than the memory consumed by old evacuation collection set, we loan the excess memory to allocation supplement to make sure this memory is not consumed by promotions.  The number of regions set aside from this reserve for the allocation supplement must be rounded down from the total excess memory.  (Before this patch, it was rounded up.)
> 3. The assertion test that was failing needed a <= comparison instead of a < comparison.

LGTM!

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

Marked as reviewed by ysr (Author).

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

From ysr at openjdk.org  Mon Aug  8 07:09:45 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 8 Aug 2022 07:09:45 GMT
Subject: RFR: Load balance remembered set scanning [v4]
In-Reply-To: <oopj0ZmNp5Lkvp8rkQEOrZSnLmlfla_CemdI_fSD8v0=.a31239b8-8df5-4cf0-a1c7-d970e342832e@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <oopj0ZmNp5Lkvp8rkQEOrZSnLmlfla_CemdI_fSD8v0=.a31239b8-8df5-4cf0-a1c7-d970e342832e@github.com>
Message-ID: <2HJLYD1fvOqHRDNbS0_YdDJ43rcMz8AjEXwRILl9w4w=.45c9014e-c5cb-42e6-8030-5fcd9f222ae1@github.com>

On Mon, 1 Aug 2022 21:56:10 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:
> 
>   Fix white space

Noticed this when playing with the code. I didn't review the rest of the changes, but I think this might be a possible explanation (and a potential fix) for the crashes you were seeing.

I have the fix running SPECjbb successfully, but have not checked if your original code would have elicited the crash you saw with SPECjbb.

src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 127:

> 125:       return;
> 126:     }
> 127: #endif

The crashes are likely because you are pulling an assignment off the worklist, and if you see a cancellation, you are dropping it on the floor and returning.

I think the check should be at the end of the loop after the assignment pulled off the work list has been processed but before the next one is pulled.

Here's a diff that should work:


diff --git a/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp b/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
index 2d7cbbb97dd..03f647f23b2 100644
--- a/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
+++ b/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
@@ -81,15 +81,7 @@ void ShenandoahScanRememberedTask::do_work(uint worker_id) {
   // set up thread local closure for shen ref processor
   _rp->set_mark_closure(worker_id, &cl);
   struct ShenandoahRegionChunk assignment;
-  bool has_work = _work_list->next(&assignment);
-  while (has_work) {
-#ifdef ENABLE_REMEMBERED_SET_CANCELLATION
-    // This check is currently disabled to avoid crashes that occur
-    // when we try to cancel remembered set scanning
-    if (heap->check_cancelled_gc_and_yield(_is_concurrent)) {
-      return;
-    }
-#endif
+  while (_work_list->next(&assignment)) {
     ShenandoahHeapRegion* region = assignment._r;
     log_debug(gc)("ShenandoahScanRememberedTask::do_work(%u), processing slice of region "
                   SIZE_FORMAT " at offset " SIZE_FORMAT ", size: " SIZE_FORMAT,
@@ -101,13 +93,15 @@ void ShenandoahScanRememberedTask::do_work(uint worker_id) {
       assert(clusters * cluster_size == assignment._chunk_size, "Chunk assignments must align on cluster boundaries");
       HeapWord* end_of_range = region->bottom() + assignment._chunk_offset + assignment._chunk_size;
 
-      // During concurrent mark, region->top() equals TAMS with respect to the current young-gen pass.  */
+      // During concurrent mark, region->top() equals TAMS with respect to the current young-gen pass.
       if (end_of_range > region->top()) {
         end_of_range = region->top();
       }
       scanner->process_region_slice(region, assignment._chunk_offset, clusters, end_of_range, &cl, false, _is_concurrent);
     }
-    has_work = _work_list->next(&assignment);
+    if (heap->check_cancelled_gc_and_yield(_is_concurrent)) {
+      return;
+    }
   }
 }

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

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

From kdnilsen at openjdk.org  Mon Aug  8 13:04:58 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 8 Aug 2022 13:04:58 GMT
Subject: RFR: Load balance remembered set scanning [v4]
In-Reply-To: <2HJLYD1fvOqHRDNbS0_YdDJ43rcMz8AjEXwRILl9w4w=.45c9014e-c5cb-42e6-8030-5fcd9f222ae1@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <oopj0ZmNp5Lkvp8rkQEOrZSnLmlfla_CemdI_fSD8v0=.a31239b8-8df5-4cf0-a1c7-d970e342832e@github.com>
 <2HJLYD1fvOqHRDNbS0_YdDJ43rcMz8AjEXwRILl9w4w=.45c9014e-c5cb-42e6-8030-5fcd9f222ae1@github.com>
Message-ID: <qhPn0gfwVDCogiR_DB5Cmy9CUml-DYXzvJPLq2iqxjo=.8325c6c4-00cd-4e91-bbfa-3def6c6d3a91@github.com>

On Mon, 8 Aug 2022 07:03:34 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:
>> 
>>   Fix white space
>
> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 127:
> 
>> 125:       return;
>> 126:     }
>> 127: #endif
> 
> The crashes are likely because you are pulling an assignment off the worklist, and if you see a cancellation, you are dropping it on the floor and returning.
> 
> I think the check should be at the end of the loop after the assignment pulled off the work list has been processed but before the next one is pulled.
> 
> Here's a diff that should work:
> 
> 
> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp b/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
> index 2d7cbbb97dd..03f647f23b2 100644
> --- a/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
> +++ b/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
> @@ -81,15 +81,7 @@ void ShenandoahScanRememberedTask::do_work(uint worker_id) {
>    // set up thread local closure for shen ref processor
>    _rp->set_mark_closure(worker_id, &cl);
>    struct ShenandoahRegionChunk assignment;
> -  bool has_work = _work_list->next(&assignment);
> -  while (has_work) {
> -#ifdef ENABLE_REMEMBERED_SET_CANCELLATION
> -    // This check is currently disabled to avoid crashes that occur
> -    // when we try to cancel remembered set scanning
> -    if (heap->check_cancelled_gc_and_yield(_is_concurrent)) {
> -      return;
> -    }
> -#endif
> +  while (_work_list->next(&assignment)) {
>      ShenandoahHeapRegion* region = assignment._r;
>      log_debug(gc)("ShenandoahScanRememberedTask::do_work(%u), processing slice of region "
>                    SIZE_FORMAT " at offset " SIZE_FORMAT ", size: " SIZE_FORMAT,
> @@ -101,13 +93,15 @@ void ShenandoahScanRememberedTask::do_work(uint worker_id) {
>        assert(clusters * cluster_size == assignment._chunk_size, "Chunk assignments must align on cluster boundaries");
>        HeapWord* end_of_range = region->bottom() + assignment._chunk_offset + assignment._chunk_size;
>  
> -      // During concurrent mark, region->top() equals TAMS with respect to the current young-gen pass.  */
> +      // During concurrent mark, region->top() equals TAMS with respect to the current young-gen pass.
>        if (end_of_range > region->top()) {
>          end_of_range = region->top();
>        }
>        scanner->process_region_slice(region, assignment._chunk_offset, clusters, end_of_range, &cl, false, _is_concurrent);
>      }
> -    has_work = _work_list->next(&assignment);
> +    if (heap->check_cancelled_gc_and_yield(_is_concurrent)) {
> +      return;
> +    }
>    }
>  }

Thanks very much for figuring out this problem.  I'd like to address this change in a different pull request to keep the history cleaner.

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

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

From kdnilsen at openjdk.org  Mon Aug  8 13:06:48 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Mon, 8 Aug 2022 13:06:48 GMT
Subject: RFR: Fix budgeting assertion
In-Reply-To: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
Message-ID: <PFn-hFffmQlyhkAme4sFZLHRKVtiO49URgwkL1sCKEo=.fc3187ec-f3e2-4987-b459-f00331833ee2@github.com>

On Fri, 5 Aug 2022 20:54:35 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> An assertion failure revealed problems with evacuation budgeting computations.  Three changes are reflected in this pull request:
> 
> 1. Memory set aside for the promotion reserve was not excluded from the allocation supplement
> 2. When the old evacuation reserve is larger than the memory consumed by old evacuation collection set, we loan the excess memory to allocation supplement to make sure this memory is not consumed by promotions.  The number of regions set aside from this reserve for the allocation supplement must be rounded down from the total excess memory.  (Before this patch, it was rounded up.)
> 3. The assertion test that was failing needed a <= comparison instead of a < comparison.

There's another assertion failure related to evacuating budgeting that has turned up.  After investigating this issue, I want to make one other change to this code before we merge it.

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

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

From ysr at openjdk.org  Mon Aug  8 16:11:47 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 8 Aug 2022 16:11:47 GMT
Subject: RFR: Load balance remembered set scanning [v4]
In-Reply-To: <qhPn0gfwVDCogiR_DB5Cmy9CUml-DYXzvJPLq2iqxjo=.8325c6c4-00cd-4e91-bbfa-3def6c6d3a91@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <oopj0ZmNp5Lkvp8rkQEOrZSnLmlfla_CemdI_fSD8v0=.a31239b8-8df5-4cf0-a1c7-d970e342832e@github.com>
 <2HJLYD1fvOqHRDNbS0_YdDJ43rcMz8AjEXwRILl9w4w=.45c9014e-c5cb-42e6-8030-5fcd9f222ae1@github.com>
 <qhPn0gfwVDCogiR_DB5Cmy9CUml-DYXzvJPLq2iqxjo=.8325c6c4-00cd-4e91-bbfa-3def6c6d3a91@github.com>
Message-ID: <dV-XtFtzOF1LrScPJeSDAiwD2O7JQQ8zwlKc2fbxYhg=.2cf265f1-fd3a-42f3-bbde-589e1a212e7d@github.com>

On Mon, 8 Aug 2022 13:01:09 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp line 127:
>> 
>>> 125:       return;
>>> 126:     }
>>> 127: #endif
>> 
>> The crashes are likely because you are pulling an assignment off the worklist, and if you see a cancellation, you are dropping it on the floor and returning.
>> 
>> I think the check should be at the end of the loop after the assignment pulled off the work list has been processed but before the next one is pulled.
>> 
>> Here's a diff that should work:
>> 
>> 
>> diff --git a/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp b/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
>> index 2d7cbbb97dd..03f647f23b2 100644
>> --- a/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
>> +++ b/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp
>> @@ -81,15 +81,7 @@ void ShenandoahScanRememberedTask::do_work(uint worker_id) {
>>    // set up thread local closure for shen ref processor
>>    _rp->set_mark_closure(worker_id, &cl);
>>    struct ShenandoahRegionChunk assignment;
>> -  bool has_work = _work_list->next(&assignment);
>> -  while (has_work) {
>> -#ifdef ENABLE_REMEMBERED_SET_CANCELLATION
>> -    // This check is currently disabled to avoid crashes that occur
>> -    // when we try to cancel remembered set scanning
>> -    if (heap->check_cancelled_gc_and_yield(_is_concurrent)) {
>> -      return;
>> -    }
>> -#endif
>> +  while (_work_list->next(&assignment)) {
>>      ShenandoahHeapRegion* region = assignment._r;
>>      log_debug(gc)("ShenandoahScanRememberedTask::do_work(%u), processing slice of region "
>>                    SIZE_FORMAT " at offset " SIZE_FORMAT ", size: " SIZE_FORMAT,
>> @@ -101,13 +93,15 @@ void ShenandoahScanRememberedTask::do_work(uint worker_id) {
>>        assert(clusters * cluster_size == assignment._chunk_size, "Chunk assignments must align on cluster boundaries");
>>        HeapWord* end_of_range = region->bottom() + assignment._chunk_offset + assignment._chunk_size;
>>  
>> -      // During concurrent mark, region->top() equals TAMS with respect to the current young-gen pass.  */
>> +      // During concurrent mark, region->top() equals TAMS with respect to the current young-gen pass.
>>        if (end_of_range > region->top()) {
>>          end_of_range = region->top();
>>        }
>>        scanner->process_region_slice(region, assignment._chunk_offset, clusters, end_of_range, &cl, false, _is_concurrent);
>>      }
>> -    has_work = _work_list->next(&assignment);
>> +    if (heap->check_cancelled_gc_and_yield(_is_concurrent)) {
>> +      return;
>> +    }
>>    }
>>  }
>
> Thanks very much for figuring out this problem.  I'd like to address this change in a different pull request to keep the history cleaner.

?

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

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

From wkemper at openjdk.org  Mon Aug  8 17:43:11 2022
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 8 Aug 2022 17:43:11 GMT
Subject: RFR: Include old humongous start regions when counting immediate
 garbage
Message-ID: <AftSndKcnYAcqyNOorBWMQEXJXIwkaLsBcdKwtmCjL4=.e2e6ec14-ddf5-4a26-a6cf-cf94185eb2cf@github.com>

We only log these values, but we expect to one day use them to possibly shortcut an old generation collection in the same fashion as the young generation.

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

Commit messages:
 - Include old humongous start regions when counting immediate garbage

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

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

From ysr at openjdk.org  Mon Aug  8 17:57:35 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 8 Aug 2022 17:57:35 GMT
Subject: RFR: Include old humongous start regions when counting immediate
 garbage
In-Reply-To: <AftSndKcnYAcqyNOorBWMQEXJXIwkaLsBcdKwtmCjL4=.e2e6ec14-ddf5-4a26-a6cf-cf94185eb2cf@github.com>
References: <AftSndKcnYAcqyNOorBWMQEXJXIwkaLsBcdKwtmCjL4=.e2e6ec14-ddf5-4a26-a6cf-cf94185eb2cf@github.com>
Message-ID: <DmCHVrkov4DghtefnGB4xxyKLiO_j2JEdjqr3rxzWJA=.64af2dfe-2209-4084-81a2-a4371d5674da@github.com>

On Mon, 8 Aug 2022 17:36:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We only log these values, but we expect to one day use them to possibly shortcut an old generation collection in the same fashion as the young generation.

Ship it!

( ref: https://github.com/openjdk/shenandoah/pull/149/files/bdda91d68dc5bf09f53e30815b63b29b865a25b5#r938504467 )

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

Marked as reviewed by ysr (Author).

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

From ysr at openjdk.org  Mon Aug  8 18:21:41 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 8 Aug 2022 18:21:41 GMT
Subject: RFR: Handle old, pinned regions [v7]
In-Reply-To: <kD5Kq33rJoVcXaOR5NxtRX_4IDRPEIRiAK7FXqT-G4M=.1b3cce2e-a7c8-42cb-87f1-3cac4329976d@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
 <qgoqIqV40A6cqSKYCUNxZSAqOBNH47uGHezkk--TpDA=.333ebd8e-f330-4a83-aaa5-93e43b319825@github.com>
 <NA7GN1N3Y4r69X_6zvgV9ocqhQNdYP7_g-NEEnlYAPo=.7f0b6723-c190-4b6a-bf5a-ef98c60d655a@github.com>
 <kD5Kq33rJoVcXaOR5NxtRX_4IDRPEIRiAK7FXqT-G4M=.1b3cce2e-a7c8-42cb-87f1-3cac4329976d@github.com>
Message-ID: <vbVyL2mM4U8fVPZ8mVAmfkHO7D27r8ssY4Zkh5DJ_s4=.3190474d-bd6a-48b4-a761-6fa54e466ace@github.com>

On Fri, 5 Aug 2022 22:58:46 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 212:
>> 
>>> 210:     if (region->is_regular() || region->is_pinned()) {
>>> 211:       if (!region->has_live()) {
>>> 212:         assert(!region->is_pinned(), "Pinned region should have live (pinned) objects.");
>> 
>> This comment pertains to lines 231-234 below for the case where the immediate_regions and immediate_garbage for the humongous regions are being counted. I think while it correctly counts the contribution of the Humongous Continuations, I believe because of the "else if" it misses the contribution of the first Humongous Starts region. 
>> 
>> This isn't a serious issue, however, since it's just a value that is logged rather than being used in guiding any steps/heuristics in the collection. Not your change, but thought I'd mention it.
>
> That's a good catch! Eventually we could have a threshold for the amount of `immediate_garbage` above which we would _not_ continue with the old collection (i.e., we found enough immediate garbage to skip mixed collections). I will open a separate PR to fix this.

Thanks! Closing the loop by linking the PR: https://github.com/openjdk/shenandoah/pull/157

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

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

From ysr at openjdk.org  Mon Aug  8 20:10:47 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 8 Aug 2022 20:10:47 GMT
Subject: RFR: Load balance remembered set scanning [v4]
In-Reply-To: <dV-XtFtzOF1LrScPJeSDAiwD2O7JQQ8zwlKc2fbxYhg=.2cf265f1-fd3a-42f3-bbde-589e1a212e7d@github.com>
References: <4sfwLJzdf6PTAeyEocKdCIsLbTbgYRjhU3SVXylKnSM=.01f77836-0b59-47c3-8a58-5ec01af7ff04@github.com>
 <oopj0ZmNp5Lkvp8rkQEOrZSnLmlfla_CemdI_fSD8v0=.a31239b8-8df5-4cf0-a1c7-d970e342832e@github.com>
 <2HJLYD1fvOqHRDNbS0_YdDJ43rcMz8AjEXwRILl9w4w=.45c9014e-c5cb-42e6-8030-5fcd9f222ae1@github.com>
 <qhPn0gfwVDCogiR_DB5Cmy9CUml-DYXzvJPLq2iqxjo=.8325c6c4-00cd-4e91-bbfa-3def6c6d3a91@github.com>
 <dV-XtFtzOF1LrScPJeSDAiwD2O7JQQ8zwlKc2fbxYhg=.2cf265f1-fd3a-42f3-bbde-589e1a212e7d@github.com>
Message-ID: <g60K0wH5kCyLpFh1ipPlZguXcQo0RDJPUsC5ezTJxGo=.136d9fe6-3336-4a77-8bf1-76d073745a36@github.com>

On Mon, 8 Aug 2022 16:09:40 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Thanks very much for figuring out this problem.  I'd like to address this change in a different pull request to keep the history cleaner.
>
> ?

I left a SPECjbb run overnight with the changes, but alas it still does crash (slowdebug mode) during a deoptimization, presumably because of a bad oop on the stack. I'll file a ticket to track the issue, but it does seem like there's some other issue besides the one pointed out above.

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

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

From kdnilsen at openjdk.org  Tue Aug  9 16:19:39 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Aug 2022 16:19:39 GMT
Subject: RFR: Fix budgeting assertion [v2]
In-Reply-To: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
Message-ID: <4CCIpVv9QkBcRsZnX9CSwDtLpuon5_GcLTSyfgwUbq8=.265ee314-34b2-4a24-ad34-15562ef9620c@github.com>

> An assertion failure revealed problems with evacuation budgeting computations.  Three changes are reflected in this pull request:
> 
> 1. Memory set aside for the promotion reserve was not excluded from the allocation supplement
> 2. When the old evacuation reserve is larger than the memory consumed by old evacuation collection set, we loan the excess memory to allocation supplement to make sure this memory is not consumed by promotions.  The number of regions set aside from this reserve for the allocation supplement must be rounded down from the total excess memory.  (Before this patch, it was rounded up.)
> 3. The assertion test that was failing needed a <= comparison instead of a < comparison.

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

 - Remove instrumentation
 - Fix choose_collection_set to use region->index after quicksort
   
   After region data is sorted in garbage order, index within the region
   data array no longer matches the region->index().  Use the
   region->index() to test whether the region was pre-selected rather than
   using the index within the region data array.  Very confusing that this
   code ever worked.  Perhaps this bug was introduced by some sort of merge
   conflict.
 - Assure that aged young regions are not promoted if not pre-selected
   
   In the case that an aged young region is not pre-selected, it should not
   be included in the collection set because there is not enough room in
   old-gen to hold its promoted contents.

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/156/files
  - new: https://git.openjdk.org/shenandoah/pull/156/files/e727640c..7d256dba

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

  Stats: 43 lines in 1 file changed: 27 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/shenandoah/pull/156.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/156/head:pull/156

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

From kdnilsen at openjdk.org  Tue Aug  9 16:30:49 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Tue, 9 Aug 2022 16:30:49 GMT
Subject: RFR: Include old humongous start regions when counting immediate
 garbage
In-Reply-To: <AftSndKcnYAcqyNOorBWMQEXJXIwkaLsBcdKwtmCjL4=.e2e6ec14-ddf5-4a26-a6cf-cf94185eb2cf@github.com>
References: <AftSndKcnYAcqyNOorBWMQEXJXIwkaLsBcdKwtmCjL4=.e2e6ec14-ddf5-4a26-a6cf-cf94185eb2cf@github.com>
Message-ID: <YfAFzqwNULoY2tvmseNW1ZnO7h-0exVqOO63VlQu5bo=.b9cb62ef-5cb7-44aa-b2da-335e0804e60b@github.com>

On Mon, 8 Aug 2022 17:36:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We only log these values, but we expect to one day use them to possibly shortcut an old generation collection in the same fashion as the young generation.

Marked as reviewed by kdnilsen (Committer).

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

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

From wkemper at openjdk.org  Tue Aug  9 18:11:05 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 9 Aug 2022 18:11:05 GMT
Subject: Integrated: Include old humongous start regions when counting
 immediate garbage
In-Reply-To: <AftSndKcnYAcqyNOorBWMQEXJXIwkaLsBcdKwtmCjL4=.e2e6ec14-ddf5-4a26-a6cf-cf94185eb2cf@github.com>
References: <AftSndKcnYAcqyNOorBWMQEXJXIwkaLsBcdKwtmCjL4=.e2e6ec14-ddf5-4a26-a6cf-cf94185eb2cf@github.com>
Message-ID: <7UqnqI-E6Hb23d3Rhk3khKfy24Z-AOjQ6hJpGZbCnQk=.95b0b858-d573-4ff4-a7d5-a8f8b2b9c425@github.com>

On Mon, 8 Aug 2022 17:36:42 GMT, William Kemper <wkemper at openjdk.org> wrote:

> We only log these values, but we expect to one day use them to possibly shortcut an old generation collection in the same fashion as the young generation.

This pull request has now been integrated.

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

Include old humongous start regions when counting immediate garbage

Reviewed-by: ysr, kdnilsen

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

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

From wkemper at openjdk.org  Tue Aug  9 18:14:07 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 9 Aug 2022 18:14:07 GMT
Subject: RFR: Fix budgeting assertion [v2]
In-Reply-To: <4CCIpVv9QkBcRsZnX9CSwDtLpuon5_GcLTSyfgwUbq8=.265ee314-34b2-4a24-ad34-15562ef9620c@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
 <4CCIpVv9QkBcRsZnX9CSwDtLpuon5_GcLTSyfgwUbq8=.265ee314-34b2-4a24-ad34-15562ef9620c@github.com>
Message-ID: <tj3vGwpwDm19I6thkQmjaMIWpDBdlwEzAVBpZOBisYg=.56463063-49b9-43f9-8024-c2f2bc1e0f05@github.com>

On Tue, 9 Aug 2022 16:19:39 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> An assertion failure revealed problems with evacuation budgeting computations.  Three changes are reflected in this pull request:
>> 
>> 1. Memory set aside for the promotion reserve was not excluded from the allocation supplement
>> 2. When the old evacuation reserve is larger than the memory consumed by old evacuation collection set, we loan the excess memory to allocation supplement to make sure this memory is not consumed by promotions.  The number of regions set aside from this reserve for the allocation supplement must be rounded down from the total excess memory.  (Before this patch, it was rounded up.)
>> 3. The assertion test that was failing needed a <= comparison instead of a < comparison.
>
> Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove instrumentation
>  - Fix choose_collection_set to use region->index after quicksort
>    
>    After region data is sorted in garbage order, index within the region
>    data array no longer matches the region->index().  Use the
>    region->index() to test whether the region was pre-selected rather than
>    using the index within the region data array.  Very confusing that this
>    code ever worked.  Perhaps this bug was introduced by some sort of merge
>    conflict.
>  - Assure that aged young regions are not promoted if not pre-selected
>    
>    In the case that an aged young region is not pre-selected, it should not
>    be included in the collection set because there is not enough room in
>    old-gen to hold its promoted contents.

Marked as reviewed by wkemper (Committer).

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

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

From wkemper at openjdk.org  Tue Aug  9 18:14:48 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 9 Aug 2022 18:14:48 GMT
Subject: git: openjdk/shenandoah: master: Handle old, pinned regions
Message-ID: <7d5d4f3b-41d0-4a54-b99f-b62cd82aea2a@openjdk.org>

Changeset: 6acf4e56
Author:    William Kemper <wkemper at openjdk.org>
Date:      2022-08-09 18:13:45 +0000
URL:       https://git.openjdk.org/shenandoah/commit/6acf4e56d490fe956c5bdc2f72602295af8d6dd2

Handle old, pinned regions

Reviewed-by: ysr, kdnilsen

! src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp
! src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp
! src/hotspot/share/gc/shenandoah/shenandoahConcurrentGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp
! src/hotspot/share/gc/shenandoah/shenandoahDegeneratedGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp
! src/hotspot/share/gc/shenandoah/shenandoahFullGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp
! src/hotspot/share/gc/shenandoah/shenandoahInitLogger.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.cpp
! src/hotspot/share/gc/shenandoah/shenandoahMarkClosures.hpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGC.hpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahRegulatorThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUtils.cpp
! src/hotspot/share/gc/shenandoah/shenandoahVMOperations.hpp
! src/hotspot/share/gc/shenandoah/shenandoahYoungGeneration.cpp
+ test/hotspot/gtest/gc/shenandoah/test_shenandoahOldHeuristic.cpp


From wkemper at openjdk.org  Tue Aug  9 18:17:31 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 9 Aug 2022 18:17:31 GMT
Subject: Integrated: Handle old, pinned regions
In-Reply-To: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
References: <Fec72l5R2-sxRL4uMZwQ15Nv8J4x5jLAPARLbeBWWx0=.5f6ffea4-d550-4486-9c72-7db350a0ad8b@github.com>
Message-ID: <1tzVwG8Sf2124N_MsucoeYGI7Q2K6Kp30oliRelgRFw=.8de4108a-e381-448f-81fd-09202894d493@github.com>

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

> Prior to this change, mixed collections were entirely ignoring the pinned status of old regions. Pinned old regions would not be coalesced and filled (which could lead to a crash) and their pin status was not being synchronized with the pin count (which could also lead to a crash). To address these problems, the following changes have been made:
> 
> * Before adding old regions to the collection set, their pinned status is synchronized.
> * Pinned old regions will _not_ be added to a mixed collection, they will be skipped and considered for inclusion in the next mixed collection.
> * Any old regions which have not been evacuated after the last mixed collection will be made parseable (coalesced and filled) _at the start of the next old marking cycle_.

This pull request has now been integrated.

Changeset: 6acf4e56
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/6acf4e56d490fe956c5bdc2f72602295af8d6dd2
Stats:     1255 lines in 29 files changed: 806 ins; 279 del; 170 mod

Handle old, pinned regions

Reviewed-by: ysr, kdnilsen

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

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

From vlivanov at openjdk.org  Wed Aug 10 00:55:16 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 10 Aug 2022 00:55:16 GMT
Subject: RFR: 8292153: x86: Represent Registers as values
Message-ID: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>

As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads.

Proposed change hides pointer representation behind value class.

Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).

Code quality doesn't suffer (and even slightly improves):
  https://godbolt.org/z/d8dGM1eY1

(I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)

Testing: hs-tier1 - hs-tier5

PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

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

Commit messages:
 - x86: Register class wrappers

Changes: https://git.openjdk.org/jdk/pull/9815/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9815&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292153
  Stats: 557 lines in 28 files changed: 153 ins; 89 del; 315 mod
  Patch: https://git.openjdk.org/jdk/pull/9815.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9815/head:pull/9815

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

From aph at openjdk.org  Wed Aug 10 10:07:37 2022
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 10 Aug 2022 10:07:37 GMT
Subject: RFR: 8292153: x86: Represent Registers as values
In-Reply-To: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>
References: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>
Message-ID: <Cm5ONvsmOH5JBiDU5bjsY03OvQm_fSbdwBfcu489uu4=.a62b43fa-66a3-4cff-94d1-c5b845f1662b@github.com>

On Tue, 9 Aug 2022 23:25:27 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads.
> 
> Proposed change hides pointer representation behind value class.
> 
> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> Code quality doesn't suffer (and even slightly improves):
>   https://godbolt.org/z/d8dGM1eY1
> 
> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
> 
> Testing: hs-tier1 - hs-tier5
> 
> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

src/hotspot/cpu/x86/stubGenerator_x86_32.cpp line 3509:

> 3507:     const Register g = rsi;
> 3508:     const Register h = rdi;
> 3509:     const Register empty = noreg; // will never be used, in order not

Shade and I were looking at this bug a week or so ago, but agreed to leave it because this patch would find and fix it. Good!

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

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

From ysr at openjdk.org  Wed Aug 10 17:22:26 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 10 Aug 2022 17:22:26 GMT
Subject: RFR: Fix budgeting assertion [v2]
In-Reply-To: <4CCIpVv9QkBcRsZnX9CSwDtLpuon5_GcLTSyfgwUbq8=.265ee314-34b2-4a24-ad34-15562ef9620c@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
 <4CCIpVv9QkBcRsZnX9CSwDtLpuon5_GcLTSyfgwUbq8=.265ee314-34b2-4a24-ad34-15562ef9620c@github.com>
Message-ID: <8G5uicuX2foAy6gRO6M9jWJvNrq0UtXR9WsZXDfpoAM=.719f4043-280f-4b3d-a143-916cecc5c587@github.com>

On Tue, 9 Aug 2022 16:19:39 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> An assertion failure revealed problems with evacuation budgeting computations.  Three changes are reflected in this pull request:
>> 
>> 1. Memory set aside for the promotion reserve was not excluded from the allocation supplement
>> 2. When the old evacuation reserve is larger than the memory consumed by old evacuation collection set, we loan the excess memory to allocation supplement to make sure this memory is not consumed by promotions.  The number of regions set aside from this reserve for the allocation supplement must be rounded down from the total excess memory.  (Before this patch, it was rounded up.)
>> 3. The assertion test that was failing needed a <= comparison instead of a < comparison.
>
> Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove instrumentation
>  - Fix choose_collection_set to use region->index after quicksort
>    
>    After region data is sorted in garbage order, index within the region
>    data array no longer matches the region->index().  Use the
>    region->index() to test whether the region was pre-selected rather than
>    using the index within the region data array.  Very confusing that this
>    code ever worked.  Perhaps this bug was introduced by some sort of merge
>    conflict.
>  - Assure that aged young regions are not promoted if not pre-selected
>    
>    In the case that an aged young region is not pre-selected, it should not
>    be included in the collection set because there is not enough room in
>    old-gen to hold its promoted contents.

Some minor comments on structure of the method and a possible refactoring, and on naming & documenting of some variables.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 126:

> 124:             old_cur_cset = new_cset;
> 125:           }
> 126:         } else if (cset->is_preselected(r->index())) {

It might be a good idea for all the `choose_collection_set*` methods that use `is_preselected` to assert that cset's `_preselected_regions` isn't null, perhaps via an `is_preselected_established` (or appropriately named assert_only method that asserts that `_preselected_regions != NULL`

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 136:

> 134:           // reclaim highly utilized young-gen regions just for the sake of finding min_garbage to reclaim
> 135:           // within youn-gen memory
> 136:           cur_young_garbage += r->get_live_data_bytes();

Isn't `r->garbage() + r->get_live_data_bytes()` equal to `r->used()`?

I am not sure I understand the reasoning here. I would much rather we named the `cur_young_garbage` variable more correctly if it is counting the amount of young regions that are in some sense being "removed from the young generation" (if indeed that's how to interpret it).

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

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

From ysr at openjdk.org  Wed Aug 10 17:22:27 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Wed, 10 Aug 2022 17:22:27 GMT
Subject: RFR: Fix budgeting assertion [v2]
In-Reply-To: <8G5uicuX2foAy6gRO6M9jWJvNrq0UtXR9WsZXDfpoAM=.719f4043-280f-4b3d-a143-916cecc5c587@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
 <4CCIpVv9QkBcRsZnX9CSwDtLpuon5_GcLTSyfgwUbq8=.265ee314-34b2-4a24-ad34-15562ef9620c@github.com>
 <8G5uicuX2foAy6gRO6M9jWJvNrq0UtXR9WsZXDfpoAM=.719f4043-280f-4b3d-a143-916cecc5c587@github.com>
Message-ID: <6dCRCgYA0WvyRisYpxZRqCZz_cCTRGUixQq6tPpQvFY=.96bd49f5-5338-4cc3-b60d-3cd7309ee39e@github.com>

On Wed, 10 Aug 2022 17:02:28 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove instrumentation
>>  - Fix choose_collection_set to use region->index after quicksort
>>    
>>    After region data is sorted in garbage order, index within the region
>>    data array no longer matches the region->index().  Use the
>>    region->index() to test whether the region was pre-selected rather than
>>    using the index within the region data array.  Very confusing that this
>>    code ever worked.  Perhaps this bug was introduced by some sort of merge
>>    conflict.
>>  - Assure that aged young regions are not promoted if not pre-selected
>>    
>>    In the case that an aged young region is not pre-selected, it should not
>>    be included in the collection set because there is not enough room in
>>    old-gen to hold its promoted contents.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 136:
> 
>> 134:           // reclaim highly utilized young-gen regions just for the sake of finding min_garbage to reclaim
>> 135:           // within youn-gen memory
>> 136:           cur_young_garbage += r->get_live_data_bytes();
> 
> Isn't `r->garbage() + r->get_live_data_bytes()` equal to `r->used()`?
> 
> I am not sure I understand the reasoning here. I would much rather we named the `cur_young_garbage` variable more correctly if it is counting the amount of young regions that are in some sense being "removed from the young generation" (if indeed that's how to interpret it).

Might be a good idea to describe at line 97, what `cur_young_garbage` will track as you process regions and build the collection set. Similarly, young_curset etc.

I see three separate outer if/else statements covering respectively the cases of generational/global, generational/not global, and non-generational cases. Would it read more easily and make for more easily maintained code to refactor into 3 separate cset builders called for each of the three cases, if necessary from the top level method (but even better if called from different contexts to specialize early hoisting the check on the type of collection up into the highest caller that has the information, rather than having all of them in one single, somewhat long and somewhat unwieldy method?

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

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

From vlivanov at openjdk.org  Wed Aug 10 21:10:51 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 10 Aug 2022 21:10:51 GMT
Subject: RFR: 8292153: x86: Represent Registers as values [v2]
In-Reply-To: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>
References: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>
Message-ID: <RqaY4Q9x97gVDWWMY7CHnnZF92XhusQ3q67v2qpqhzw=.e798ddfd-6536-4713-8021-974b60b78f28@github.com>

> As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads.
> 
> Proposed change hides pointer representation behind value class.
> 
> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> Code quality doesn't suffer (and even slightly improves):
>   https://godbolt.org/z/d8dGM1eY1
> 
> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
> 
> Testing: hs-tier1 - hs-tier5
> 
> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  cleanups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9815/files
  - new: https://git.openjdk.org/jdk/pull/9815/files/4cb98cbd..478d4bed

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

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

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

From kvn at openjdk.org  Thu Aug 11 02:00:39 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 11 Aug 2022 02:00:39 GMT
Subject: RFR: 8292153: x86: Represent Registers as values [v2]
In-Reply-To: <RqaY4Q9x97gVDWWMY7CHnnZF92XhusQ3q67v2qpqhzw=.e798ddfd-6536-4713-8021-974b60b78f28@github.com>
References: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>
 <RqaY4Q9x97gVDWWMY7CHnnZF92XhusQ3q67v2qpqhzw=.e798ddfd-6536-4713-8021-974b60b78f28@github.com>
Message-ID: <xlIklCYRGl2qaWKXp_r1BwSwOW_OkwyaA4cv2OhSRsQ=.84c007f2-4bce-43f5-a02d-ed17d2c39e32@github.com>

On Wed, 10 Aug 2022 21:10:51 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads.
>> 
>> Proposed change hides pointer representation behind value class.
>> 
>> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
>> 
>> Code quality doesn't suffer (and even slightly improves):
>>   https://godbolt.org/z/d8dGM1eY1
>> 
>> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
>> 
>> Testing: hs-tier1 - hs-tier5
>> 
>> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanups

Looks good to me.

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

Marked as reviewed by kvn (Reviewer).

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

From vlivanov at openjdk.org  Thu Aug 11 05:11:41 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 11 Aug 2022 05:11:41 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values
Message-ID: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>

(It's a PR dependent on #9815.)

Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.

The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.

Proposed change hides pointer representation behind value class.

Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).

Code quality improves:
  GCC:   https://godbolt.org/z/r6G36facj
  Clang: https://godbolt.org/z/x5oPdYEPM

(I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)

Testing: hs-tier1 - hs-tier5

PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

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

Commit messages:
 - 8292203: AArch64: Represent Registers as values
 - cleanups
 - x86: Register class wrappers

Changes: https://git.openjdk.org/jdk/pull/9826/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292203
  Stats: 1102 lines in 43 files changed: 273 ins; 156 del; 673 mod
  Patch: https://git.openjdk.org/jdk/pull/9826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9826/head:pull/9826

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

From aph at openjdk.org  Thu Aug 11 08:48:45 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 11 Aug 2022 08:48:45 GMT
Subject: RFR: 8292153: x86: Represent Registers as values [v2]
In-Reply-To: <RqaY4Q9x97gVDWWMY7CHnnZF92XhusQ3q67v2qpqhzw=.e798ddfd-6536-4713-8021-974b60b78f28@github.com>
References: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>
 <RqaY4Q9x97gVDWWMY7CHnnZF92XhusQ3q67v2qpqhzw=.e798ddfd-6536-4713-8021-974b60b78f28@github.com>
Message-ID: <lhqOaNFI7RstBE0lHa6p8FdQIFawaKEoj-s4c2dfe2c=.9702db0a-2b3a-4d5c-bea2-70365cb68f78@github.com>

On Wed, 10 Aug 2022 21:10:51 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads.
>> 
>> Proposed change hides pointer representation behind value class.
>> 
>> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
>> 
>> Code quality doesn't suffer (and even slightly improves):
>>   https://godbolt.org/z/d8dGM1eY1
>> 
>> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
>> 
>> Testing: hs-tier1 - hs-tier5
>> 
>> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanups

Marked as reviewed by aph (Reviewer).

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

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

From kvn at openjdk.org  Thu Aug 11 19:52:16 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Thu, 11 Aug 2022 19:52:16 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values
In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
Message-ID: <n93_nB7_HpB6cVAVYrWBbD2C0yvxow77XwmZTo-rHss=.62778118-c846-4f00-ba0b-41a051df75aa@github.com>

On Wed, 10 Aug 2022 21:44:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> (It's a PR dependent on #9815.)
> 
> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
> 
> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
> 
> Proposed change hides pointer representation behind value class.
> 
> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> Code quality improves:
>   GCC:   https://godbolt.org/z/r6G36facj
>   Clang: https://godbolt.org/z/x5oPdYEPM
> 
> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
> 
> Testing: hs-tier1 - hs-tier5
> 
> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

I looked on aarch64 changes. Looks fine.
The rest come from #9815 as I understand.

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

Marked as reviewed by kvn (Reviewer).

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

From vlivanov at openjdk.org  Thu Aug 11 21:17:00 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 11 Aug 2022 21:17:00 GMT
Subject: RFR: 8292153: x86: Represent Registers as values [v2]
In-Reply-To: <RqaY4Q9x97gVDWWMY7CHnnZF92XhusQ3q67v2qpqhzw=.e798ddfd-6536-4713-8021-974b60b78f28@github.com>
References: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>
 <RqaY4Q9x97gVDWWMY7CHnnZF92XhusQ3q67v2qpqhzw=.e798ddfd-6536-4713-8021-974b60b78f28@github.com>
Message-ID: <v-7U1p7GDJC6DnspJ9y6OjX6f7mXoHSJIEnOmoMpJbI=.94b1eb65-16ba-4ef3-9593-fa9ecbef166e@github.com>

On Wed, 10 Aug 2022 21:10:51 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads.
>> 
>> Proposed change hides pointer representation behind value class.
>> 
>> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
>> 
>> Code quality doesn't suffer (and even slightly improves):
>>   https://godbolt.org/z/d8dGM1eY1
>> 
>> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
>> 
>> Testing: hs-tier1 - hs-tier5
>> 
>> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanups

Thanks for the reviews, Vladimir and Andrew.

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

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

From vlivanov at openjdk.org  Thu Aug 11 21:19:58 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 11 Aug 2022 21:19:58 GMT
Subject: Integrated: 8292153: x86: Represent Registers as values
In-Reply-To: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>
References: <nP70jbNmLFMrHrtIPxYrSPFtYqNbzoIFx6HocnmKt48=.46b1a09d-b03b-48de-843e-5cc2670c3b8b@github.com>
Message-ID: <vouzQVojgAYgZS9siza_DDa1O_5zTH2q-GW8w0Dx43A=.914c6849-d568-4172-aa14-f70cde48249d@github.com>

On Tue, 9 Aug 2022 23:25:27 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> As of now, Registers of all sorts use pointer-based representation. It's error-prone, because compilers perform implicit conversions between pointers and integral values. Also, it constraints `MacroAssembler` API where it may introduce ambiguity between overloads.
> 
> Proposed change hides pointer representation behind value class.
> 
> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> Code quality doesn't suffer (and even slightly improves):
>   https://godbolt.org/z/d8dGM1eY1
> 
> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
> 
> Testing: hs-tier1 - hs-tier5
> 
> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

This pull request has now been integrated.

Changeset: 755ecf6b
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/755ecf6b7384e67ccb51c4498f94336631db690d
Stats:     575 lines in 28 files changed: 152 ins; 103 del; 320 mod

8292153: x86: Represent Registers as values

Reviewed-by: kvn, aph

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

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

From vlivanov at openjdk.org  Thu Aug 11 21:24:37 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 11 Aug 2022 21:24:37 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v2]
In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
Message-ID: <BmwcCHejXH9MB6zD0w_Caz6ed1mLE1s66PTp2HBWADM=.2c0fcafa-2a47-4f12-81e1-f9cf53c942f8@github.com>

> (It's a PR dependent on #9815.)
> 
> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
> 
> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
> 
> Proposed change hides pointer representation behind value class.
> 
> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> Code quality improves:
>   GCC:   https://godbolt.org/z/r6G36facj
>   Clang: https://godbolt.org/z/x5oPdYEPM
> 
> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
> 
> Testing: hs-tier1 - hs-tier5
> 
> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into rwrapper.aarch64
 - 8292203: AArch64: Represent Registers as values
 - cleanups
 - x86: Register class wrappers

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

Changes: https://git.openjdk.org/jdk/pull/9826/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=01
  Stats: 527 lines in 15 files changed: 121 ins; 53 del; 353 mod
  Patch: https://git.openjdk.org/jdk/pull/9826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9826/head:pull/9826

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

From iklam at openjdk.org  Fri Aug 12 03:15:02 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Aug 2022 03:15:02 GMT
Subject: RFR: 8292267: Clean up synchronizer.hpp
Message-ID: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>

Fix two problems with synchronizer.hpp:

- It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration!
- synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp.

These headers are included much less after this PR (out of ~1000 hotspot .o files)


linkedlist.hpp    857 -> 101
synchronizer.hpp  848 -> 122
resourceHash.hpp  850 -> 270

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

Commit messages:
 - added back inlined functions in case their performance matters
 - fixed copyright
 - 8292267: Clean up synchronizer.hpp

Changes: https://git.openjdk.org/jdk/pull/9849/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292267
  Stats: 54 lines in 21 files changed: 27 ins; 20 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9849.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9849/head:pull/9849

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

From coleenp at openjdk.org  Fri Aug 12 13:24:18 2022
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 Aug 2022 13:24:18 GMT
Subject: RFR: 8292267: Clean up synchronizer.hpp
In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
Message-ID: <39nneFOUe-wR-G9IjpEaDdLOI8ihO04p1Vv6deQDInc=.e00c9cf9-9bd5-4691-bb0a-2e6a1421c8a0@github.com>

On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration!
> - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp.
> 
> These headers are included much less after this PR (out of ~1000 hotspot .o files)
> 
> 
> linkedlist.hpp    857 -> 101
> synchronizer.hpp  848 -> 122
> resourceHash.hpp  850 -> 270

Very nice.

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

Marked as reviewed by coleenp (Reviewer).

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

From dcubed at openjdk.org  Fri Aug 12 15:30:18 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 Aug 2022 15:30:18 GMT
Subject: RFR: 8292267: Clean up synchronizer.hpp
In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
Message-ID: <fwawhxye_3D7mpQ2NgUB7bZ8b0gjW05f2DJDj86740Y=.a7dee5df-eef3-447b-8649-0fa42e752c40@github.com>

On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration!
> - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp.
> 
> These headers are included much less after this PR (out of ~1000 hotspot .o files)
> 
> 
> linkedlist.hpp    857 -> 101
> synchronizer.hpp  848 -> 122
> resourceHash.hpp  850 -> 270

Looks great. I only posted a few nit comments.

src/hotspot/share/gc/shenandoah/shenandoahPadding.hpp line 28:

> 26: #define SHARE_GC_SHENANDOAH_SHENANDOAHPADDING_HPP
> 27: 
> 28: #include "memory/padded.hpp"

This one surprised me, but I'm guessing it was included indirectly
from synchronizer.hpp via some frame header...

src/hotspot/share/prims/jvmtiExport.hpp line 50:

> 48: class JvmtiEnv;
> 49: class JvmtiThreadState;
> 50: class ThreadsList;

Not in sorted order relative to OopStorage. Does it need to be?

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

Marked as reviewed by dcubed (Reviewer).

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

From dholmes at openjdk.org  Fri Aug 12 21:11:13 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Aug 2022 21:11:13 GMT
Subject: RFR: 8292267: Clean up synchronizer.hpp
In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
Message-ID: <HxVtyVfQxeJJ5dG3jxyj0r1KfyBikvWgG7FhLS4tvM0=.53c5204b-dae8-48ae-8e3f-85e46129d944@github.com>

On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration!
> - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp.
> 
> These headers are included much less after this PR (out of ~1000 hotspot .o files)
> 
> 
> linkedlist.hpp    857 -> 101
> synchronizer.hpp  848 -> 122
> resourceHash.hpp  850 -> 270

Looks fine.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

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

From iklam at openjdk.org  Fri Aug 12 21:45:23 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 12 Aug 2022 21:45:23 GMT
Subject: RFR: 8292267: Clean up synchronizer.hpp [v2]
In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
Message-ID: <b2VVq8OvUN5lewXtuj7RgqdZ9Qa_GnDKJ-Kt5th1x-s=.e192ec43-4c32-41bb-8bc0-6cc4d4f51ed2@github.com>

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration!
> - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp.
> 
> These headers are included much less after this PR (out of ~1000 hotspot .o files)
> 
> 
> linkedlist.hpp    857 -> 101
> synchronizer.hpp  848 -> 122
> resourceHash.hpp  850 -> 270

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @dcubed-ojdk review comments - reorder class forward declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9849/files
  - new: https://git.openjdk.org/jdk/pull/9849/files/9b372650..f2dfac39

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

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

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

From kdnilsen at openjdk.org  Fri Aug 12 23:51:15 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 12 Aug 2022 23:51:15 GMT
Subject: RFR: Fix budgeting assertion [v2]
In-Reply-To: <6dCRCgYA0WvyRisYpxZRqCZz_cCTRGUixQq6tPpQvFY=.96bd49f5-5338-4cc3-b60d-3cd7309ee39e@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
 <4CCIpVv9QkBcRsZnX9CSwDtLpuon5_GcLTSyfgwUbq8=.265ee314-34b2-4a24-ad34-15562ef9620c@github.com>
 <8G5uicuX2foAy6gRO6M9jWJvNrq0UtXR9WsZXDfpoAM=.719f4043-280f-4b3d-a143-916cecc5c587@github.com>
 <6dCRCgYA0WvyRisYpxZRqCZz_cCTRGUixQq6tPpQvFY=.96bd49f5-5338-4cc3-b60d-3cd7309ee39e@github.com>
Message-ID: <RbSOtNYwqdIMKWS814oRnF1AbL_-JAcW0u0SVNoYSwA=.4cbe74d7-c70f-422f-b011-4e1f88525335@github.com>

On Wed, 10 Aug 2022 17:14:59 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 136:
>> 
>>> 134:           // reclaim highly utilized young-gen regions just for the sake of finding min_garbage to reclaim
>>> 135:           // within youn-gen memory
>>> 136:           cur_young_garbage += r->get_live_data_bytes();
>> 
>> Isn't `r->garbage() + r->get_live_data_bytes()` equal to `r->used()`?
>> 
>> I am not sure I understand the reasoning here. I would much rather we named the `cur_young_garbage` variable more correctly if it is counting the amount of young regions that are in some sense being "removed from the young generation" (if indeed that's how to interpret it).
>
> Might be a good idea to describe at line 97, what `cur_young_garbage` will track as you process regions and build the collection set. Similarly, young_curset etc.
> 
> I see three separate outer if/else statements covering respectively the cases of generational/global, generational/not global, and non-generational cases. Would it read more easily and make for more easily maintained code to refactor into 3 separate cset builders called for each of the three cases, if necessary from the top level method (but even better if called from different contexts to specialize early hoisting the check on the type of collection up into the highest caller that has the information, rather than having all of them in one single, somewhat long and somewhat unwieldy method?

Thanks for these suggestions.  Adding a comment and "folding" those two addition operations into one.

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

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

From kdnilsen at openjdk.org  Fri Aug 12 23:51:16 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Fri, 12 Aug 2022 23:51:16 GMT
Subject: RFR: Fix budgeting assertion [v2]
In-Reply-To: <RbSOtNYwqdIMKWS814oRnF1AbL_-JAcW0u0SVNoYSwA=.4cbe74d7-c70f-422f-b011-4e1f88525335@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
 <4CCIpVv9QkBcRsZnX9CSwDtLpuon5_GcLTSyfgwUbq8=.265ee314-34b2-4a24-ad34-15562ef9620c@github.com>
 <8G5uicuX2foAy6gRO6M9jWJvNrq0UtXR9WsZXDfpoAM=.719f4043-280f-4b3d-a143-916cecc5c587@github.com>
 <6dCRCgYA0WvyRisYpxZRqCZz_cCTRGUixQq6tPpQvFY=.96bd49f5-5338-4cc3-b60d-3cd7309ee39e@github.com>
 <RbSOtNYwqdIMKWS814oRnF1AbL_-JAcW0u0SVNoYSwA=.4cbe74d7-c70f-422f-b011-4e1f88525335@github.com>
Message-ID: <bUg2_a3fNlceI4z4TvezlxyGVCxxY97SXBMH5PXwOrw=.1a1cc201-d8ec-4b89-b54a-dbdb4b6d9feb@github.com>

On Fri, 12 Aug 2022 23:46:29 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Might be a good idea to describe at line 97, what `cur_young_garbage` will track as you process regions and build the collection set. Similarly, young_curset etc.
>> 
>> I see three separate outer if/else statements covering respectively the cases of generational/global, generational/not global, and non-generational cases. Would it read more easily and make for more easily maintained code to refactor into 3 separate cset builders called for each of the three cases, if necessary from the top level method (but even better if called from different contexts to specialize early hoisting the check on the type of collection up into the highest caller that has the information, rather than having all of them in one single, somewhat long and somewhat unwieldy method?
>
> Thanks for these suggestions.  Adding a comment and "folding" those two addition operations into one.

Not refactoring the body of method for now, but that can be done at a future time.

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

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

From kdnilsen at openjdk.org  Sat Aug 13 00:18:06 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 13 Aug 2022 00:18:06 GMT
Subject: RFR: Fix budgeting assertion [v3]
In-Reply-To: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
Message-ID: <cXBZMz7Wv-umXAQDY0YlVz-HiXRzm6vlXiFkeXXOY_Y=.0682a1c7-81d2-4699-9623-d7f48db68b3a@github.com>

> An assertion failure revealed problems with evacuation budgeting computations.  Three changes are reflected in this pull request:
> 
> 1. Memory set aside for the promotion reserve was not excluded from the allocation supplement
> 2. When the old evacuation reserve is larger than the memory consumed by old evacuation collection set, we loan the excess memory to allocation supplement to make sure this memory is not consumed by promotions.  The number of regions set aside from this reserve for the allocation supplement must be rounded down from the total excess memory.  (Before this patch, it was rounded up.)
> 3. The assertion test that was failing needed a <= comparison instead of a < comparison.

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

  Minor change and comments for reviewer

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

Changes:
  - all: https://git.openjdk.org/shenandoah/pull/156/files
  - new: https://git.openjdk.org/shenandoah/pull/156/files/7d256dba..00504682

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

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

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

From kdnilsen at openjdk.org  Sat Aug 13 00:18:09 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 13 Aug 2022 00:18:09 GMT
Subject: RFR: Fix budgeting assertion [v2]
In-Reply-To: <8G5uicuX2foAy6gRO6M9jWJvNrq0UtXR9WsZXDfpoAM=.719f4043-280f-4b3d-a143-916cecc5c587@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
 <4CCIpVv9QkBcRsZnX9CSwDtLpuon5_GcLTSyfgwUbq8=.265ee314-34b2-4a24-ad34-15562ef9620c@github.com>
 <8G5uicuX2foAy6gRO6M9jWJvNrq0UtXR9WsZXDfpoAM=.719f4043-280f-4b3d-a143-916cecc5c587@github.com>
Message-ID: <wVJqdAirHLmjm9AIyrjvKAQtOP3RPpJ4L2Zpg0pKwWk=.33e68cb7-f06e-416b-acfb-5e307a2fdddd@github.com>

On Wed, 10 Aug 2022 16:52:33 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Remove instrumentation
>>  - Fix choose_collection_set to use region->index after quicksort
>>    
>>    After region data is sorted in garbage order, index within the region
>>    data array no longer matches the region->index().  Use the
>>    region->index() to test whether the region was pre-selected rather than
>>    using the index within the region data array.  Very confusing that this
>>    code ever worked.  Perhaps this bug was introduced by some sort of merge
>>    conflict.
>>  - Assure that aged young regions are not promoted if not pre-selected
>>    
>>    In the case that an aged young region is not pre-selected, it should not
>>    be included in the collection set because there is not enough room in
>>    old-gen to hold its promoted contents.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 126:
> 
>> 124:             old_cur_cset = new_cset;
>> 125:           }
>> 126:         } else if (cset->is_preselected(r->index())) {
> 
> It might be a good idea for all the `choose_collection_set*` methods that use `is_preselected` to assert that cset's `_preselected_regions` isn't null, perhaps via an `is_preselected_established` (or appropriately named assert_only method that asserts that `_preselected_regions != NULL`

Thanks.  This is a good idea.  Let's put this into a future pr...

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

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

From kdnilsen at openjdk.org  Sat Aug 13 00:19:32 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 13 Aug 2022 00:19:32 GMT
Subject: Integrated: Fix budgeting assertion
In-Reply-To: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
References: <wsEDN2Skcj3BMLIKqxMc6tv12BfFKk1ng_GirqzOaZE=.a78be262-4176-4828-8f03-06d8dbf37965@github.com>
Message-ID: <jpB7rStMMtupxjo_0ukcDhcKluDMeUDLrOLQinYxXTA=.c600f8d4-d021-4e53-8d31-fd33df3f72a5@github.com>

On Fri, 5 Aug 2022 20:54:35 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> An assertion failure revealed problems with evacuation budgeting computations.  Three changes are reflected in this pull request:
> 
> 1. Memory set aside for the promotion reserve was not excluded from the allocation supplement
> 2. When the old evacuation reserve is larger than the memory consumed by old evacuation collection set, we loan the excess memory to allocation supplement to make sure this memory is not consumed by promotions.  The number of regions set aside from this reserve for the allocation supplement must be rounded down from the total excess memory.  (Before this patch, it was rounded up.)
> 3. The assertion test that was failing needed a <= comparison instead of a < comparison.

This pull request has now been integrated.

Changeset: b4ff060b
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/b4ff060bf879a56141bd7c46713675ae2f2b466f
Stats:     71 lines in 3 files changed: 47 ins; 1 del; 23 mod

Fix budgeting assertion

Reviewed-by: wkemper

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

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

From andrew at openjdk.org  Mon Aug 15 01:51:45 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 15 Aug 2022 01:51:45 GMT
Subject: RFR: Merge jdk8u:master
Message-ID: <BhPDXnsx_8g7BzEp9L6nG75JRk0cgxlJFqbYetkoRcc=.7fe1a870-1c75-4127-b94a-2f9be348a083@github.com>

Merge jdk8u332-b01

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

Commit messages:
 - Merge jdk8u332-b01
 - Added tag jdk8u332-b00 for changeset 13db406330a1
 - Merge
 - Added tag jdk8u322-ga for changeset f75aee4df47a
 - 8270290: NTLM authentication fails if HEAD request is used
 - 8279077: JFR crashes on Linux ppc due to missing crash protector in signal handler
 - 8167014: jdeps: Missing message: warn.skipped.entry
 - 8266749: AArch64: Backtracing broken on PAC enabled systems
 - 8241768: git needs .gitattributes
 - 8202822: Add .git to .hgignore
 - ... and 14 more: https://git.openjdk.org/shenandoah-jdk8u/compare/6305c6ff...1c83efdc

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

Changes: https://git.openjdk.org/shenandoah-jdk8u/pull/5/files
  Stats: 37558 lines in 1281 files changed: 12218 ins; 20667 del; 4673 mod
  Patch: https://git.openjdk.org/shenandoah-jdk8u/pull/5.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-jdk8u pull/5/head:pull/5

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

From andrew at openjdk.org  Mon Aug 15 07:30:44 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 15 Aug 2022 07:30:44 GMT
Subject: RFR: Merge jdk8u:master
In-Reply-To: <BhPDXnsx_8g7BzEp9L6nG75JRk0cgxlJFqbYetkoRcc=.7fe1a870-1c75-4127-b94a-2f9be348a083@github.com>
References: <BhPDXnsx_8g7BzEp9L6nG75JRk0cgxlJFqbYetkoRcc=.7fe1a870-1c75-4127-b94a-2f9be348a083@github.com>
Message-ID: <mp_fQk7NhjWTqgZ1sRsVAwc_87VLA2KD1Sr0WaBtte8=.8ba10004-b62c-4d6f-843c-3a46060d10ee@github.com>

On Mon, 15 Aug 2022 01:42:59 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u332-b01

Linux build failure is known and will be resolved by a follow-up backport of 8260632: "Build failures after JDK-8253353"
Looks like the same build failure applies to the Windows build too (when it works)
Mac OS is known to be broken for now

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

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

From andrew at openjdk.org  Mon Aug 15 07:33:44 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 15 Aug 2022 07:33:44 GMT
Subject: Integrated: Merge jdk8u:master
In-Reply-To: <BhPDXnsx_8g7BzEp9L6nG75JRk0cgxlJFqbYetkoRcc=.7fe1a870-1c75-4127-b94a-2f9be348a083@github.com>
References: <BhPDXnsx_8g7BzEp9L6nG75JRk0cgxlJFqbYetkoRcc=.7fe1a870-1c75-4127-b94a-2f9be348a083@github.com>
Message-ID: <v0BTSCIGSPn1xof6g77XAAipMEJ-TS_eVNt8tEPmNBg=.228d4c42-78d7-455d-965a-4b7dcf59bd16@github.com>

On Mon, 15 Aug 2022 01:42:59 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Merge jdk8u332-b01

This pull request has now been integrated.

Changeset: eea51955
Author:    Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/shenandoah-jdk8u/commit/eea5195503d616470cf99aa288d2e8d62d7f9b5d
Stats:     37558 lines in 1281 files changed: 12218 ins; 20667 del; 4673 mod

Merge jdk8u:master

Merge jdk8u332-b01

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

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

From andrew at openjdk.org  Mon Aug 15 07:59:23 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 15 Aug 2022 07:59:23 GMT
Subject: RFR: 8260632: Build failures after JDK-8253353
Message-ID: <ligtGPXtkoK9P-Y0VJseVe9mFwmA53NEnDmpOkYRUVA=.3db3cc6d-df7c-4e4c-abcb-f8d5523a0a6f@github.com>

Necessary backport to fix the build now JDK-8253353 has been backported to 8u in 8u332-b01

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

Commit messages:
 - Backport f1522fb288f292edf80bbc87436dc932bd7d2d9d

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

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

From shade at openjdk.org  Mon Aug 15 08:41:39 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 15 Aug 2022 08:41:39 GMT
Subject: RFR: 8260632: Build failures after JDK-8253353
In-Reply-To: <ligtGPXtkoK9P-Y0VJseVe9mFwmA53NEnDmpOkYRUVA=.3db3cc6d-df7c-4e4c-abcb-f8d5523a0a6f@github.com>
References: <ligtGPXtkoK9P-Y0VJseVe9mFwmA53NEnDmpOkYRUVA=.3db3cc6d-df7c-4e4c-abcb-f8d5523a0a6f@github.com>
Message-ID: <idMlSUqk9yVT8a_gIQG5IDGi2uUKCTxFiXVd0FqCV90=.d70e23bb-9856-470e-96ab-a1bdb0ded02a@github.com>

On Mon, 15 Aug 2022 07:52:15 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Necessary backport to fix the build now JDK-8253353 has been backported to 8u in 8u332-b01

Marked as reviewed by shade (Committer).

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

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

From duke at openjdk.org  Mon Aug 15 10:28:19 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Mon, 15 Aug 2022 10:28:19 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v2]
In-Reply-To: <BmwcCHejXH9MB6zD0w_Caz6ed1mLE1s66PTp2HBWADM=.2c0fcafa-2a47-4f12-81e1-f9cf53c942f8@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
 <BmwcCHejXH9MB6zD0w_Caz6ed1mLE1s66PTp2HBWADM=.2c0fcafa-2a47-4f12-81e1-f9cf53c942f8@github.com>
Message-ID: <Ugj3u1GrMJ0i6D4845IZouHZSpKAxXMyPO7sBkuIjQc=.381dafa7-5c42-4f83-8d59-a2327407ebcf@github.com>

On Thu, 11 Aug 2022 21:24:37 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> (It's a PR dependent on #9815.)
>> 
>> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
>> 
>> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
>> 
>> Proposed change hides pointer representation behind value class.
>> 
>> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
>> 
>> Code quality improves:
>>   GCC:   https://godbolt.org/z/r6G36facj
>>   Clang: https://godbolt.org/z/x5oPdYEPM
>> 
>> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
>> 
>> Testing: hs-tier1 - hs-tier5
>> 
>> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into rwrapper.aarch64
>  - 8292203: AArch64: Represent Registers as values
>  - cleanups
>  - x86: Register class wrappers

src/hotspot/cpu/aarch64/register_aarch64.hpp line 39:

> 37:   int _encoding;
> 38: 
> 39:   constexpr Register(int encoding, bool unused) : _encoding(encoding) {}

Why do we need unused here? If the intention is to prevent implicit conversion from `int` to `Register` then you can mark the constructor as `explicit`. Thanks.

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

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

From duke at openjdk.org  Mon Aug 15 10:39:16 2022
From: duke at openjdk.org (Quan Anh Mai)
Date: Mon, 15 Aug 2022 10:39:16 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v2]
In-Reply-To: <BmwcCHejXH9MB6zD0w_Caz6ed1mLE1s66PTp2HBWADM=.2c0fcafa-2a47-4f12-81e1-f9cf53c942f8@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
 <BmwcCHejXH9MB6zD0w_Caz6ed1mLE1s66PTp2HBWADM=.2c0fcafa-2a47-4f12-81e1-f9cf53c942f8@github.com>
Message-ID: <UCKcZ6lfirVf2S9LCBoXacgcQDqMC3JXllCxYWd-T1U=.b35d3bf6-c6d4-482f-b32d-c16f544d687e@github.com>

On Thu, 11 Aug 2022 21:24:37 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> (It's a PR dependent on #9815.)
>> 
>> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
>> 
>> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
>> 
>> Proposed change hides pointer representation behind value class.
>> 
>> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
>> 
>> Code quality improves:
>>   GCC:   https://godbolt.org/z/r6G36facj
>>   Clang: https://godbolt.org/z/x5oPdYEPM
>> 
>> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
>> 
>> Testing: hs-tier1 - hs-tier5
>> 
>> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into rwrapper.aarch64
>  - 8292203: AArch64: Represent Registers as values
>  - cleanups
>  - x86: Register class wrappers

> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).

I don't really understand this part. Can we overload the `->` operator instead? I believe this works:

    Register* operator->() {
        return this;
    }

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

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

From aph at openjdk.org  Mon Aug 15 10:44:25 2022
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 15 Aug 2022 10:44:25 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v2]
In-Reply-To: <UCKcZ6lfirVf2S9LCBoXacgcQDqMC3JXllCxYWd-T1U=.b35d3bf6-c6d4-482f-b32d-c16f544d687e@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
 <BmwcCHejXH9MB6zD0w_Caz6ed1mLE1s66PTp2HBWADM=.2c0fcafa-2a47-4f12-81e1-f9cf53c942f8@github.com>
 <UCKcZ6lfirVf2S9LCBoXacgcQDqMC3JXllCxYWd-T1U=.b35d3bf6-c6d4-482f-b32d-c16f544d687e@github.com>
Message-ID: <MG7k30AhRR_fK9UOXQxGlifRd5wUn0yJon4lkyJ-F9Y=.ae4f5695-c209-4a41-95aa-8434a0e53ee0@github.com>

On Mon, 15 Aug 2022 10:37:00 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

> > Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> I don't really understand this part. Can we overload the `->` operator instead? I believe this works:
> 
> ```
> Register* operator->() {
>     return this;
> }

I tried something like that before, and got poor code quality.

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

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

From andrew at openjdk.org  Tue Aug 16 16:31:00 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 16 Aug 2022 16:31:00 GMT
Subject: RFR: 8260632: Build failures after JDK-8253353
In-Reply-To: <ligtGPXtkoK9P-Y0VJseVe9mFwmA53NEnDmpOkYRUVA=.3db3cc6d-df7c-4e4c-abcb-f8d5523a0a6f@github.com>
References: <ligtGPXtkoK9P-Y0VJseVe9mFwmA53NEnDmpOkYRUVA=.3db3cc6d-df7c-4e4c-abcb-f8d5523a0a6f@github.com>
Message-ID: <zMHMfmqC1zOtOV9Dc5gaeLXEcfm5V_-VL_zIlOT6Gmo=.5bb52e6e-5e61-464c-9a1f-73c2b1cdbfb8@github.com>

On Mon, 15 Aug 2022 07:52:15 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Necessary backport to fix the build now JDK-8253353 has been backported to 8u in 8u332-b01

Thanks Aleksey.

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

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

From andrew at openjdk.org  Tue Aug 16 16:31:02 2022
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 16 Aug 2022 16:31:02 GMT
Subject: Integrated: 8260632: Build failures after JDK-8253353
In-Reply-To: <ligtGPXtkoK9P-Y0VJseVe9mFwmA53NEnDmpOkYRUVA=.3db3cc6d-df7c-4e4c-abcb-f8d5523a0a6f@github.com>
References: <ligtGPXtkoK9P-Y0VJseVe9mFwmA53NEnDmpOkYRUVA=.3db3cc6d-df7c-4e4c-abcb-f8d5523a0a6f@github.com>
Message-ID: <vTxmrttuB_DgTt6yTmROoa2E2QtaxHUFH1kIeeaZCbU=.33860af0-dd03-42c5-93d4-e8d8c6b5eb6b@github.com>

On Mon, 15 Aug 2022 07:52:15 GMT, Andrew John Hughes <andrew at openjdk.org> wrote:

> Necessary backport to fix the build now JDK-8253353 has been backported to 8u in 8u332-b01

This pull request has now been integrated.

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

8260632: Build failures after JDK-8253353

Reviewed-by: shade
Backport-of: f1522fb288f292edf80bbc87436dc932bd7d2d9d

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

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

From vlivanov at openjdk.org  Wed Aug 17 18:18:36 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 17 Aug 2022 18:18:36 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v3]
In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
Message-ID: <xC0dld6d1S2UW-Dh1pbDIcGH_Fwk7oCeUi0lb9KwZHI=.469b895d-a315-4a4b-bf3e-415a7e5d0d26@github.com>

> (It's a PR dependent on #9815.)
> 
> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
> 
> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
> 
> Proposed change hides pointer representation behind value class.
> 
> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> Code quality improves:
>   GCC:   https://godbolt.org/z/r6G36facj
>   Clang: https://godbolt.org/z/x5oPdYEPM
> 
> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
> 
> Testing: hs-tier1 - hs-tier5
> 
> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  explicit constructors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9826/files
  - new: https://git.openjdk.org/jdk/pull/9826/files/a139bc03..d0ae344d

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

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

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

From vlivanov at openjdk.org  Wed Aug 17 18:29:20 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 17 Aug 2022 18:29:20 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v2]
In-Reply-To: <Ugj3u1GrMJ0i6D4845IZouHZSpKAxXMyPO7sBkuIjQc=.381dafa7-5c42-4f83-8d59-a2327407ebcf@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
 <BmwcCHejXH9MB6zD0w_Caz6ed1mLE1s66PTp2HBWADM=.2c0fcafa-2a47-4f12-81e1-f9cf53c942f8@github.com>
 <Ugj3u1GrMJ0i6D4845IZouHZSpKAxXMyPO7sBkuIjQc=.381dafa7-5c42-4f83-8d59-a2327407ebcf@github.com>
Message-ID: <T1_kW59lCUe70ePgUPG54R6QStJ0CwdDbcKZAvm-P8U=.bc1e4fd6-7afd-4ae1-94f6-83677e6f8abd@github.com>

On Mon, 15 Aug 2022 10:26:07 GMT, Quan Anh Mai <duke at openjdk.org> wrote:

>> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
>> 
>>  - Merge branch 'master' into rwrapper.aarch64
>>  - 8292203: AArch64: Represent Registers as values
>>  - cleanups
>>  - x86: Register class wrappers
>
> src/hotspot/cpu/aarch64/register_aarch64.hpp line 39:
> 
>> 37:   int _encoding;
>> 38: 
>> 39:   constexpr Register(int encoding, bool unused) : _encoding(encoding) {}
> 
> Why do we need unused here? If the intention is to prevent implicit conversion from `int` to `Register` then you can mark the constructor as `explicit`. Thanks.

Good point. Fixed.

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

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

From vlivanov at openjdk.org  Wed Aug 17 18:33:54 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 17 Aug 2022 18:33:54 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v4]
In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
Message-ID: <hgF-NhIjphMoX_A9Wjchw1R6325uV3itJ-Xz4IqhklQ=.8e345cfa-9bea-4f4d-b3cf-e4be7aeba74a@github.com>

> (It's a PR dependent on #9815.)
> 
> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
> 
> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
> 
> Proposed change hides pointer representation behind value class.
> 
> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> Code quality improves:
>   GCC:   https://godbolt.org/z/r6G36facj
>   Clang: https://godbolt.org/z/x5oPdYEPM
> 
> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
> 
> Testing: hs-tier1 - hs-tier5
> 
> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

Vladimir Ivanov 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 rwrapper.aarch64
 - explicit constructors
 - Merge branch 'master' into rwrapper.aarch64
 - 8292203: AArch64: Represent Registers as values
 - cleanups
 - x86: Register class wrappers

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

Changes: https://git.openjdk.org/jdk/pull/9826/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=03
  Stats: 527 lines in 15 files changed: 121 ins; 53 del; 353 mod
  Patch: https://git.openjdk.org/jdk/pull/9826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9826/head:pull/9826

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

From iklam at openjdk.org  Fri Aug 19 06:32:26 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 19 Aug 2022 06:32:26 GMT
Subject: RFR: 8292267: Clean up synchronizer.hpp [v3]
In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
Message-ID: <x7mTTS-BTVf_mTOk0VswaYclodr3dBpLG4ebIrkEhpY=.4c408a16-7126-4705-8d68-ce22191e4a25@github.com>

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration!
> - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp.
> 
> These headers are included much less after this PR (out of ~1000 hotspot .o files)
> 
> 
> linkedlist.hpp    857 -> 101
> synchronizer.hpp  848 -> 122
> resourceHash.hpp  850 -> 270

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

 - Merge branch 'master' into 8292267-clean-up-synchronizer-hpp
 - @dcubed-ojdk review comments - reorder class forward declarations
 - added back inlined functions in case their performance matters
 - fixed copyright
 - 8292267: Clean up synchronizer.hpp

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

Changes: https://git.openjdk.org/jdk/pull/9849/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9849&range=02
  Stats: 54 lines in 21 files changed: 28 ins; 21 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9849.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9849/head:pull/9849

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

From iklam at openjdk.org  Fri Aug 19 17:25:41 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 19 Aug 2022 17:25:41 GMT
Subject: RFR: 8292267: Clean up synchronizer.hpp [v3]
In-Reply-To: <39nneFOUe-wR-G9IjpEaDdLOI8ihO04p1Vv6deQDInc=.e00c9cf9-9bd5-4691-bb0a-2e6a1421c8a0@github.com>
References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
 <39nneFOUe-wR-G9IjpEaDdLOI8ihO04p1Vv6deQDInc=.e00c9cf9-9bd5-4691-bb0a-2e6a1421c8a0@github.com>
Message-ID: <JDYSCwmtQCai9-f-_vQZWQlgIGFuBe4BcvHHOVgkcB0=.3088d4cb-3b59-43f5-b836-fe7a4015a0c6@github.com>

On Fri, 12 Aug 2022 13:20:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into 8292267-clean-up-synchronizer-hpp
>>  - @dcubed-ojdk review comments - reorder class forward declarations
>>  - added back inlined functions in case their performance matters
>>  - fixed copyright
>>  - 8292267: Clean up synchronizer.hpp
>
> Very nice.

Thanks @coleenp @dholmes-ora @dcubed-ojdk for the review.
Tiers 1,2 and build-tier5 passed on top of #9927

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

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

From iklam at openjdk.org  Fri Aug 19 17:29:38 2022
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 19 Aug 2022 17:29:38 GMT
Subject: Integrated: 8292267: Clean up synchronizer.hpp
In-Reply-To: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
References: <16JoAqcTJt3BRqfmZC9v5tSkYzpT7nY3wBA74g3J9hQ=.76a0f1f5-6bb9-401d-b061-66ced37960e3@github.com>
Message-ID: <L2AqTj2Z5jlFM1J8XGA3tODvss9GwQ5wxe4HoYI7qtU=.e2aeb3cc-c0de-4f69-9073-f54e3e937db3@github.com>

On Fri, 12 Aug 2022 00:42:52 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> Fix two problems with synchronizer.hpp:
> 
> - It's unnecessarily included in two popular headers: monitorChunk.hpp and frame_<cpu\>.hpp. The latter is most problematic because it includes synchronizer.hpp in the middle of a class declaration!
> - synchronizer.hpp includes linkedlist.hpp. This can be avoid by moving the definition of Synchronizer::PtrList into synchronizer.cpp.
> 
> These headers are included much less after this PR (out of ~1000 hotspot .o files)
> 
> 
> linkedlist.hpp    857 -> 101
> synchronizer.hpp  848 -> 122
> resourceHash.hpp  850 -> 270

This pull request has now been integrated.

Changeset: 7244dd6f
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7244dd6fab0c516ed76af594593b8378512620c8
Stats:     54 lines in 21 files changed: 28 ins; 21 del; 5 mod

8292267: Clean up synchronizer.hpp

Reviewed-by: coleenp, dcubed, dholmes

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

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

From duke at openjdk.org  Tue Aug 23 15:14:54 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 23 Aug 2022 15:14:54 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
Message-ID: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>

Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode.

1. Always enable barrier for Shenandoah IU mode (this change is same as https://github.com/openjdk/jdk/pull/9494), but is not sufficient to prevent the assertion failure.
2. Run barriers for oops in stack chunk header. The code in `stackChunkOopDesc::do_barriers` is missing barriers on the oops present in the stack chunk header.

Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Commit messages:
 - 8288129: Shenandoah: Skynet test crashed with iu + aggressive

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

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

From vlivanov at openjdk.org  Wed Aug 24 03:48:17 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 24 Aug 2022 03:48:17 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v5]
In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
Message-ID: <RSffsow0RdpL5gsf-I7E7pHnIPaYd076zh-muPmeSZ8=.49f51fc9-cb1e-43e9-bdb3-b7006800509f@github.com>

> (It's a PR dependent on #9815.)
> 
> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
> 
> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
> 
> Proposed change hides pointer representation behind value class.
> 
> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> Code quality improves:
>   GCC:   https://godbolt.org/z/r6G36facj
>   Clang: https://godbolt.org/z/x5oPdYEPM
> 
> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
> 
> Testing: hs-tier1 - hs-tier5
> 
> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into rwrapper.aarch64
 - Merge branch 'master' into rwrapper.aarch64
 - explicit constructors
 - Merge branch 'master' into rwrapper.aarch64
 - 8292203: AArch64: Represent Registers as values
 - cleanups
 - x86: Register class wrappers

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

Changes: https://git.openjdk.org/jdk/pull/9826/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9826&range=04
  Stats: 527 lines in 15 files changed: 121 ins; 53 del; 353 mod
  Patch: https://git.openjdk.org/jdk/pull/9826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9826/head:pull/9826

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

From vlivanov at openjdk.org  Wed Aug 24 23:33:32 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 24 Aug 2022 23:33:32 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v5]
In-Reply-To: <RSffsow0RdpL5gsf-I7E7pHnIPaYd076zh-muPmeSZ8=.49f51fc9-cb1e-43e9-bdb3-b7006800509f@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
 <RSffsow0RdpL5gsf-I7E7pHnIPaYd076zh-muPmeSZ8=.49f51fc9-cb1e-43e9-bdb3-b7006800509f@github.com>
Message-ID: <oiP1O9T4WZ-ZcyT3FFenE-YOOo4N-lCxZm3TkGDReI4=.8cca8422-727d-4634-a173-72541eb7c7fa@github.com>

On Wed, 24 Aug 2022 03:48:17 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> (It's a PR dependent on #9815.)
>> 
>> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
>> 
>> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
>> 
>> Proposed change hides pointer representation behind value class.
>> 
>> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
>> 
>> Code quality improves:
>>   GCC:   https://godbolt.org/z/r6G36facj
>>   Clang: https://godbolt.org/z/x5oPdYEPM
>> 
>> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
>> 
>> Testing: hs-tier1 - hs-tier5
>> 
>> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into rwrapper.aarch64
>  - Merge branch 'master' into rwrapper.aarch64
>  - explicit constructors
>  - Merge branch 'master' into rwrapper.aarch64
>  - 8292203: AArch64: Represent Registers as values
>  - cleanups
>  - x86: Register class wrappers

Thanks for the review, Vladimir.

Anybody else planning to review? Otherwise, I'll push it tomorrow.

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

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

From aph at openjdk.org  Thu Aug 25 09:14:46 2022
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 25 Aug 2022 09:14:46 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v5]
In-Reply-To: <RSffsow0RdpL5gsf-I7E7pHnIPaYd076zh-muPmeSZ8=.49f51fc9-cb1e-43e9-bdb3-b7006800509f@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
 <RSffsow0RdpL5gsf-I7E7pHnIPaYd076zh-muPmeSZ8=.49f51fc9-cb1e-43e9-bdb3-b7006800509f@github.com>
Message-ID: <axXqXIqbjfeAxaBjwV2yR6YYQ4jw7NnaptTv1mNgzQc=.feac2154-7779-4461-820e-c84a7e7f042a@github.com>

On Wed, 24 Aug 2022 03:48:17 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> (It's a PR dependent on #9815.)
>> 
>> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
>> 
>> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
>> 
>> Proposed change hides pointer representation behind value class.
>> 
>> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
>> 
>> Code quality improves:
>>   GCC:   https://godbolt.org/z/r6G36facj
>>   Clang: https://godbolt.org/z/x5oPdYEPM
>> 
>> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
>> 
>> Testing: hs-tier1 - hs-tier5
>> 
>> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into rwrapper.aarch64
>  - Merge branch 'master' into rwrapper.aarch64
>  - explicit constructors
>  - Merge branch 'master' into rwrapper.aarch64
>  - 8292203: AArch64: Represent Registers as values
>  - cleanups
>  - x86: Register class wrappers

Marked as reviewed by aph (Reviewer).

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

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

From aboldtch at openjdk.org  Thu Aug 25 10:21:05 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 25 Aug 2022 10:21:05 GMT
Subject: RFR: 8292868: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop for aarch64
Message-ID: <FMyEOZdNQYrQhNeCeMfRlZvAosq3ntY1b9_4KS5_D4E=.0bb634bf-40bd-4021-af2a-c47099f64da0@github.com>

Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at.

This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api

Testing: Oracle aarch64 platforms tier 1-3

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

Commit messages:
 - Remove implicit tmp register aarch64 store_at

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

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

From shade at openjdk.org  Thu Aug 25 11:27:26 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 Aug 2022 11:27:26 GMT
Subject: RFR: 8292868: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop for aarch64
In-Reply-To: <FMyEOZdNQYrQhNeCeMfRlZvAosq3ntY1b9_4KS5_D4E=.0bb634bf-40bd-4021-af2a-c47099f64da0@github.com>
References: <FMyEOZdNQYrQhNeCeMfRlZvAosq3ntY1b9_4KS5_D4E=.0bb634bf-40bd-4021-af2a-c47099f64da0@github.com>
Message-ID: <XvHNYpHE__RukylUXR4pi-4RNfkPFDOmramP0yzMDJw=.bfa0d8f6-ce51-4d0b-8998-cd2d0eadff44@github.com>

On Thu, 25 Aug 2022 10:11:30 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at.
> 
> This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api
> 
> Testing: Oracle aarch64 platforms tier 1-3

Looks fine. I tested cross-builds on many platforms.

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

Marked as reviewed by shade (Reviewer).

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

From eosterlund at openjdk.org  Thu Aug 25 14:32:31 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 25 Aug 2022 14:32:31 GMT
Subject: RFR: 8292868: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop for aarch64
In-Reply-To: <FMyEOZdNQYrQhNeCeMfRlZvAosq3ntY1b9_4KS5_D4E=.0bb634bf-40bd-4021-af2a-c47099f64da0@github.com>
References: <FMyEOZdNQYrQhNeCeMfRlZvAosq3ntY1b9_4KS5_D4E=.0bb634bf-40bd-4021-af2a-c47099f64da0@github.com>
Message-ID: <L-WVN7_cqnRyUp7eNeu-VaqgMoXVKaI4Uj_U2wchkdU=.aea9970f-fb24-499b-91a4-40d6d765bec0@github.com>

On Thu, 25 Aug 2022 10:11:30 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at.
> 
> This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api
> 
> Testing: Oracle aarch64 platforms tier 1-3

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

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

From tschatzl at openjdk.org  Thu Aug 25 15:57:25 2022
From: tschatzl at openjdk.org (Thomas Schatzl)
Date: Thu, 25 Aug 2022 15:57:25 GMT
Subject: RFR: 8292868: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop for aarch64
In-Reply-To: <FMyEOZdNQYrQhNeCeMfRlZvAosq3ntY1b9_4KS5_D4E=.0bb634bf-40bd-4021-af2a-c47099f64da0@github.com>
References: <FMyEOZdNQYrQhNeCeMfRlZvAosq3ntY1b9_4KS5_D4E=.0bb634bf-40bd-4021-af2a-c47099f64da0@github.com>
Message-ID: <7KwQtFF-Cze8L37wp3QH6eedzGI-nEW0krpfqq91eoI=.f64a6651-0656-4392-ac6f-a5c85c8c755c@github.com>

On Thu, 25 Aug 2022 10:11:30 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at.
> 
> This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api
> 
> Testing: Oracle aarch64 platforms tier 1-3

Marked as reviewed by tschatzl (Reviewer).

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

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

From vlivanov at openjdk.org  Thu Aug 25 16:41:38 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 25 Aug 2022 16:41:38 GMT
Subject: RFR: 8292203: AArch64: Represent Registers as values [v5]
In-Reply-To: <RSffsow0RdpL5gsf-I7E7pHnIPaYd076zh-muPmeSZ8=.49f51fc9-cb1e-43e9-bdb3-b7006800509f@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
 <RSffsow0RdpL5gsf-I7E7pHnIPaYd076zh-muPmeSZ8=.49f51fc9-cb1e-43e9-bdb3-b7006800509f@github.com>
Message-ID: <PDDN5pPBXD-rRDJRs5rwqn7nn9zmyhazk7EijRhuPho=.8c0afed8-7d70-4aa4-b2e9-ac6eee34abfd@github.com>

On Wed, 24 Aug 2022 03:48:17 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> (It's a PR dependent on #9815.)
>> 
>> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
>> 
>> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
>> 
>> Proposed change hides pointer representation behind value class.
>> 
>> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
>> 
>> Code quality improves:
>>   GCC:   https://godbolt.org/z/r6G36facj
>>   Clang: https://godbolt.org/z/x5oPdYEPM
>> 
>> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
>> 
>> Testing: hs-tier1 - hs-tier5
>> 
>> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.
>
> Vladimir Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Merge branch 'master' into rwrapper.aarch64
>  - Merge branch 'master' into rwrapper.aarch64
>  - explicit constructors
>  - Merge branch 'master' into rwrapper.aarch64
>  - 8292203: AArch64: Represent Registers as values
>  - cleanups
>  - x86: Register class wrappers

Thanks for the review, Andrew.

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

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

From vlivanov at openjdk.org  Thu Aug 25 16:55:37 2022
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 25 Aug 2022 16:55:37 GMT
Subject: Integrated: 8292203: AArch64: Represent Registers as values
In-Reply-To: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
References: <_s8CT6GCb-kQtYSEzg6iG4n_EDJ4a94t8w9ytbflHsw=.e9b74730-419f-4331-8805-a58e242180f8@github.com>
Message-ID: <mYL8Xg7xpWmt1dxgRYigF5dcTq0hdryLgBfLpSVwj_U=.3acdd17b-7797-432c-b1e7-b81639eeb5f3@github.com>

On Wed, 10 Aug 2022 21:44:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> (It's a PR dependent on #9815.)
> 
> Along with x86 ([JDK-8292153](https://bugs.openjdk.org/browse/JDK-8292153)), I propose to refactor Register classes on AArch64 and migrate away from pointer-based representation.
> 
> The motivation is the same: improve compile-time checks and avoid ambiguities between overloads due to implicit conversions between pointers and integral types.
> 
> Proposed change hides pointer representation behind value class.
> 
> Pointer-based representation is kept to avoid massive migration of users (from `->` to `.`) and to enable incremental migration on per-platform basis (pointer-based representation is assumed in shared code).
> 
> Code quality improves:
>   GCC:   https://godbolt.org/z/r6G36facj
>   Clang: https://godbolt.org/z/x5oPdYEPM
> 
> (I noticed one downside: slowdebug builds become slower, because `operator->` isn't inlined there. If it becomes a problem, migrating performance-sensitive places from `->` to `.` should solve the problem.)
> 
> Testing: hs-tier1 - hs-tier5
> 
> PS: a number of cleanups are incorporated. In particular, I decided to expand all macros from `register.hpp` because IMO they add confusion rather than improve readability.

This pull request has now been integrated.

Changeset: 2fe0ce01
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2fe0ce01485d7b84dc109d3d4f24bdd908c0e7cf
Stats:     527 lines in 15 files changed: 121 ins; 53 del; 353 mod

8292203: AArch64: Represent Registers as values

Reviewed-by: kvn, aph

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

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

From aboldtch at openjdk.org  Fri Aug 26 09:42:05 2022
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 26 Aug 2022 09:42:05 GMT
Subject: Integrated: 8292868: Explicitly pass a third temp register to
 MacroAssembler::store_heap_oop for aarch64
In-Reply-To: <FMyEOZdNQYrQhNeCeMfRlZvAosq3ntY1b9_4KS5_D4E=.0bb634bf-40bd-4021-af2a-c47099f64da0@github.com>
References: <FMyEOZdNQYrQhNeCeMfRlZvAosq3ntY1b9_4KS5_D4E=.0bb634bf-40bd-4021-af2a-c47099f64da0@github.com>
Message-ID: <faqJcYbAC2TbEr6HvQwh6CoMT_Olh6_EHbXJFdl_qZc=.13c50bd0-9803-464a-89b3-ecebbb54f478@github.com>

On Thu, 25 Aug 2022 10:11:30 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> Currently G1 (and Shenandoah) implicitly uses r3 on aarch64 in store_at.
> 
> This out of the blue register fixed for x86 in [JDK-8283186](https://bugs.openjdk.org/browse/JDK-8283186). This would be fixed in the same way on aarch64 by passing the temporary register explicitly so it is part of the GC api
> 
> Testing: Oracle aarch64 platforms tier 1-3

This pull request has now been integrated.

Changeset: f91943c1
Author:    Axel Boldt-Christmas <aboldtch at openjdk.org>
Committer: Erik ?sterlund <eosterlund at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f91943c19fc0b060684a437d2c768461d54c088e
Stats:     68 lines in 16 files changed: 2 ins; 0 del; 66 mod

8292868: Explicitly pass a third temp register to MacroAssembler::store_heap_oop for aarch64

Reviewed-by: shade, eosterlund, tschatzl

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

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

From duke at openjdk.org  Fri Aug 26 17:58:54 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 26 Aug 2022 17:58:54 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
Message-ID: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com>

On Tue, 23 Aug 2022 15:05:48 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> When running with `-XX:+ShenandoahVerify`, the issue manifests as assertion at:
> 
> 
>    1 #
>    2 # A fatal error has been detected by the Java Runtime Environment:
>    3 #
>    4 #  Internal Error (/home/asmehra/data/ashu-mehra/loom/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=920144, tid=920156
>    5 #  Error: Before Evacuation, Reachable; Must be marked in complete bitmap, except j.l.r.Reference referents
>    6 
>    7 Referenced from:
>    8   interior location: 0x00007f0a40000090
>    9   0x00007f0a40000060 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk
>   10         allocated after mark start
>   11     not after update watermark
>   12         marked strong
>   13         marked weak
>   14     not in collection set
>   15   mark: mark(is_neutral no_hash age=0)
>   16   region: |    0|R  |BTE 7f0a40000000, 7f0a401ff9b0, 7f0a40200000|TAMS 7f0a40000000|UWM 7f0a401ff9b0|U  2046K|T  2046K|G     0B|S     0B|L  2046K|CP   0
>   17 
>   18 Object:
>   19   0x00007f0c2f848a40 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk
>   20     not allocated after mark start
>   21     not after update watermark
>   22     not marked strong
>   23     not marked weak
>   24         in collection set
>   25   mark: mark(is_neutral no_hash age=0)
>   26   region: | 3964|CS |BTE 7f0c2f800000, 7f0c2fa00000, 7f0c2fa00000|TAMS 7f0c2fa00000|UWM 7f0c2fa00000|U  2048K|T     0B|G  2048K|S     0B|L  1612K|CP   0
>   27 
>   28 Forwardee:
>   29   (the object itself)
> 
> 
> The StackChunk object `0x00007f0c2f848a40` is not marked which happens to be referenced from the parent field of the newly allocated StackChunk object `0x00007f0a40000060`.
> The sequence for setting `StackChunk::parent` is as follows. At some point during the process of freezing the continuation, the jvm does:
> 
> 
> 	continuationWrapper::_tail = stackChunk1
> 	stackChunk2 = allocate new StackChunk
> 	stackChunk2::parent = continuationWrapper::_tail
> 	continuationWrapper::_tail = stackChunk2
> 
> 
> At the end of the sequence stackChunk1 is only reachable from stackChunk2. If stackChunk2 happens to be allocated after concurrent mark has started and if the shenandoahgc is using IU mode, then the stackChunk2 would would not be scanned. This results in gc missing the marking of stackChunk1 which triggers the the assertion during heap verification.
> 
> This is similar to the sequence described by @fisk [here](https://github.com/openjdk/jdk19/pull/140#issuecomment-1185491224)
> 
> There is code in `FreezeBase::finish_freeze()` to call `stackChunkOopDesc::do_barriers()` which triggers the gc barriers for the newly allocated StackChunk object. But it has two problems:
> 1. The call to `stackChunkOopDesc::do_barriers()` is guarded by a flag [1] which is false for StackChunk objects allocated after marking has started [2]
> 2. `stackChunkOopDesc::do_barriers()` currently triggers the gc barriers for the oops in the stack represented by the newly allocated StackChunk, but it ignores the oops in the StackChunk header
> 
> To fix these two issues, we need the following changes:
> 1. Always enable barrier for Shenandoah IU mode (this change is same as 8288129: Shenandoah: Skynet test crashed with iu + aggressive #9494).
> 2. Add the code in `stackChunkOopDesc::do_barriers` to run the barriers on the oops present in the stack chunk header.
> 
> [1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1201
> [2] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2308
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

@stefank @fisk I see this code [1] which indicates ZGC does not require barriers at all. I would appreciate if either of you can provide inputs on how does ZGC handles the scenario where the previously reachable object O1 is now reachable only from another object O2 allocated after marking has started. How would O1 be marked by ZGC in such case? 
This seems to be the scenario we are hitting in the context of loom code during the freeze process and shenandoah IU mode fails to handle it.

[1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1299

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

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

From duke at openjdk.org  Fri Aug 26 20:22:57 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Fri, 26 Aug 2022 20:22:57 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
 [v2]
In-Reply-To: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
Message-ID: <9ah9SD1YhJdPEqRlH4n9k1NqWha3eTTuNaiQhywVP_Q=.9ab53e2a-4c10-4e2b-be4e-cf1483c2f12d@github.com>

> Please review this patch to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> When running with `-XX:+ShenandoahVerify`, the issue manifests as assertion at:
> 
> 
>    1 #
>    2 # A fatal error has been detected by the Java Runtime Environment:
>    3 #
>    4 #  Internal Error (/home/asmehra/data/ashu-mehra/loom/src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp:92), pid=920144, tid=920156
>    5 #  Error: Before Evacuation, Reachable; Must be marked in complete bitmap, except j.l.r.Reference referents
>    6 
>    7 Referenced from:
>    8   interior location: 0x00007f0a40000090
>    9   0x00007f0a40000060 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk
>   10         allocated after mark start
>   11     not after update watermark
>   12         marked strong
>   13         marked weak
>   14     not in collection set
>   15   mark: mark(is_neutral no_hash age=0)
>   16   region: |    0|R  |BTE 7f0a40000000, 7f0a401ff9b0, 7f0a40200000|TAMS 7f0a40000000|UWM 7f0a401ff9b0|U  2046K|T  2046K|G     0B|S     0B|L  2046K|CP   0
>   17 
>   18 Object:
>   19   0x00007f0c2f848a40 - klass 0x00007f0a0d89a290 jdk.internal.vm.StackChunk
>   20     not allocated after mark start
>   21     not after update watermark
>   22     not marked strong
>   23     not marked weak
>   24         in collection set
>   25   mark: mark(is_neutral no_hash age=0)
>   26   region: | 3964|CS |BTE 7f0c2f800000, 7f0c2fa00000, 7f0c2fa00000|TAMS 7f0c2fa00000|UWM 7f0c2fa00000|U  2048K|T     0B|G  2048K|S     0B|L  1612K|CP   0
>   27 
>   28 Forwardee:
>   29   (the object itself)
> 
> 
> The StackChunk object `0x00007f0c2f848a40` is not marked which happens to be referenced from the parent field of the newly allocated StackChunk object `0x00007f0a40000060`.
> The sequence for setting `StackChunk::parent` is as follows. At some point during the process of freezing the continuation, the jvm does:
> 
> 
> 	continuationWrapper::_tail = stackChunk1
> 	stackChunk2 = allocate new StackChunk
> 	stackChunk2::parent = continuationWrapper::_tail
> 	continuationWrapper::_tail = stackChunk2
> 
> 
> At the end of the sequence stackChunk1 is only reachable from stackChunk2. If stackChunk2 happens to be allocated after concurrent mark has started and if the shenandoahgc is using IU mode, then the stackChunk2 would would not be scanned. This results in gc missing the marking of stackChunk1 which triggers the the assertion during heap verification.
> 
> This is similar to the sequence described by @fisk [here](https://github.com/openjdk/jdk19/pull/140#issuecomment-1185491224)
> 
> There is code in `FreezeBase::finish_freeze()` to call `stackChunkOopDesc::do_barriers()` which triggers the gc barriers for the newly allocated StackChunk object. But it has two problems:
> 1. The call to `stackChunkOopDesc::do_barriers()` is guarded by a flag [1] which is false for StackChunk objects allocated after marking has started [2]
> 2. `stackChunkOopDesc::do_barriers()` currently triggers the gc barriers for the oops in the stack represented by the newly allocated StackChunk, but it ignores the oops in the StackChunk header
> 
> To fix these two issues, we need the following changes:
> 1. Always enable barrier for Shenandoah IU mode (this change is same as 8288129: Shenandoah: Skynet test crashed with iu + aggressive #9494).
> 2. Add the code in `stackChunkOopDesc::do_barriers` to run the barriers on the oops present in the stack chunk header.
> 
> [1] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1201
> [2] https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L2308
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision:

  Enable loom for ShenandoahGC IU mode
  
  Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9982/files
  - new: https://git.openjdk.org/jdk/pull/9982/files/5ce2ca34..d3894f8f

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

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

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

From ysr at openjdk.org  Sat Aug 27 08:01:20 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Sat, 27 Aug 2022 08:01:20 GMT
Subject: RFR: Use only up to ConcGCThreads for concurrent RS scanning.
Message-ID: <ZIeAtLADasjfWgLSUeu4xg-s8_bCCGcN5ZlrK0sgxhA=.ced7d86e-4576-417d-b0cf-48f5b0fba29c@github.com>

The concurrent RS scanning phase was using (up to) ParallelGCThreads, rather than ConcGCThreads as was the original intention for concurrent phases.

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

Commit messages:
 - Use only up to ConcGCThreads for concurrent RS scanning.

Changes: https://git.openjdk.org/shenandoah/pull/159/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah&pr=159&range=00
  Stats: 37 lines in 5 files changed: 33 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/shenandoah/pull/159.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah pull/159/head:pull/159

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

From yadongwang at openjdk.org  Sat Aug 27 15:25:57 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Sat, 27 Aug 2022 15:25:57 GMT
Subject: RFR: 8293007: riscv: optimize nmethod entry barrier
Message-ID: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>

https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier.
Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. 

Tier1 passed on unmatched.

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

Commit messages:
 - fix whitespace
 - 8293007: riscv: optimize nmethod entry barrier

Changes: https://git.openjdk.org/jdk/pull/10056/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10056&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293007
  Stats: 282 lines in 16 files changed: 210 ins; 27 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/10056.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10056/head:pull/10056

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

From kdnilsen at openjdk.org  Sun Aug 28 14:01:51 2022
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sun, 28 Aug 2022 14:01:51 GMT
Subject: RFR: Use only up to ConcGCThreads for concurrent RS scanning.
In-Reply-To: <ZIeAtLADasjfWgLSUeu4xg-s8_bCCGcN5ZlrK0sgxhA=.ced7d86e-4576-417d-b0cf-48f5b0fba29c@github.com>
References: <ZIeAtLADasjfWgLSUeu4xg-s8_bCCGcN5ZlrK0sgxhA=.ced7d86e-4576-417d-b0cf-48f5b0fba29c@github.com>
Message-ID: <h3KaaYsP5y6XHD5ZyOTuG4bEyPPdhkSCXOO9-F8-sMk=.b52409b1-1e0f-45dc-b952-5353d25786c7@github.com>

On Sat, 27 Aug 2022 01:16:55 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> The concurrent RS scanning phase was using (up to) ParallelGCThreads, rather than ConcGCThreads as was the original intention for concurrent phases.

Thanks for putting this together.

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

Marked as reviewed by kdnilsen (Committer).

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

From stefank at openjdk.org  Mon Aug 29 07:02:08 2022
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 29 Aug 2022 07:02:08 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
 <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com>
Message-ID: <yPod9owrfatPjl7szLvNuWnIYfB8iLF-q3QvkBiAdHM=.e1666cff-2e27-4471-bd29-924f1e28497a@github.com>

On Fri, 26 Aug 2022 17:56:41 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> @stefank @fisk I see this code [1] which indicates ZGC does not require barriers at all. I would appreciate if either of you can provide inputs on how does ZGC handles the scenario where the previously reachable object O1 is now reachable only from another object O2 allocated after marking has started. How would O1 be marked by ZGC in such case? This seems to be the scenario we are hitting in the context of loom code during the freeze process and shenandoah IU mode fails to handle it.
> 
> [1]
> 
> https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1299

This is our thinking w.r.t ZGC:
1) ZGC only returns memory from what we call "allocating" ZPages. Such pages are never part of an on-going marking cycle, and therefore don't need any barriers.
2) There's no safepoint *after* the memory has been allocated via `chunk_oop = allocator.allocate(); // can safepoint`

So, when we reach the line you linked to, we are guaranteed that we don't need to perform any GC barriers on that object.

Now, for Shenandoah IU mode, AFAIU (drawing parallels to CMS), the raw initializing stores are problematic, because you don't register those oops anywhere:

  // fields are uninitialized
  chunk->set_parent_raw<typename ConfigT::OopT>(_cont.last_nonempty_chunk());
  chunk->set_cont_raw<typename ConfigT::OopT>(_cont.continuation());


You can also see how that comment about the fields are uninitialized, refers to SATB marking, and most-likely uses that as a rationale for skipping store barriers.

In Generational ZGC, we also introduced store barriers. It's not similar to IU, but you can see how we had to changed from a raw store, to a store with a barrier:
https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/runtime/continuationFreezeThaw.cpp


  // Allocate the chunk.
  //
  // This might safepoint while allocating, but all safepointing due to
  // instrumentation have been deferred. This property is important for
  // some GCs, as this ensures that the allocated object is in the young
  // generation / newly allocated memory.
  StackChunkAllocator allocator(klass, size_in_words, current, stack_size, _cont, _jvmti_event_collector);
  stackChunkOop chunk = allocator.allocate();

  if (chunk == nullptr) {
    return nullptr; // OOME
  }
...
#if INCLUDE_ZGC
  if (UseZGC) {
    // fields are uninitialized
    chunk->set_parent_access<IS_DEST_UNINITIALIZED>(_cont.last_nonempty_chunk());
    chunk->set_cont_access<IS_DEST_UNINITIALIZED>(_cont.continuation());
    ZStackChunkGCData::initialize(chunk);

    assert(!chunk->requires_barriers(), "ZGC always allocates in the young generation");
    _barriers = false;
  } else
#endif

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

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

From fyang at openjdk.org  Mon Aug 29 08:33:35 2022
From: fyang at openjdk.org (Fei Yang)
Date: Mon, 29 Aug 2022 08:33:35 GMT
Subject: RFR: 8293007: riscv: optimize nmethod entry barrier
In-Reply-To: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
Message-ID: <sjxzSWucAFaDi6q4do16nGO-xuU8LuUm5MtjSLBd-Cc=.d75974f6-cf26-4936-9806-3d5e7bd5fb2b@github.com>

On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier.
> Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. 
> 
> Tier1 passed on unmatched.

The riscv-specific code changes look fine. And I see the changes made to hotspot shared code are small and are guarded with #if defined(RISCV), which is the same as how aarch64 does, this should be safe and won't affect other platforms.

BTW: I also performed tier2 hotspot & jdk test on riscv64-linux unmatched machine, result looks good.

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

Marked as reviewed by fyang (Reviewer).

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

From fjiang at openjdk.org  Mon Aug 29 08:45:38 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Mon, 29 Aug 2022 08:45:38 GMT
Subject: RFR: 8293007: riscv: optimize nmethod entry barrier
In-Reply-To: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
Message-ID: <PT6ucbye_StyIrsmsdZ_wueEVPOsorOX-eBpFPRy_fo=.7e658296-41dd-4e50-b09d-17496f455fce@github.com>

On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier.
> Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. 
> 
> Tier1 passed on unmatched.

Looks good. (Not a JDK Reviewer)

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

Marked as reviewed by fjiang (Author).

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

From yadongwang at openjdk.org  Mon Aug 29 09:18:52 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Mon, 29 Aug 2022 09:18:52 GMT
Subject: RFR: 8293007: riscv: optimize nmethod entry barrier
In-Reply-To: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
Message-ID: <y5EdXwofmvJj0d2dw3SYhogO8zGI7MbrOyzmFN3mlhU=.7a86185d-2f12-42ae-b0c8-f6184c0f3e1b@github.com>

On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier.
> Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. 
> 
> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.

Better have another review, maybe @shipilev please?

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

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

From shade at openjdk.org  Mon Aug 29 11:29:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Aug 2022 11:29:11 GMT
Subject: RFR: 8293007: riscv: optimize nmethod entry barrier
In-Reply-To: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
Message-ID: <BAAO9arx65btGc0gGdv-xaVtaOUOwkzepFNElhNr9gY=.02daf915-077b-48ec-a79d-05bd4b9d6e23@github.com>

On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

> https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier.
> Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. 
> 
> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.

Looks okay with minor comments.

src/hotspot/cpu/riscv/gc/g1/g1BarrierSetAssembler_riscv.cpp line 161:

> 159:   __ bind(runtime);
> 160: 
> 161:   __ push_call_clobbered_registers();

So this looks like a bugfix? https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000601.html

The issue and PR should probably reflect that then.

src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 192:

> 190: 
> 191: void BarrierSetAssembler::clear_patching_epoch() {
> 192:   _patching_epoch = 0;

Don't we want `Atomic::store(&_patching_epoch, 0)` here?

src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 224:

> 222:         // which means there isn't really any need for any fencing for neither
> 223:         // data nor instruction modification happening concurrently. The
> 224:         // instruction patching is synchronized with glocal icache_flush() by

"global"?

src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp line 204:

> 202:     // are read in the opposite order, such that the load of the nmethod guard
> 203:     // acquires the patching epoch. This way, the guard is guaranteed to block
> 204:     // entries to the nmethod, util it has safely published the requirement for

"until"?

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

Marked as reviewed by shade (Reviewer).

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

From yadongwang at openjdk.org  Mon Aug 29 14:13:00 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Mon, 29 Aug 2022 14:13:00 GMT
Subject: RFR: 8293007: riscv: optimize nmethod entry barrier
In-Reply-To: <BAAO9arx65btGc0gGdv-xaVtaOUOwkzepFNElhNr9gY=.02daf915-077b-48ec-a79d-05bd4b9d6e23@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <BAAO9arx65btGc0gGdv-xaVtaOUOwkzepFNElhNr9gY=.02daf915-077b-48ec-a79d-05bd4b9d6e23@github.com>
Message-ID: <Bs3toVzlDS-ch72cmstG_OSfvGFEEaUB8Sdm2ybTF9s=.882fc9e2-e248-414b-9bf9-fe1f419f9e15@github.com>

On Mon, 29 Aug 2022 11:15:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> https://bugs.openjdk.org/browse/JDK-8290700 introduced a faster nmethod entry barrier: a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier.
>> Porting loom and generational ZGC are both under development in progress in riscv port project, and we brought the similar modification to make things smooth. 
>> 
>> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.
>
> src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 192:
> 
>> 190: 
>> 191: void BarrierSetAssembler::clear_patching_epoch() {
>> 192:   _patching_epoch = 0;
> 
> Don't we want `Atomic::store(&_patching_epoch, 0)` here?

We can do a relax clear here, because clear_patching_epoch() was only called by arm_all_nmethods(), which happened always in the safepoint.

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

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

From yadongwang at openjdk.org  Mon Aug 29 14:41:12 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Mon, 29 Aug 2022 14:41:12 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2]
In-Reply-To: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
Message-ID: <cQmIeRgRxdczbxWup9XxoMwi1fx0UwB-3UM5bFpY71s=.94897b88-b71e-4adc-9c9e-c9883bb57e9d@github.com>

> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping.
> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre().
>  
> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth.
> 
> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. 
> 
> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.

Yadong Wang has updated the pull request incrementally with two additional commits since the last revision:

 - fix typo
 - fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10056/files
  - new: https://git.openjdk.org/jdk/pull/10056/files/8ef56f73..2bcc0331

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

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

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

From yadongwang at openjdk.org  Mon Aug 29 14:41:15 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Mon, 29 Aug 2022 14:41:15 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2]
In-Reply-To: <BAAO9arx65btGc0gGdv-xaVtaOUOwkzepFNElhNr9gY=.02daf915-077b-48ec-a79d-05bd4b9d6e23@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <BAAO9arx65btGc0gGdv-xaVtaOUOwkzepFNElhNr9gY=.02daf915-077b-48ec-a79d-05bd4b9d6e23@github.com>
Message-ID: <IZ13HSXbkxmGCT_VKGW5WebB3GyVCLg1yFDwTO7wml0=.4ca01e0c-58b6-431c-9ca9-45428c078dc0@github.com>

On Mon, 29 Aug 2022 11:14:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yadong Wang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix typo
>>  - fix typo
>
> src/hotspot/cpu/riscv/gc/g1/g1BarrierSetAssembler_riscv.cpp line 161:
> 
>> 159:   __ bind(runtime);
>> 160: 
>> 161:   __ push_call_clobbered_registers();
> 
> So this looks like a bugfix? https://mail.openjdk.org/pipermail/riscv-port-dev/2022-August/000601.html
> 
> The issue and PR should probably reflect that then.

Agree. I have modified issue and PR.

> src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 224:
> 
>> 222:         // which means there isn't really any need for any fencing for neither
>> 223:         // data nor instruction modification happening concurrently. The
>> 224:         // instruction patching is synchronized with glocal icache_flush() by
> 
> "global"?

Thanks. Fixed.

> src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp line 204:
> 
>> 202:     // are read in the opposite order, such that the load of the nmethod guard
>> 203:     // acquires the patching epoch. This way, the guard is guaranteed to block
>> 204:     // entries to the nmethod, util it has safely published the requirement for
> 
> "until"?

Fixed.

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

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

From yadongwang at openjdk.org  Mon Aug 29 14:41:17 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Mon, 29 Aug 2022 14:41:17 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2]
In-Reply-To: <IZ13HSXbkxmGCT_VKGW5WebB3GyVCLg1yFDwTO7wml0=.4ca01e0c-58b6-431c-9ca9-45428c078dc0@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <BAAO9arx65btGc0gGdv-xaVtaOUOwkzepFNElhNr9gY=.02daf915-077b-48ec-a79d-05bd4b9d6e23@github.com>
 <IZ13HSXbkxmGCT_VKGW5WebB3GyVCLg1yFDwTO7wml0=.4ca01e0c-58b6-431c-9ca9-45428c078dc0@github.com>
Message-ID: <2Nxt4JwZvcFnhpvVDcm-H4Mi4uvDS21swh4IaIKcNiI=.31d0a7d4-f3dd-4454-b108-aea15cac2de3@github.com>

On Mon, 29 Aug 2022 14:34:13 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/gc/shared/barrierSetNMethod_riscv.cpp line 204:
>> 
>>> 202:     // are read in the opposite order, such that the load of the nmethod guard
>>> 203:     // acquires the patching epoch. This way, the guard is guaranteed to block
>>> 204:     // entries to the nmethod, util it has safely published the requirement for
>> 
>> "until"?
>
> Fixed.

Fixed.

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

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

From shade at openjdk.org  Mon Aug 29 15:00:01 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Aug 2022 15:00:01 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2]
In-Reply-To: <cQmIeRgRxdczbxWup9XxoMwi1fx0UwB-3UM5bFpY71s=.94897b88-b71e-4adc-9c9e-c9883bb57e9d@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <cQmIeRgRxdczbxWup9XxoMwi1fx0UwB-3UM5bFpY71s=.94897b88-b71e-4adc-9c9e-c9883bb57e9d@github.com>
Message-ID: <MS9zW7ZH0zUPngtsR9kEt9rUN_mgRbmtGLuyweEyn2E=.12da9600-d0ec-47f2-a579-6952b185d692@github.com>

On Mon, 29 Aug 2022 14:41:12 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

>> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping.
>> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre().
>>  
>> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth.
>> 
>> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. 
>> 
>> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.
>
> Yadong Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix typo
>  - fix typo

Marked as reviewed by shade (Reviewer).

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

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

From shade at openjdk.org  Mon Aug 29 15:00:06 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 29 Aug 2022 15:00:06 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2]
In-Reply-To: <Bs3toVzlDS-ch72cmstG_OSfvGFEEaUB8Sdm2ybTF9s=.882fc9e2-e248-414b-9bf9-fe1f419f9e15@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <BAAO9arx65btGc0gGdv-xaVtaOUOwkzepFNElhNr9gY=.02daf915-077b-48ec-a79d-05bd4b9d6e23@github.com>
 <Bs3toVzlDS-ch72cmstG_OSfvGFEEaUB8Sdm2ybTF9s=.882fc9e2-e248-414b-9bf9-fe1f419f9e15@github.com>
Message-ID: <gQOqKazMiOLy32lfj4rOvjvBKDdSl4jSaLm8bBVPRwg=.e784097c-eded-4347-95e1-bcde667a14f7@github.com>

On Mon, 29 Aug 2022 14:09:28 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/gc/shared/barrierSetAssembler_riscv.cpp line 192:
>> 
>>> 190: 
>>> 191: void BarrierSetAssembler::clear_patching_epoch() {
>>> 192:   _patching_epoch = 0;
>> 
>> Don't we want `Atomic::store(&_patching_epoch, 0)` here?
>
> We can do a relax clear here, because clear_patching_epoch() was only called by arm_all_nmethods(), which happened always in the safepoint.

Allright then.

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

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

From wkemper at openjdk.org  Mon Aug 29 15:40:52 2022
From: wkemper at openjdk.org (William Kemper)
Date: Mon, 29 Aug 2022 15:40:52 GMT
Subject: RFR: Use only up to ConcGCThreads for concurrent RS scanning.
In-Reply-To: <ZIeAtLADasjfWgLSUeu4xg-s8_bCCGcN5ZlrK0sgxhA=.ced7d86e-4576-417d-b0cf-48f5b0fba29c@github.com>
References: <ZIeAtLADasjfWgLSUeu4xg-s8_bCCGcN5ZlrK0sgxhA=.ced7d86e-4576-417d-b0cf-48f5b0fba29c@github.com>
Message-ID: <jahhSH7b5WJTxwiW1Cx7WBtoosNcMecksOzMSyI6FTI=.d5af07ec-32e1-4e5e-b0bc-1b2c79cc6f30@github.com>

On Sat, 27 Aug 2022 01:16:55 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> The concurrent RS scanning phase was using (up to) ParallelGCThreads, rather than ConcGCThreads as was the original intention for concurrent phases.

Marked as reviewed by wkemper (Committer).

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

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

From eosterlund at openjdk.org  Mon Aug 29 16:13:11 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Mon, 29 Aug 2022 16:13:11 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <yPod9owrfatPjl7szLvNuWnIYfB8iLF-q3QvkBiAdHM=.e1666cff-2e27-4471-bd29-924f1e28497a@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
 <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com>
 <yPod9owrfatPjl7szLvNuWnIYfB8iLF-q3QvkBiAdHM=.e1666cff-2e27-4471-bd29-924f1e28497a@github.com>
Message-ID: <ZyigmZ5Kmq3RnQZAZIzsZSONbPl8DbfKpRcsN8slFHw=.88bedd4e-5a39-42d8-9c81-d4c75122f1be@github.com>

On Mon, 29 Aug 2022 06:58:37 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > @stefank @fisk I see this code [1] which indicates ZGC does not require barriers at all. I would appreciate if either of you can provide inputs on how does ZGC handles the scenario where the previously reachable object O1 is now reachable only from another object O2 allocated after marking has started. How would O1 be marked by ZGC in such case? This seems to be the scenario we are hitting in the context of loom code during the freeze process and shenandoah IU mode fails to handle it.
> 
> > 
> 
> > [1]
> 
> > 
> 
> > https://github.com/openjdk/jdk/blob/9a0d1e7ce86368cdcade713a9e220604f7d77ecf/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1299
> 
> 
> 
> This is our thinking w.r.t ZGC:
> 
> 1) ZGC only returns memory from what we call "allocating" ZPages. Such pages are never part of an on-going marking cycle, and therefore don't need any barriers.
> 
> 2) There's no safepoint *after* the memory has been allocated via `chunk_oop = allocator.allocate(); // can safepoint`
> 
> 
> 
> So, when we reach the line you linked to, we are guaranteed that we don't need to perform any GC barriers on that object.
> 
> 
> 
> Now, for Shenandoah IU mode, AFAIU (drawing parallels to CMS), the raw initializing stores are problematic, because you don't register those oops anywhere:
> 
> ```
> 
>   // fields are uninitialized
> 
>   chunk->set_parent_raw<typename ConfigT::OopT>(_cont.last_nonempty_chunk());
> 
>   chunk->set_cont_raw<typename ConfigT::OopT>(_cont.continuation());
> 
> ```
> 
> 
> 
> You can also see how that comment about the fields are uninitialized, refers to SATB marking, and most-likely uses that as a rationale for skipping store barriers.
> 
> 
> 
> In Generational ZGC, we also introduced store barriers. It's not similar to IU, but you can see how we had to changed from a raw store, to a store with a barrier:
> 
> https://github.com/openjdk/zgc/blob/f0b25d9339104a80f903d889a7939dd623c76867/src/hotspot/share/runtime/continuationFreezeThaw.cpp
> 
> 
> 
> ```
> 
>   // Allocate the chunk.
> 
>   //
> 
>   // This might safepoint while allocating, but all safepointing due to
> 
>   // instrumentation have been deferred. This property is important for
> 
>   // some GCs, as this ensures that the allocated object is in the young
> 
>   // generation / newly allocated memory.
> 
>   StackChunkAllocator allocator(klass, size_in_words, current, stack_size, _cont, _jvmti_event_collector);
> 
>   stackChunkOop chunk = allocator.allocate();
> 
> 
> 
>   if (chunk == nullptr) {
> 
>     return nullptr; // OOME
> 
>   }
> 
> ...
> 
> #if INCLUDE_ZGC
> 
>   if (UseZGC) {
> 
>     // fields are uninitialized
> 
>     chunk->set_parent_access<IS_DEST_UNINITIALIZED>(_cont.last_nonempty_chunk());
> 
>     chunk->set_cont_access<IS_DEST_UNINITIALIZED>(_cont.continuation());
> 
>     ZStackChunkGCData::initialize(chunk);
> 
> 
> 
>     assert(!chunk->requires_barriers(), "ZGC always allocates in the young generation");
> 
>     _barriers = false;
> 
>   } else
> 
> #endif
> 
> ```

The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not.

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

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

From ysr at openjdk.org  Mon Aug 29 18:12:52 2022
From: ysr at openjdk.org (Y. Srinivas Ramakrishna)
Date: Mon, 29 Aug 2022 18:12:52 GMT
Subject: Integrated: Use only up to ConcGCThreads for concurrent RS scanning.
In-Reply-To: <ZIeAtLADasjfWgLSUeu4xg-s8_bCCGcN5ZlrK0sgxhA=.ced7d86e-4576-417d-b0cf-48f5b0fba29c@github.com>
References: <ZIeAtLADasjfWgLSUeu4xg-s8_bCCGcN5ZlrK0sgxhA=.ced7d86e-4576-417d-b0cf-48f5b0fba29c@github.com>
Message-ID: <2pbI01bxwTTn7XsI0Bc2RZeRQaTwVQe_Gk8CCQHZJcI=.c4feccca-84c0-4eef-833f-32a1bc68222c@github.com>

On Sat, 27 Aug 2022 01:16:55 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

> The concurrent RS scanning phase was using (up to) ParallelGCThreads, rather than ConcGCThreads as was the original intention for concurrent phases.

This pull request has now been integrated.

Changeset: 270e8b89
Author:    Y. Srinivas Ramakrishna <ysr at openjdk.org>
Committer: William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.org/shenandoah/commit/270e8b89a1599c8cb87f9846fb0eb146ecd525b6
Stats:     37 lines in 5 files changed: 33 ins; 1 del; 3 mod

Use only up to ConcGCThreads for concurrent RS scanning.

Reviewed-by: kdnilsen, wkemper

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

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

From duke at openjdk.org  Mon Aug 29 19:15:10 2022
From: duke at openjdk.org (cfumiwu)
Date: Mon, 29 Aug 2022 19:15:10 GMT
Subject: RFR: Log rotation
Message-ID: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>

Making the shenandoah log file be able to rotate with given log file count and log file size. Default log file count would be 5 and default log file size would be 20MB.

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

Commit messages:
 - Syncing the file with the local changes
 - Exit JVM when initialization failed
 - Adding assertion error when _stream is NULL
 - Terminate process when initailization fails
 - Prints error message when _stream is NULL and change description for command line options
 - Adding new log rotation test case and delete unused variables
 - Create log rotation for shenandoah log files

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

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

From robilad at openjdk.org  Mon Aug 29 19:15:10 2022
From: robilad at openjdk.org (Dalibor Topic)
Date: Mon, 29 Aug 2022 19:15:10 GMT
Subject: RFR: Log rotation
In-Reply-To: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
References: <EtWvtoNUC8vkf_JlOHfqimmZwLxW9F1gu_FcLDCkqjw=.ff06c5e2-1676-49e7-999c-942560532201@github.com>
Message-ID: <i0L4knn1-02nwroKhDWxjnZo76WJhxUSPrNwWHlgAm0=.07a3ed59-e0f3-4657-ac4e-bb13bb5abe9d@github.com>

On Fri, 26 Aug 2022 17:06:42 GMT, cfumiwu <duke at openjdk.org> wrote:

> Making the shenandoah log file be able to rotate with given log file count and log file size. Default log file count would be 5 and default log file size would be 20MB.

Hi, please send an e-Mail to Dalibor.topic at oracle.com so that I can verify your account.

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

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

From yadongwang at openjdk.org  Tue Aug 30 01:20:23 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Tue, 30 Aug 2022 01:20:23 GMT
Subject: Integrated: 8293007: riscv: failed to build after JDK-8290025
In-Reply-To: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
Message-ID: <yznCJ3xodeGrPlCOw_dYPH13RHabg8P27iws8if744Y=.2c9af071-1d04-45b1-83c1-b963b5c592ad@github.com>

On Sat, 27 Aug 2022 14:54:18 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping.
> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre().
>  
> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth.
> 
> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. 
> 
> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.

This pull request has now been integrated.

Changeset: e016363b
Author:    Yadong Wang <yadongwang at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e016363b54f1624e9ff4470803c6000d8fe91a7f
Stats:     283 lines in 16 files changed: 210 ins; 27 del; 46 mod

8293007: riscv: failed to build after JDK-8290025

Reviewed-by: fyang, fjiang, shade

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

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

From kvn at openjdk.org  Tue Aug 30 03:46:17 2022
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 30 Aug 2022 03:46:17 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025
In-Reply-To: <y5EdXwofmvJj0d2dw3SYhogO8zGI7MbrOyzmFN3mlhU=.7a86185d-2f12-42ae-b0c8-f6184c0f3e1b@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <y5EdXwofmvJj0d2dw3SYhogO8zGI7MbrOyzmFN3mlhU=.7a86185d-2f12-42ae-b0c8-f6184c0f3e1b@github.com>
Message-ID: <mWS-PSZusudQjNATPSKk1EsiJfLPUQWxvYjON1NeRxw=.9971aab8-bbf8-4717-ba2c-b259f5096c3d@github.com>

On Mon, 29 Aug 2022 09:15:26 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

>> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping.
>> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre().
>>  
>> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth.
>> 
>> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. 
>> 
>> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.
>
> Better have another review, maybe @shipilev please?

@yadongw this broke aarch64 Zero build:

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

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

From fjiang at openjdk.org  Tue Aug 30 05:04:09 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 30 Aug 2022 05:04:09 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025
In-Reply-To: <y5EdXwofmvJj0d2dw3SYhogO8zGI7MbrOyzmFN3mlhU=.7a86185d-2f12-42ae-b0c8-f6184c0f3e1b@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <y5EdXwofmvJj0d2dw3SYhogO8zGI7MbrOyzmFN3mlhU=.7a86185d-2f12-42ae-b0c8-f6184c0f3e1b@github.com>
Message-ID: <YaPqpol1BmL-DA5wrMIRukZoosyG27PbyQl7I-e02EE=.2e2fe540-bb33-455b-a0ab-4563f3b61cd9@github.com>

On Mon, 29 Aug 2022 09:15:26 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

>> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping.
>> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre().
>>  
>> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth.
>> 
>> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. 
>> 
>> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.
>
> Better have another review, maybe @shipilev please?

> @yadongw this broke aarch64 Zero build:
> 
> ```
> /workspace/open/src/hotspot/share/gc/shared/barrierSetNMethod.cpp: In member function 'void BarrierSetNMethod::arm_all_nmethods()':
> /workspace/open/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:136:24: error: incomplete type 'BarrierSetAssembler' used in nested name specifier
>    136 |   BarrierSetAssembler::clear_patching_epoch();
>        |                        ^~~~~~~~~~~~~~~~~~~~
> ```

Thanks for reporting this issue, I'm working on it and will submit a fixing PR later.

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

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

From yadongwang at openjdk.org  Tue Aug 30 05:11:04 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Tue, 30 Aug 2022 05:11:04 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025
In-Reply-To: <y5EdXwofmvJj0d2dw3SYhogO8zGI7MbrOyzmFN3mlhU=.7a86185d-2f12-42ae-b0c8-f6184c0f3e1b@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <y5EdXwofmvJj0d2dw3SYhogO8zGI7MbrOyzmFN3mlhU=.7a86185d-2f12-42ae-b0c8-f6184c0f3e1b@github.com>
Message-ID: <OLZNmicMct6wG3RWnPK2WQjdHYX-1QkizR5sfYy8-SY=.9de46574-3115-43b1-8178-0c52b4f9df6b@github.com>

On Mon, 29 Aug 2022 09:15:26 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

>> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping.
>> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre().
>>  
>> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth.
>> 
>> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. 
>> 
>> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.
>
> Better have another review, maybe @shipilev please?

> @yadongw this broke aarch64 Zero build:
> 
> ```
> /workspace/open/src/hotspot/share/gc/shared/barrierSetNMethod.cpp: In member function 'void BarrierSetNMethod::arm_all_nmethods()':
> /workspace/open/src/hotspot/share/gc/shared/barrierSetNMethod.cpp:136:24: error: incomplete type 'BarrierSetAssembler' used in nested name specifier
>    136 |   BarrierSetAssembler::clear_patching_epoch();
>        |                        ^~~~~~~~~~~~~~~~~~~~
> ```

@vnkozlov Sorry for the problem. I missed the building/testing of zero, and we'll fix that right way.

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

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

From fjiang at openjdk.org  Tue Aug 30 06:23:01 2022
From: fjiang at openjdk.org (Feilong Jiang)
Date: Tue, 30 Aug 2022 06:23:01 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2]
In-Reply-To: <cQmIeRgRxdczbxWup9XxoMwi1fx0UwB-3UM5bFpY71s=.94897b88-b71e-4adc-9c9e-c9883bb57e9d@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <cQmIeRgRxdczbxWup9XxoMwi1fx0UwB-3UM5bFpY71s=.94897b88-b71e-4adc-9c9e-c9883bb57e9d@github.com>
Message-ID: <jsoh7OJrhE1MnhPIKOQAjUiFduxS0Wilt-J_pHGA6z0=.d0cae1cb-3be2-4647-951b-6ec3b093fa2b@github.com>

On Mon, 29 Aug 2022 14:41:12 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

>> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping.
>> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre().
>>  
>> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth.
>> 
>> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. 
>> 
>> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.
>
> Yadong Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix typo
>  - fix typo

See: https://github.com/openjdk/jdk/pull/10075

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

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

From eosterlund at openjdk.org  Tue Aug 30 07:16:50 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 30 Aug 2022 07:16:50 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2]
In-Reply-To: <cQmIeRgRxdczbxWup9XxoMwi1fx0UwB-3UM5bFpY71s=.94897b88-b71e-4adc-9c9e-c9883bb57e9d@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <cQmIeRgRxdczbxWup9XxoMwi1fx0UwB-3UM5bFpY71s=.94897b88-b71e-4adc-9c9e-c9883bb57e9d@github.com>
Message-ID: <hWUv70eJYGh8doQbfUJG0ZJ0sRtA558SMG9gZUl7J5c=.0d2b3b4c-efaa-48ec-9cc3-c7a09d248155@github.com>

On Mon, 29 Aug 2022 14:41:12 GMT, Yadong Wang <yadongwang at openjdk.org> wrote:

>> The riscv port tier1 failed after JDK-8290025?after which GC took over the work of code cache sweeping.
>> Then, concurrent GC like ZGC or Shenandoah failed at the unimplemented BarreirSetNMethod::arm(), and meanwhile, it exposed a long-stand bug in G1BarrierSetAssembler::g1_write_barrier_pre().
>>  
>> Considering we are at the same time to rewrite the nmethod entry barrier when porting loom and generational ZGC in riscv port, we solve them together in this issue to make things smooth.
>> 
>> Like JDK-8290700, we brought the similar optimization to the nmethod entry barrier, and introduced a out-of-line stub to the entry barriers of C2 methods, and also a concurrent-data-and instruction-patching barrier. 
>> 
>> Tier1 passed on unmatched, and also full jtreg tests tested on qemu user mode without new failures.
>
> Yadong Wang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - fix typo
>  - fix typo

Sorry for the late feedback but I'm not sure this looks right.

src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2352:

> 2350:       __ lwu(t1, t1);
> 2351:       __ sw(t1, thread_epoch_addr);
> 2352:       __ membar(__ LoadLoad);

Don't you need a FENCE.I instruction here? Similar to the AArch64 isb instruction.

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

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

From yadongwang at openjdk.org  Tue Aug 30 09:10:13 2022
From: yadongwang at openjdk.org (Yadong Wang)
Date: Tue, 30 Aug 2022 09:10:13 GMT
Subject: RFR: 8293007: riscv: failed to build after JDK-8290025 [v2]
In-Reply-To: <hWUv70eJYGh8doQbfUJG0ZJ0sRtA558SMG9gZUl7J5c=.0d2b3b4c-efaa-48ec-9cc3-c7a09d248155@github.com>
References: <E5i4Py3r892Yk8OPxJafZVTCNjx01Ssu0XIXR7sh9LA=.a0647e68-d504-4a44-bc34-62a99b800c74@github.com>
 <cQmIeRgRxdczbxWup9XxoMwi1fx0UwB-3UM5bFpY71s=.94897b88-b71e-4adc-9c9e-c9883bb57e9d@github.com>
 <hWUv70eJYGh8doQbfUJG0ZJ0sRtA558SMG9gZUl7J5c=.0d2b3b4c-efaa-48ec-9cc3-c7a09d248155@github.com>
Message-ID: <9vNWr4kJDCJeWaXcxGHpgOUH-VFNqsZ0WN2UcJTJavY=.4081e45d-da6e-41d8-8854-8868321791cb@github.com>

On Tue, 30 Aug 2022 07:12:45 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Yadong Wang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - fix typo
>>  - fix typo
>
> src/hotspot/cpu/riscv/stubGenerator_riscv.cpp line 2352:
> 
>> 2350:       __ lwu(t1, t1);
>> 2351:       __ sw(t1, thread_epoch_addr);
>> 2352:       __ membar(__ LoadLoad);
> 
> Don't you need a FENCE.I instruction here? Similar to the AArch64 isb instruction.

We don't need a fence.i here in the riscv port , see our discussion in https://mail.openjdk.org/pipermail/riscv-port- dev/2022-July/000572.html.

In the riscv world, fence.i in user-space cannot guarante the read hart see the modified code because threads may migrate to other processor core after fence.i. Instead, we called icache_flush() after the write hart modified code, which synchronized all harts to flush icache by IPI in kernel mode. So the read hart do not need a fence.i.

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

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

From duke at openjdk.org  Tue Aug 30 15:24:25 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 30 Aug 2022 15:24:25 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <ZyigmZ5Kmq3RnQZAZIzsZSONbPl8DbfKpRcsN8slFHw=.88bedd4e-5a39-42d8-9c81-d4c75122f1be@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
 <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com>
 <yPod9owrfatPjl7szLvNuWnIYfB8iLF-q3QvkBiAdHM=.e1666cff-2e27-4471-bd29-924f1e28497a@github.com>
 <ZyigmZ5Kmq3RnQZAZIzsZSONbPl8DbfKpRcsN8slFHw=.88bedd4e-5a39-42d8-9c81-d4c75122f1be@github.com>
Message-ID: <CJqfTI6g96XBafHMRdaUVlHrZ8P44y-SVKAgpnb98Qg=.e2d945d5-e4dd-4ff0-b013-1bb7d10feac9@github.com>

On Mon, 29 Aug 2022 16:09:05 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

> The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not.

@fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean.
It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt?

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

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

From eosterlund at openjdk.org  Tue Aug 30 15:46:07 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 30 Aug 2022 15:46:07 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <CJqfTI6g96XBafHMRdaUVlHrZ8P44y-SVKAgpnb98Qg=.e2d945d5-e4dd-4ff0-b013-1bb7d10feac9@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
 <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com>
 <yPod9owrfatPjl7szLvNuWnIYfB8iLF-q3QvkBiAdHM=.e1666cff-2e27-4471-bd29-924f1e28497a@github.com>
 <ZyigmZ5Kmq3RnQZAZIzsZSONbPl8DbfKpRcsN8slFHw=.88bedd4e-5a39-42d8-9c81-d4c75122f1be@github.com>
 <CJqfTI6g96XBafHMRdaUVlHrZ8P44y-SVKAgpnb98Qg=.e2d945d5-e4dd-4ff0-b013-1bb7d10feac9@github.com>
Message-ID: <GfTHBd-62-LzCeGM3RODBqQnFooOSMWaVxrJXaeS6GI=.2d01dc04-2c03-4f9a-af43-16a87096ecad@github.com>

On Tue, 30 Aug 2022 15:20:48 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> > The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not.
> 
> @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean. It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt?

That is precisely what I am suggesting. The situation is the opposite from what you think. The Access API *is* the public interface to the GC, that will do the right thing for all GCs, while the requires_barriers and do_barriers stuff is less general, as I just discussed.

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

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

From duke at openjdk.org  Tue Aug 30 16:02:00 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 30 Aug 2022 16:02:00 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <GfTHBd-62-LzCeGM3RODBqQnFooOSMWaVxrJXaeS6GI=.2d01dc04-2c03-4f9a-af43-16a87096ecad@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
 <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com>
 <yPod9owrfatPjl7szLvNuWnIYfB8iLF-q3QvkBiAdHM=.e1666cff-2e27-4471-bd29-924f1e28497a@github.com>
 <ZyigmZ5Kmq3RnQZAZIzsZSONbPl8DbfKpRcsN8slFHw=.88bedd4e-5a39-42d8-9c81-d4c75122f1be@github.com>
 <CJqfTI6g96XBafHMRdaUVlHrZ8P44y-SVKAgpnb98Qg=.e2d945d5-e4dd-4ff0-b013-1bb7d10feac9@github.com>
 <GfTHBd-62-LzCeGM3RODBqQnFooOSMWaVxrJXaeS6GI=.2d01dc04-2c03-4f9a-af43-16a87096ecad@github.com>
Message-ID: <EB1k07CzFEwmh1v8A1i-FMgv57i4YyVushGW5qqlckA=.e151cb95-ef95-42ef-87bf-d80f709f9808@github.com>

On Tue, 30 Aug 2022 15:42:31 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>>> The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not.
>> 
>> @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean.
>> It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt?
>
>> > The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not.
>> 
>> @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean. It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt?
> 
> That is precisely what I am suggesting. The situation is the opposite from what you think. The Access API *is* the public interface to the GC, that will do the right thing for all GCs, while the requires_barriers and do_barriers stuff is less general, as I just discussed.

@fisk you are right, I see now that `set_parent_access<IS_DEST_UNINITIALIZED>` is a no-op for satb barriers. So we can just change `set_parent_raw` to `set_parent_access<IS_DEST_UNINITIALIZED>` for all gc policies, right?
btw `set_parent_access<decorators>` is missing in the mainline, so I would have to add this API (and the corresponding API oop::obj_field_put_access) as well. Does that make sense?

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

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

From eosterlund at openjdk.org  Tue Aug 30 16:02:00 2022
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Tue, 30 Aug 2022 16:02:00 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <GfTHBd-62-LzCeGM3RODBqQnFooOSMWaVxrJXaeS6GI=.2d01dc04-2c03-4f9a-af43-16a87096ecad@github.com>
References: <yBWWsT0pshofoCQQYPDI0oHn2yQdJadfS3fK3_yLmg0=.cabeb805-ca02-4db4-86ac-c5b406922696@github.com>
 <_iVJ9T-0cTV6qOg0nYWdkc5fuVONketYVGz1XpHaRoE=.885f341f-ad7b-4c21-97d9-329de4bf3284@github.com>
 <yPod9owrfatPjl7szLvNuWnIYfB8iLF-q3QvkBiAdHM=.e1666cff-2e27-4471-bd29-924f1e28497a@github.com>
 <ZyigmZ5Kmq3RnQZAZIzsZSONbPl8DbfKpRcsN8slFHw=.88bedd4e-5a39-42d8-9c81-d4c75122f1be@github.com>
 <CJqfTI6g96XBafHMRdaUVlHrZ8P44y-SVKAgpnb98Qg=.e2d945d5-e4dd-4ff0-b013-1bb7d10feac9@github.com>
 <GfTHBd-62-LzCeGM3RODBqQnFooOSMWaVxrJXaeS6GI=.2d01dc04-2c03-4f9a-af43-16a87096ecad@github.com>
Message-ID: <7ikOdW5iF-kptYo_k02QoZOPXVUeU1OVqsDk0r7FF98=.daca7ba6-3711-4f02-bf9e-755705a029a8@github.com>

On Tue, 30 Aug 2022 15:42:31 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>>> The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not.
>> 
>> @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean.
>> It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt?
>
>> > The neat thing with using the right Access API stores instead of an ad hoc barrier, is that it works for both shenandoah IU mode, and generational ZGC, while the ad hoc barrier does not.
>> 
>> @fisk are you suggesting that changing the Access API from `set_parent_raw` to `set_parent_access` is the right approach? This introduces gc policy specific code which does not look clean. It appears that the combination of `requires_barriers()` and `do_barriers()` API is suppose to encapsulate the gc policy specific requirements. `requires_barriers()` would handle any gc specific requirement for using barriers and `do_barriers()` would then take the necessary action. This makes sense as it keeps the code clean. wdyt?
> 
> That is precisely what I am suggesting. The situation is the opposite from what you think. The Access API *is* the public interface to the GC, that will do the right thing for all GCs, while the requires_barriers and do_barriers stuff is less general, as I just discussed.

> @fisk you are right, I see now that `set_parent_access<IS_DEST_UNINITIALIZED>` is a no-op for satb barriers. So we can just change `set_parent_raw` to `set_parent_access<IS_DEST_UNINITIALIZED>` for all gc policies, right?
> 
> btw `set_parent_access<decorators>` is missing in the mainline, so I would have to add this API (and the corresponding API oop::obj_field_put_access) as well. Does that make sense?

That sounds great! :)

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

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

From wkemper at openjdk.org  Tue Aug 30 17:29:50 2022
From: wkemper at openjdk.org (William Kemper)
Date: Tue, 30 Aug 2022 17:29:50 GMT
Subject: RFR: Enhancements for Shenandoah's generational mode
Message-ID: <McFzerNRWchKo-tk5sK7mVS6YGbx-9lvwK5Y5pPfsLs=.13c66f9a-4aad-48f2-b4fd-6e042be5cd8a@github.com>

During the course of the development of the generational mode for Shenandoah, we have found this tool useful to demonstrate progress and changes in behavior. We have also found this tool useful for troubleshooting performance issues and debugging crashes. There are many changes here, but these are the highlights:
* The age and affiliation of a region are encoded in the border and shape of the region (respectively).
* Phases are encoded with different colors for different generations and whether they have degenerated.
* A mechanism to record and replay session has been added (record feature is implemented in hotspot and is not yet upstream).
* Popup windows can be opened for additional detail on regions, as well as their history.
* The legend shows the number of regions in the state described by the legend item.
* Visualizer can now 'find' VMs running Shenandoah with region sampling enabled.
Many months ago we broke backward compatibility on our branch, but we have recently restored it so the time seems right for a PR. Thank you for looking and sorry for the massive number of changes.

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

Commit messages:
 - Fix whitespace errors detected by jcheck
 - Create two test cases for the timeline paint and spotlight paint method
 - Keyboard shortcuts for controlling playback
 - Create a slider control for moving through recordings
 - Fixing the front snapshot index not adding
 - Timeline for region popup window
 - Fix speed up problem after pausing the visualizer
 - Add region detail popup window
 - Summary view (#5)
 - Fix Empty Committed on Region (#6)
 - ... and 36 more: https://git.openjdk.org/shenandoah-visualizer/compare/bc55c9c0...ab6ccb70

Changes: https://git.openjdk.org/shenandoah-visualizer/pull/1/files
 Webrev: https://webrevs.openjdk.org/?repo=shenandoah-visualizer&pr=1&range=00
  Stats: 7057 lines in 24 files changed: 6763 ins; 88 del; 206 mod
  Patch: https://git.openjdk.org/shenandoah-visualizer/pull/1.diff
  Fetch: git fetch https://git.openjdk.org/shenandoah-visualizer pull/1/head:pull/1

PR: https://git.openjdk.org/shenandoah-visualizer/pull/1

From duke at openjdk.org  Tue Aug 30 23:52:37 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 30 Aug 2022 23:52:37 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
Message-ID: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>

Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.

Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.

Testing with fastdebug build:

- [x] hotspot_loom
- [x] jdk_loom
- [x] hotspot_loom in Shenandoah IU mode
- [x] jdk_loom in Shenandoah IU mode
- [x] hotspot_loom in Shenandoah IU + aggressive
- [x] jdk_loom in Shenandoah IU + aggressive

Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

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

Commit messages:
 - 8288129: Shenandoah: Skynet test crashed with iu + aggressive

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

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

From duke at openjdk.org  Tue Aug 30 23:52:37 2022
From: duke at openjdk.org (Ashutosh Mehra)
Date: Tue, 30 Aug 2022 23:52:37 GMT
Subject: RFR: 8288129: Shenandoah: Skynet test crashed with iu + aggressive
In-Reply-To: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
References: <8TBBcirtBEjxJZVz6Zg6WDWAfQTIgYbV5EbihZcFep0=.5e1702fc-5d9a-4c90-8d6a-4009770d93ac@github.com>
Message-ID: <rDO36g3Se2r5QFl1v29RVJalNbQGOWVSWh0cKPNWTX0=.fe9c3a88-8bd5-4733-b0c0-311453678210@github.com>

On Tue, 30 Aug 2022 23:40:32 GMT, Ashutosh Mehra <duke at openjdk.org> wrote:

> Another attempt to fix the crash when running Loom with Shenandoah in iu+aggressive mode.
> 
> Explanation for the problem can be seen in https://github.com/openjdk/jdk/pull/9982#issue-1348107961 but instead of adding barriers for the oops in stack chunk header in `do_barriers()`, this fix uses Access API (`oopDesc::obj_field_put_access`) with `IS_DEST_UNINITIALIZED` decorator as suggested in https://github.com/openjdk/jdk/pull/9982#issuecomment-1231843259. The Access API invokes appropriate barriers based on the GC policy and the decorator. For SATB barriers it is a no-op. For IU mode it invokes the iu write barrier.
> 
> Testing with fastdebug build:
> 
> - [x] hotspot_loom
> - [x] jdk_loom
> - [x] hotspot_loom in Shenandoah IU mode
> - [x] jdk_loom in Shenandoah IU mode
> - [x] hotspot_loom in Shenandoah IU + aggressive
> - [x] jdk_loom in Shenandoah IU + aggressive
> 
> Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>

I got couple of intermittent failures in jdk_loom with Shenandoah IU+aggressive mode, but I reproduced the same intermittent failure without the changes as well, so probably a latent bug.

Tests that failed are:
- java/lang/management/ThreadMXBean/LockedSynchronizers.java
- java/lang/management/ThreadMXBean/MyOwnSynchronizer.java

Frequency of failure is around 1/10.

Reason for the failure is the following assertion:


# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/shenandoahBarrierSet.inline.hpp:246
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/asmehra/data/ashu-mehra/jdk/src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp:246), pid=1427500, tid=1427517
#  Error: Shenandoah assert_not_in_cset failed; Object should not be in collection set

Referenced from:
  interior location: 0x00007fc020003280
  outside of Java heap
  0x00007fc020003280 points into unknown readable memory: 0x0000000000000000 | 00 00 00 00 00 00 00 00

Object:
  0x00000000d01b6840 - klass 0x0000000800215ed8 java.util.concurrent.locks.ReentrantLock$NonfairSync
    not allocated after mark start
    not after update watermark
        marked strong
    not marked weak
        in collection set
  mark: mark(is_neutral no_hash age=0)
  region: |    6|CS |BTE     d0180000,     d01bff00,     d01c0000|TAMS     d01bff00|UWM     d01bff00|U   255K|T   255K|G     0B|S     0B|L 49040B|CP   0

Forwardee:
  (the object itself)

@fisk @rkennke if these changes look good, I will close the previous pr.

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

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