From github.com+71722661+earthling-amzn at openjdk.java.net  Thu Apr  1 00:14:35 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Thu, 1 Apr 2021 00:14:35 GMT
Subject: RFR: Clean up CondCardMark code: remove excess barriers,
 enable it by default [v2]
In-Reply-To: <IdDC0Ik6dNZwCLpJKsRk7G_4O7lez1_rX16ytHPYlvo=.9268c4ba-ac45-49d0-be61-86efbaec7300@github.com>
References: <eChq52l3NYgnnGYGx1tQ4r5WZEoGj0Dbo7E_WIXS77I=.624ef79a-2cb2-489d-a975-f689dc48156c@github.com>
 <XLIwLVwkU036BbbFC9DGHc1-CcLK_KlNRWM_AjibF-A=.679d45db-c758-4bff-90d2-d9efa700c25c@github.com>
 <IdDC0Ik6dNZwCLpJKsRk7G_4O7lez1_rX16ytHPYlvo=.9268c4ba-ac45-49d0-be61-86efbaec7300@github.com>
Message-ID: <edenGEmibQGWQMYzKMDgSrw1vWmH4BojfCjcr1rFCW4=.b6820288-ca6e-4c87-8ca0-d082a8afa0f6@github.com>

On Wed, 31 Mar 2021 23:54:27 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More cleanups of scanned_concurrently
>
> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 393:
> 
>> 391:   if (UseCondCardMark) {
>> 392:     Label L_already_dirty;
>> 393:     __ membar(Assembler::StoreLoad);
> 
> I believe this StoreStore barrier is for preventing race against concurrent refinement. Question is that, generational Shenandoah going to implement concurrent refinement in the future?

We plan to start work on concurrent remembered set scanning very soon. I'm not far enough into it yet to know if we'll need these barriers, but it looks like we might.

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

PR: https://git.openjdk.java.net/shenandoah/pull/26

From gnu.andrew at redhat.com  Thu Apr  1 03:25:04 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Thu, 1 Apr 2021 04:25:04 +0100
Subject: [RFR] [8u] 8u292-b09 Upstream Sync
Message-ID: <20210401032504.GB353026@rincewind>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/

Merge changesets:
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/corba/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/jaxp/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/jaxws/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/jdk/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/hotspot/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/langtools/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/nashorn/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/root/merge.changeset

Changes in aarch64-shenandoah-jdk8u292-b09:
  - JDK-8264171: Missing aarch64 parts of JDK-8236179 (C1 register allocation failure with T_ADDRESS)

Main issues of note:
None, clean merge.

diffstat for root
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for corba
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jaxp
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jaxws
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for langtools
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for nashorn
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jdk
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for hotspot
 b/.hgtags                                        |    1 +
 b/src/cpu/aarch64/vm/c1_FrameMap_aarch64.cpp     |    2 ++
 b/src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp |    4 ++--
 3 files changed, 5 insertions(+), 2 deletions(-)

Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
ppc64, ppc64le, aarch32 (Zero) & aarch64.

Ok to push?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Thu Apr  1 07:12:27 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 1 Apr 2021 09:12:27 +0200
Subject: [RFR] [8u] 8u292-b09 Upstream Sync
In-Reply-To: <20210401032504.GB353026@rincewind>
References: <20210401032504.GB353026@rincewind>
Message-ID: <6d01de26-1602-d6e3-092f-85a959c77156@redhat.com>

On 4/1/21 5:25 AM, Andrew Hughes wrote:
> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/
> 
> Merge changesets:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/jaxws/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/jdk/merge.changeset

Look trivially fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/hotspot/merge.changeset

Looks fine.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/root/merge.changeset

Look trivially fine.

> Ok to push?

Yes.


-- 
Thanks,
-Aleksey


From zgu at openjdk.java.net  Thu Apr  1 13:25:32 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 1 Apr 2021 13:25:32 GMT
Subject: RFR: Clean up CondCardMark code: remove excess barriers,
 enable it by default [v2]
In-Reply-To: <XLIwLVwkU036BbbFC9DGHc1-CcLK_KlNRWM_AjibF-A=.679d45db-c758-4bff-90d2-d9efa700c25c@github.com>
References: <eChq52l3NYgnnGYGx1tQ4r5WZEoGj0Dbo7E_WIXS77I=.624ef79a-2cb2-489d-a975-f689dc48156c@github.com>
 <XLIwLVwkU036BbbFC9DGHc1-CcLK_KlNRWM_AjibF-A=.679d45db-c758-4bff-90d2-d9efa700c25c@github.com>
Message-ID: <CM6OxCP0bD1F_9i4GMi4DsmqkV6Q041imn-9rtmIetg=.b914b018-dae0-4c37-805d-12dfbd5bda4b@github.com>

On Wed, 31 Mar 2021 14:24:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The `StoreLoad`, `StoreStore` barriers in that code are only needed for CMS, and does not relate to Shenandoah. Also, `UseCondCardMark` is a recommended option for most machines today, and therefore we better just enable it ergonomically.
>> 
>> Additional testing:
>>  - [x] hotspot_gc_shenandoah, x86_64, {fastdebug,release}
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More cleanups of scanned_concurrently

Looks goodf

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

Marked as reviewed by zgu (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/26

From shade at openjdk.java.net  Thu Apr  1 16:10:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 1 Apr 2021 16:10:38 GMT
Subject: RFR: Clean up CondCardMark code: remove excess barriers,
 enable it by default [v2]
In-Reply-To: <edenGEmibQGWQMYzKMDgSrw1vWmH4BojfCjcr1rFCW4=.b6820288-ca6e-4c87-8ca0-d082a8afa0f6@github.com>
References: <eChq52l3NYgnnGYGx1tQ4r5WZEoGj0Dbo7E_WIXS77I=.624ef79a-2cb2-489d-a975-f689dc48156c@github.com>
 <XLIwLVwkU036BbbFC9DGHc1-CcLK_KlNRWM_AjibF-A=.679d45db-c758-4bff-90d2-d9efa700c25c@github.com>
 <IdDC0Ik6dNZwCLpJKsRk7G_4O7lez1_rX16ytHPYlvo=.9268c4ba-ac45-49d0-be61-86efbaec7300@github.com>
 <edenGEmibQGWQMYzKMDgSrw1vWmH4BojfCjcr1rFCW4=.b6820288-ca6e-4c87-8ca0-d082a8afa0f6@github.com>
Message-ID: <ECzTEO-H0cA996KT4rBnU3J--hFU3p9XgFyenE_fNTQ=.3e97cdd2-1f4e-4f61-bf94-3b5c0e29de37@github.com>

On Thu, 1 Apr 2021 00:11:16 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 393:
>> 
>>> 391:   if (UseCondCardMark) {
>>> 392:     Label L_already_dirty;
>>> 393:     __ membar(Assembler::StoreLoad);
>> 
>> I believe this StoreStore barrier is for preventing race against concurrent refinement. Question is that, generational Shenandoah going to implement concurrent refinement in the future?
>
> We plan to start work on concurrent remembered set scanning very soon. I'm not far enough into it yet to know if we'll need these barriers, but it looks like we might.

Either way, this thing is gone with https://bugs.openjdk.java.net/browse/JDK-8261309 -- and it was needed for CMS. I would prefer to drop it to match upstream, and then reintroduce the barriers iff they are needed.

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

PR: https://git.openjdk.java.net/shenandoah/pull/26

From github.com+71722661+earthling-amzn at openjdk.java.net  Thu Apr  1 17:15:34 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Thu, 1 Apr 2021 17:15:34 GMT
Subject: RFR: Clean up CondCardMark code: remove excess barriers,
 enable it by default [v2]
In-Reply-To: <ECzTEO-H0cA996KT4rBnU3J--hFU3p9XgFyenE_fNTQ=.3e97cdd2-1f4e-4f61-bf94-3b5c0e29de37@github.com>
References: <eChq52l3NYgnnGYGx1tQ4r5WZEoGj0Dbo7E_WIXS77I=.624ef79a-2cb2-489d-a975-f689dc48156c@github.com>
 <XLIwLVwkU036BbbFC9DGHc1-CcLK_KlNRWM_AjibF-A=.679d45db-c758-4bff-90d2-d9efa700c25c@github.com>
 <IdDC0Ik6dNZwCLpJKsRk7G_4O7lez1_rX16ytHPYlvo=.9268c4ba-ac45-49d0-be61-86efbaec7300@github.com>
 <edenGEmibQGWQMYzKMDgSrw1vWmH4BojfCjcr1rFCW4=.b6820288-ca6e-4c87-8ca0-d082a8afa0f6@github.com>
 <ECzTEO-H0cA996KT4rBnU3J--hFU3p9XgFyenE_fNTQ=.3e97cdd2-1f4e-4f61-bf94-3b5c0e29de37@github.com>
Message-ID: <9brUQr90RP8mYoQvOGSTiBakie18LK9BawcEfbWhu2Y=.f3e5888d-3faf-4a17-b548-5d451fcde303@github.com>

On Thu, 1 Apr 2021 16:07:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> We plan to start work on concurrent remembered set scanning very soon. I'm not far enough into it yet to know if we'll need these barriers, but it looks like we might.
>
> Either way, this thing is gone with https://bugs.openjdk.java.net/browse/JDK-8261309 -- and it was needed for CMS. I would prefer to drop it to match upstream, and then reintroduce the barriers iff they are needed.

I agree, thanks for the link and the background on the change.

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

PR: https://git.openjdk.java.net/shenandoah/pull/26

From gnu.andrew at redhat.com  Fri Apr  2 02:44:41 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Fri, 2 Apr 2021 03:44:41 +0100
Subject: [RFR] [8u] 8u292-b09 Upstream Sync
In-Reply-To: <6d01de26-1602-d6e3-092f-85a959c77156@redhat.com>
References: <20210401032504.GB353026@rincewind>
 <6d01de26-1602-d6e3-092f-85a959c77156@redhat.com>
Message-ID: <20210402024441.GA442813@rincewind>

On 09:12 Thu 01 Apr     , Aleksey Shipilev wrote:
> On 4/1/21 5:25 AM, Andrew Hughes wrote:
> > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/
> > 
> > Merge changesets:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/jaxws/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/jdk/merge.changeset
> 
> Look trivially fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/hotspot/merge.changeset
> 
> Looks fine.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b09/root/merge.changeset
> 
> Look trivially fine.
> 
> > Ok to push?
> 
> Yes.
> 
> 
> -- 
> Thanks,
> -Aleksey
> 

Thanks. Pushed.
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at openjdk.java.net  Fri Apr  2 07:11:42 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 2 Apr 2021 07:11:42 GMT
Subject: Integrated: Clean up CondCardMark code: remove excess barriers,
 enable it by default
In-Reply-To: <eChq52l3NYgnnGYGx1tQ4r5WZEoGj0Dbo7E_WIXS77I=.624ef79a-2cb2-489d-a975-f689dc48156c@github.com>
References: <eChq52l3NYgnnGYGx1tQ4r5WZEoGj0Dbo7E_WIXS77I=.624ef79a-2cb2-489d-a975-f689dc48156c@github.com>
Message-ID: <yUN8NgaiD0EzBSZaV-WaXrYs8IaOzrmAy5QOxkud08U=.d1b23adc-57b9-4743-89ef-f930b72da3dd@github.com>

On Wed, 31 Mar 2021 13:34:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The `StoreLoad`, `StoreStore` barriers in that code are only needed for CMS, and does not relate to Shenandoah. Also, `UseCondCardMark` is a recommended option for most machines today, and therefore we better just enable it ergonomically.
> 
> Additional testing:
>  - [x] hotspot_gc_shenandoah, x86_64, {fastdebug,release}

This pull request has now been integrated.

Changeset: d6b1c3f0
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/d6b1c3f0
Stats:     35 lines in 6 files changed: 3 ins; 30 del; 2 mod

Clean up CondCardMark code: remove excess barriers, enable it by default

Reviewed-by: zgu

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

PR: https://git.openjdk.java.net/shenandoah/pull/26

From github.com+71722661+earthling-amzn at openjdk.java.net  Fri Apr  2 17:33:59 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Fri, 2 Apr 2021 17:33:59 GMT
Subject: RFR: Add parallel worker timings for remembered set scan
Message-ID: <ERMKBsr6YNMg7eZEqZrtDSfWK0WRbNmXaCTjTTQ2ce8=.7609af48-f4ba-4ca2-81cd-304364334cca@github.com>

### Description
Followed the existing pattern to add parallel working timings for remembered set scan.

### Testing
Ran Dacapo, looks like this in the logs:
[157.867s][202297][info] Concurrent Reset                  94013 us
[157.867s][202297][info] Pause Init Mark (G)              579650 us
[157.867s][202297][info] Pause Init Mark (N)              579456 us
[157.867s][202297][info]   Scan Remembered Set            483166 us, parallelism: 3.91x
[157.867s][202297][info]     RS: <total>                 1891580 us
[157.867s][202297][info]     RS: Scan Clusters           1891580 us, workers (us): 481972, 468615, 457912, 483081, 
[157.867s][202297][info]   Update Region States               78 us
[157.867s][202297][info] Concurrent Mark Roots             18932 us, parallelism: 1.98x

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

Commit messages:
 - Add parallel worker timings for remembered set scan

Changes: https://git.openjdk.java.net/shenandoah/pull/27/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=27&range=00
  Stats: 10 lines in 4 files changed: 6 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/27/head:pull/27

PR: https://git.openjdk.java.net/shenandoah/pull/27

From shade at openjdk.java.net  Sat Apr  3 06:34:41 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Sat, 3 Apr 2021 06:34:41 GMT
Subject: RFR: Add parallel worker timings for remembered set scan
In-Reply-To: <ERMKBsr6YNMg7eZEqZrtDSfWK0WRbNmXaCTjTTQ2ce8=.7609af48-f4ba-4ca2-81cd-304364334cca@github.com>
References: <ERMKBsr6YNMg7eZEqZrtDSfWK0WRbNmXaCTjTTQ2ce8=.7609af48-f4ba-4ca2-81cd-304364334cca@github.com>
Message-ID: <zz3j6XyaufkFgl2RMYNze19dd1_7_Hu24dZsflek9Xs=.0e2abccc-fc42-47f1-b360-3d6adb69ab03@github.com>

On Fri, 2 Apr 2021 17:27:41 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> ### Description
> Followed the existing pattern to add parallel working timings for remembered set scan.
> 
> ### Testing
> Ran Dacapo, looks like this in the logs:
> [157.867s][202297][info] Concurrent Reset                  94013 us
> [157.867s][202297][info] Pause Init Mark (G)              579650 us
> [157.867s][202297][info] Pause Init Mark (N)              579456 us
> [157.867s][202297][info]   Scan Remembered Set            483166 us, parallelism: 3.91x
> [157.867s][202297][info]     RS: <total>                 1891580 us
> [157.867s][202297][info]     RS: Scan Clusters           1891580 us, workers (us): 481972, 468615, 457912, 483081, 
> [157.867s][202297][info]   Update Region States               78 us
> [157.867s][202297][info] Concurrent Mark Roots             18932 us, parallelism: 1.98x

This looks good. Consider fixing minor nits.

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

> 104:                                                                                        \
> 105:   f(init_update_refs_gross,                         "Pause Init Update Refs (G)")      \
> 106:   f(init_update_refs,                               "Pause Init Update Refs (N)")      \

Revert this change, we should clean this up upstream.

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

> 101:   ShenandoahObjToScanQueue* old = _old_queue_set == NULL ? NULL : _old_queue_set->queue(worker_id);
> 102:   ShenandoahMarkRefsClosure<YOUNG> cl(q, _rp, old);
> 103:   RememberedScanner *scanner = ShenandoahHeap::heap()->card_scan();

While you are at it, can you put `*` to lean to the type? `RememberedScanner* scanner`.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/27

From github.com+71722661+earthling-amzn at openjdk.java.net  Mon Apr  5 16:36:55 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Mon, 5 Apr 2021 16:36:55 GMT
Subject: RFR: Add parallel worker timings for remembered set scan [v2]
In-Reply-To: <ERMKBsr6YNMg7eZEqZrtDSfWK0WRbNmXaCTjTTQ2ce8=.7609af48-f4ba-4ca2-81cd-304364334cca@github.com>
References: <ERMKBsr6YNMg7eZEqZrtDSfWK0WRbNmXaCTjTTQ2ce8=.7609af48-f4ba-4ca2-81cd-304364334cca@github.com>
Message-ID: <2yvcNa9iSlKVZR6YkCUxUrCgkm2i1XsnyI5ij08-geI=.d89b1493-1a69-4af0-9e2a-81baad84fe49@github.com>

> ### Description
> Followed the existing pattern to add parallel working timings for remembered set scan.
> 
> ### Testing
> Ran Dacapo, looks like this in the logs:
> [157.867s][202297][info] Concurrent Reset                  94013 us
> [157.867s][202297][info] Pause Init Mark (G)              579650 us
> [157.867s][202297][info] Pause Init Mark (N)              579456 us
> [157.867s][202297][info]   Scan Remembered Set            483166 us, parallelism: 3.91x
> [157.867s][202297][info]     RS: <total>                 1891580 us
> [157.867s][202297][info]     RS: Scan Clusters           1891580 us, workers (us): 481972, 468615, 457912, 483081, 
> [157.867s][202297][info]   Update Region States               78 us
> [157.867s][202297][info] Concurrent Mark Roots             18932 us, parallelism: 1.98x

earthling-amzn has updated the pull request incrementally with two additional commits since the last revision:

 - Align '*' to type, not variable
 - Revert unrelated whitespace change.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/27/files
  - new: https://git.openjdk.java.net/shenandoah/pull/27/files/9cc042c8..123c59ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=27&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=27&range=00-01

  Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/27.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/27/head:pull/27

PR: https://git.openjdk.java.net/shenandoah/pull/27

From github.com+71722661+earthling-amzn at openjdk.java.net  Mon Apr  5 16:49:32 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Mon, 5 Apr 2021 16:49:32 GMT
Subject: RFR: Add parallel worker timings for remembered set scan [v2]
In-Reply-To: <zz3j6XyaufkFgl2RMYNze19dd1_7_Hu24dZsflek9Xs=.0e2abccc-fc42-47f1-b360-3d6adb69ab03@github.com>
References: <ERMKBsr6YNMg7eZEqZrtDSfWK0WRbNmXaCTjTTQ2ce8=.7609af48-f4ba-4ca2-81cd-304364334cca@github.com>
 <zz3j6XyaufkFgl2RMYNze19dd1_7_Hu24dZsflek9Xs=.0e2abccc-fc42-47f1-b360-3d6adb69ab03@github.com>
Message-ID: <_CA8fnjYSleO-JUJcoqJ16-b7eNqNimwAE47xjZmL78=.64a9e063-3ddf-4a49-8d4c-63c792a311df@github.com>

On Sat, 3 Apr 2021 06:30:30 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> earthling-amzn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Align '*' to type, not variable
>>  - Revert unrelated whitespace change.
>
> src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp line 106:
> 
>> 104:                                                                                        \
>> 105:   f(init_update_refs_gross,                         "Pause Init Update Refs (G)")      \
>> 106:   f(init_update_refs,                               "Pause Init Update Refs (N)")      \
> 
> Revert this change, we should clean this up upstream.

Created a pull request for this: https://github.com/openjdk/jdk/pull/3342

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

PR: https://git.openjdk.java.net/shenandoah/pull/27

From shade at openjdk.java.net  Mon Apr  5 16:50:29 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 5 Apr 2021 16:50:29 GMT
Subject: git: openjdk/shenandoah: master: Add parallel worker timings for
 remembered set scan
Message-ID: <900a854e-2fe6-4f9f-9fcd-b2a514959936@openjdk.org>

Changeset: bad8e744
Author:    William Kemper <kemperw at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-04-05 16:50:11 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/bad8e744

Add parallel worker timings for remembered set scan

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.cpp
! src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp
! src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.cpp


From github.com+71722661+earthling-amzn at openjdk.java.net  Mon Apr  5 16:53:34 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Mon, 5 Apr 2021 16:53:34 GMT
Subject: Integrated: Add parallel worker timings for remembered set scan
In-Reply-To: <ERMKBsr6YNMg7eZEqZrtDSfWK0WRbNmXaCTjTTQ2ce8=.7609af48-f4ba-4ca2-81cd-304364334cca@github.com>
References: <ERMKBsr6YNMg7eZEqZrtDSfWK0WRbNmXaCTjTTQ2ce8=.7609af48-f4ba-4ca2-81cd-304364334cca@github.com>
Message-ID: <tRBP8I_1lxqNSL-kZWw7HrBrqVyGXIqMHuMk5sI2X18=.7d53bbcf-23d5-4c4b-a6ec-552defce9c0a@github.com>

On Fri, 2 Apr 2021 17:27:41 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> ### Description
> Followed the existing pattern to add parallel working timings for remembered set scan.
> 
> ### Testing
> Ran Dacapo, looks like this in the logs:
> [157.867s][202297][info] Concurrent Reset                  94013 us
> [157.867s][202297][info] Pause Init Mark (G)              579650 us
> [157.867s][202297][info] Pause Init Mark (N)              579456 us
> [157.867s][202297][info]   Scan Remembered Set            483166 us, parallelism: 3.91x
> [157.867s][202297][info]     RS: <total>                 1891580 us
> [157.867s][202297][info]     RS: Scan Clusters           1891580 us, workers (us): 481972, 468615, 457912, 483081, 
> [157.867s][202297][info]   Update Region States               78 us
> [157.867s][202297][info] Concurrent Mark Roots             18932 us, parallelism: 1.98x

This pull request has now been integrated.

Changeset: bad8e744
Author:    William Kemper <kemperw at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/bad8e744
Stats:     14 lines in 4 files changed: 6 ins; 0 del; 8 mod

Add parallel worker timings for remembered set scan

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/shenandoah/pull/27

From shade at openjdk.java.net  Mon Apr  5 17:00:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 5 Apr 2021 17:00:45 GMT
Subject: RFR: 8264727: Remove extraneous whitespace from phase timings
 report
In-Reply-To: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
References: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
Message-ID: <Hli56K3eFzQFVCcoT9pYOSImzTmREl60BUvthLxi5Q0=.fa136339-c688-4e8c-9ce3-eb83d8fee1d3@github.com>

On Mon, 5 Apr 2021 16:45:43 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> This extra space doesn't look like it was intended to improve any alignment of text in the report.

Marked as reviewed by shade (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3342

From github.com+71722661+earthling-amzn at openjdk.java.net  Mon Apr  5 17:00:44 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Mon, 5 Apr 2021 17:00:44 GMT
Subject: RFR: 8264727: Remove extraneous whitespace from phase timings report
Message-ID: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>

This extra space doesn't look like it was intended to improve any alignment of text in the report.

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

Commit messages:
 - Remove extraneous whitespace from phase timings report

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

PR: https://git.openjdk.java.net/jdk/pull/3342

From shade at openjdk.java.net  Mon Apr  5 17:00:45 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 5 Apr 2021 17:00:45 GMT
Subject: RFR: 8264727: Remove extraneous whitespace from phase timings
 report
In-Reply-To: <Hli56K3eFzQFVCcoT9pYOSImzTmREl60BUvthLxi5Q0=.fa136339-c688-4e8c-9ce3-eb83d8fee1d3@github.com>
References: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
 <Hli56K3eFzQFVCcoT9pYOSImzTmREl60BUvthLxi5Q0=.fa136339-c688-4e8c-9ce3-eb83d8fee1d3@github.com>
Message-ID: <iXDLSf8aMdIHUnehUVixP_dE18nJvRwGJbwA6QIA_BI=.d5a0222a-dd8d-41b4-9516-2ddb87478849@github.com>

On Mon, 5 Apr 2021 16:49:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This extra space doesn't look like it was intended to improve any alignment of text in the report.
>
> Marked as reviewed by shade (Reviewer).

Created: https://bugs.openjdk.java.net/browse/JDK-8264727 -- rename this PR to "8264727: Shenandoah: Remove extraneous whitespace from phase timings report" to get it hooked up.

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

PR: https://git.openjdk.java.net/jdk/pull/3342

From shade at openjdk.java.net  Mon Apr  5 17:06:13 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 5 Apr 2021 17:06:13 GMT
Subject: RFR: 8264727: Remove extraneous whitespace from phase timings
 report
In-Reply-To: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
References: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
Message-ID: <vrtgAY7fjObozUJ1jNa5GScsAnwouFUUe0WBXxqAaWM=.d529c9bd-9c06-4d93-beea-762dd64ad5d5@github.com>

On Mon, 5 Apr 2021 16:45:43 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> This extra space doesn't look like it was intended to improve any alignment of text in the report.

Looks fine and trivial.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3342

From zgu at openjdk.java.net  Mon Apr  5 21:50:49 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 5 Apr 2021 21:50:49 GMT
Subject: RFR: 8264718: Shenandoah: enable string deduplication during root
 scanning
Message-ID: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>

Shenandoah used to scan roots at pauses, so it deliberately disables string deduplication during root scanning to avoid extra pause times.

Now, Shenandoah scans roots in concurrent phase, it is no longer a concern, we should enable it.

Test:
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - Merge branch 'master' into enable_dedup_roots
 - init

Changes: https://git.openjdk.java.net/jdk/pull/3348/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3348&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264718
  Stats: 69 lines in 5 files changed: 40 ins; 25 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3348.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3348/head:pull/3348

PR: https://git.openjdk.java.net/jdk/pull/3348

From shade at openjdk.java.net  Tue Apr  6 06:40:28 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Apr 2021 06:40:28 GMT
Subject: RFR: 8264727: Remove extraneous whitespace from phase timings
 report
In-Reply-To: <vrtgAY7fjObozUJ1jNa5GScsAnwouFUUe0WBXxqAaWM=.d529c9bd-9c06-4d93-beea-762dd64ad5d5@github.com>
References: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
 <vrtgAY7fjObozUJ1jNa5GScsAnwouFUUe0WBXxqAaWM=.d529c9bd-9c06-4d93-beea-762dd64ad5d5@github.com>
Message-ID: <eI-kxZmXReFlh5U6MUWCOt9GbUFa4oz6zn0-7kWFujM=.24d9539d-7ce0-4d84-807a-7d4c2df43f57@github.com>

On Mon, 5 Apr 2021 17:02:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> This extra space doesn't look like it was intended to improve any alignment of text in the report.
>
> Looks fine and trivial.

You need to resolve the integration blocker before integration: the PR title and bug synopsis are mismatched. You need "Shenandoah: " in the title.

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

PR: https://git.openjdk.java.net/jdk/pull/3342

From github.com+71722661+earthling-amzn at openjdk.java.net  Tue Apr  6 18:49:51 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Tue, 6 Apr 2021 18:49:51 GMT
Subject: RFR: Use timed wait to sleep control thread
Message-ID: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>

Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.

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

Commit messages:
 - Use timed wait to sleep control thread

Changes: https://git.openjdk.java.net/shenandoah/pull/28/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=28&range=00
  Stats: 17 lines in 2 files changed: 12 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/28.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/28/head:pull/28

PR: https://git.openjdk.java.net/shenandoah/pull/28

From github.com+25214855+casparcwang at openjdk.java.net  Wed Apr  7 08:03:27 2021
From: github.com+25214855+casparcwang at openjdk.java.net (=?UTF-8?B?546L6LaF?=)
Date: Wed, 7 Apr 2021 08:03:27 GMT
Subject: RFR: 8264718: Shenandoah: enable string deduplication during root
 scanning
In-Reply-To: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>
References: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>
Message-ID: <0XUFNDhmkB4OgUxbtnadAcg9daAjdppc0VlVWJMZVPI=.69dcbac1-bbbd-45ba-97ac-2ad8b5c18d52@github.com>

On Mon, 5 Apr 2021 21:42:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah used to scan roots at pauses, so it deliberately disables string deduplication during root scanning to avoid extra pause times.
> 
> Now, Shenandoah scans roots in concurrent phase, it is no longer a concern, we should enable it.
> 
> Test:
> - [x] hotspot_gc_shenandoah

src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 134:

> 132:     ShenandoahInitMarkRootsClosure<ENQUEUE_DEDUP>  init_mark(task_queues()->queue(worker_id));
> 133:     _root_scanner.roots_do(&init_mark, worker_id);
> 134: 

extra empty line

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

PR: https://git.openjdk.java.net/jdk/pull/3348

From rkennke at redhat.com  Wed Apr  7 09:28:16 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Wed, 7 Apr 2021 11:28:16 +0200
Subject: Result: New Shenandoah committer: William Kemper
Message-ID: <aaa38d3f-f4c1-9f4f-c346-bd4043766e81@redhat.com>

Voting for William Kemper [1] is now closed.

Yes: 2
Veto: 0
Abstain: 0

According to the Bylaws definition of Lazy Consensus, this is
sufficient to approve the nomination.

Roman Kennke

[1] 
https://mail.openjdk.java.net/pipermail/shenandoah-dev/2021-March/015043.html


From zgu at openjdk.java.net  Wed Apr  7 12:11:18 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 7 Apr 2021 12:11:18 GMT
Subject: RFR: 8264718: Shenandoah: enable string deduplication during root
 scanning [v2]
In-Reply-To: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>
References: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>
Message-ID: <Lt_Zin0WIrf-d8Ah8KX2l-iEYN0XySOEWV7zLE3_gUk=.79266dfd-9797-4018-b237-7099f6dca55b@github.com>

> Shenandoah used to scan roots at pauses, so it deliberately disables string deduplication during root scanning to avoid extra pause times.
> 
> Now, Shenandoah scans roots in concurrent phase, it is no longer a concern, we should enable it.
> 
> Test:
> - [x] hotspot_gc_shenandoah

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

  Removed excessive empty lines

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3348/files
  - new: https://git.openjdk.java.net/jdk/pull/3348/files/45344ee4..d3d63b38

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3348&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3348&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/3348

From rkennke at openjdk.java.net  Wed Apr  7 16:22:55 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 7 Apr 2021 16:22:55 GMT
Subject: RFR: Use timed wait to sleep control thread
In-Reply-To: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
Message-ID: <o1Fxj12mUDodhW95f-BUw-Zv9LlgtWPnkri-VxZfQ3Q=.3e2b85ab-8b2c-4815-bfde-2a96d1aafcb8@github.com>

On Tue, 6 Apr 2021 18:44:02 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.

This looks like something that @shipilev has touched a few times before.

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From shade at openjdk.java.net  Wed Apr  7 16:28:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Apr 2021 16:28:36 GMT
Subject: RFR: 8264718: Shenandoah: enable string deduplication during root
 scanning [v2]
In-Reply-To: <Lt_Zin0WIrf-d8Ah8KX2l-iEYN0XySOEWV7zLE3_gUk=.79266dfd-9797-4018-b237-7099f6dca55b@github.com>
References: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>
 <Lt_Zin0WIrf-d8Ah8KX2l-iEYN0XySOEWV7zLE3_gUk=.79266dfd-9797-4018-b237-7099f6dca55b@github.com>
Message-ID: <iW8-GHgZifSjUCqSY-6H2195IaZQcnfX3eC1fVLxWqM=.f34529ec-a081-48a7-b248-dfa7623c0ce2@github.com>

On Wed, 7 Apr 2021 12:11:18 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Shenandoah used to scan roots at pauses, so it deliberately disables string deduplication during root scanning to avoid extra pause times.
>> 
>> Now, Shenandoah scans roots in concurrent phase, it is no longer a concern, we should enable it.
>> 
>> Test:
>> - [x] hotspot_gc_shenandoah
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed excessive empty lines

Looks fine, with a minor nit. Fix it before push.

src/hotspot/share/gc/shenandoah/shenandoahSTWMark.cpp line 132:

> 130: void ShenandoahSTWMark::mark_roots(uint worker_id) {
> 131:   if (ShenandoahStringDedup::is_enabled()) {
> 132:     ShenandoahInitMarkRootsClosure<ENQUEUE_DEDUP>  init_mark(task_queues()->queue(worker_id));

Excess space here and on the other branch, between `<ENQUEUE_DEDUP>` and `init_mark`.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3348

From shade at openjdk.java.net  Wed Apr  7 16:35:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Apr 2021 16:35:52 GMT
Subject: RFR: Use timed wait to sleep control thread
In-Reply-To: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
Message-ID: <tI7B3OltNlb8stTM7z9hOxaxm_c0ychR_Cxsh4ltnfk=.b2272218-5b86-46f4-be66-9b3b8511bfe2@github.com>

On Tue, 6 Apr 2021 18:44:02 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.

I don't mind this going into sandbox, but honestly, we need to fix it in the mainline. The awkwardness of control loop sleep-looping gets very tedious.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/28

From shade at openjdk.java.net  Wed Apr  7 17:12:37 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Apr 2021 17:12:37 GMT
Subject: RFR: Use timed wait to sleep control thread
In-Reply-To: <tI7B3OltNlb8stTM7z9hOxaxm_c0ychR_Cxsh4ltnfk=.b2272218-5b86-46f4-be66-9b3b8511bfe2@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <tI7B3OltNlb8stTM7z9hOxaxm_c0ychR_Cxsh4ltnfk=.b2272218-5b86-46f4-be66-9b3b8511bfe2@github.com>
Message-ID: <WbPNPLrBM3ChYIMbVe3jSBCQ2oiq4QI0VbaiJBmeqkM=.90729f74-99ee-466c-bc0f-bdd9f17c93fa@github.com>

On Wed, 7 Apr 2021 16:32:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.
>
> I don't mind this going into sandbox, but honestly, we need to fix it in the mainline. The awkwardness of control loop sleep-looping gets very tedious.

I shall try and do this in mainline with this: https://bugs.openjdk.java.net/browse/JDK-8264851 -- probably next week, though.

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From shade at openjdk.java.net  Wed Apr  7 17:24:56 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 7 Apr 2021 17:24:56 GMT
Subject: RFR: Use timed wait to sleep control thread
In-Reply-To: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
Message-ID: <l3rzYdBVZU4CTFNuip4ylNtG5KMrAkgmdu0C2-dYorQ=.620646f5-1cd5-4b18-9506-8efde29e5f9c@github.com>

On Tue, 6 Apr 2021 18:44:02 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.

Oh wait, questions...

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 374:

> 372:       // The timed wait is necessary because this thread has a responsibility to send
> 373:       // 'alloc_words' to the pacer when it does not perform a GC.
> 374:       MonitorLocker lock(&_control_lock, Mutex::SafepointCheckFlag::_no_safepoint_check_flag);

This is just `Mutex::_no_safepoint_check_flag`, Hotspot uses that everywhere. Another instance in also in the same file.

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 768:

> 766:     _gc_requested.set();
> 767:     _requested_gc_cause = cause;
> 768:     notify_control_thread();

So this thing holds `_gc_waiters_lock`. I noticed it when trying to implement JDK-8264851. Fastdebug builds would fail with: `#  assert(false) failed: Attempting to acquire lock ShenandoahControlWaitGC_lock/11 out of order with lock ShenandoahRequestedGC_lock/11 -- possible deadlock`. How is that handled here?

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From zgu at openjdk.java.net  Wed Apr  7 17:25:09 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 7 Apr 2021 17:25:09 GMT
Subject: RFR: 8264718: Shenandoah: enable string deduplication during root
 scanning [v3]
In-Reply-To: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>
References: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>
Message-ID: <qQbcb-90KpjbQNg7cju4tUTRDuut1z_TRo0tP9Nrbpg=.785b7b32-7cb0-4b31-affe-9f9b72185e87@github.com>

> Shenandoah used to scan roots at pauses, so it deliberately disables string deduplication during root scanning to avoid extra pause times.
> 
> Now, Shenandoah scans roots in concurrent phase, it is no longer a concern, we should enable it.
> 
> Test:
> - [x] hotspot_gc_shenandoah

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

  Removed excess spaces

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3348/files
  - new: https://git.openjdk.java.net/jdk/pull/3348/files/d3d63b38..33862ac2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3348&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3348&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/3348

From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr  7 18:14:54 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 7 Apr 2021 18:14:54 GMT
Subject: RFR: Use timed wait to sleep control thread
In-Reply-To: <l3rzYdBVZU4CTFNuip4ylNtG5KMrAkgmdu0C2-dYorQ=.620646f5-1cd5-4b18-9506-8efde29e5f9c@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <l3rzYdBVZU4CTFNuip4ylNtG5KMrAkgmdu0C2-dYorQ=.620646f5-1cd5-4b18-9506-8efde29e5f9c@github.com>
Message-ID: <WRchwMWkjoJ83EEZksT2BdNNl5qw9vNN05ayHi2l5iQ=.2eb59db7-7482-4ac9-8eca-71ec8341fed0@github.com>

On Wed, 7 Apr 2021 17:20:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.
>
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 374:
> 
>> 372:       // The timed wait is necessary because this thread has a responsibility to send
>> 373:       // 'alloc_words' to the pacer when it does not perform a GC.
>> 374:       MonitorLocker lock(&_control_lock, Mutex::SafepointCheckFlag::_no_safepoint_check_flag);
> 
> This is just `Mutex::_no_safepoint_check_flag`, Hotspot uses that everywhere. Another instance in also in the same file.

Sorry, my IDE does this. Fixed.

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr  7 18:18:45 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 7 Apr 2021 18:18:45 GMT
Subject: RFR: Use timed wait to sleep control thread
In-Reply-To: <l3rzYdBVZU4CTFNuip4ylNtG5KMrAkgmdu0C2-dYorQ=.620646f5-1cd5-4b18-9506-8efde29e5f9c@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <l3rzYdBVZU4CTFNuip4ylNtG5KMrAkgmdu0C2-dYorQ=.620646f5-1cd5-4b18-9506-8efde29e5f9c@github.com>
Message-ID: <dLXUK6Inc9IfUf6qIO8K2VMzvB2UNpqOl7dttLblNLM=.e2b0c668-9e1f-4b5d-982c-54b8341b6a21@github.com>

On Wed, 7 Apr 2021 17:22:05 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.
>
> Oh wait, questions...

I'm not sure we can fix this so easily on mainline. The control thread on mainline needs to periodically evaluate the heuristics. To support the generational changes, heuristic evaluation was moved to a separate thread (so that it can initiate a young collection while the control thread is busy handling an old collection).

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr  7 18:49:59 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 7 Apr 2021 18:49:59 GMT
Subject: RFR: Use timed wait to sleep control thread
In-Reply-To: <l3rzYdBVZU4CTFNuip4ylNtG5KMrAkgmdu0C2-dYorQ=.620646f5-1cd5-4b18-9506-8efde29e5f9c@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <l3rzYdBVZU4CTFNuip4ylNtG5KMrAkgmdu0C2-dYorQ=.620646f5-1cd5-4b18-9506-8efde29e5f9c@github.com>
Message-ID: <pJ4DgM4qX-AoZdXhZAQ4zUsGvwbPei5kkGcK844sZBs=.97bae674-b96c-43da-92c9-66eeaa8e8408@github.com>

On Wed, 7 Apr 2021 17:21:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.
>
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 768:
> 
>> 766:     _gc_requested.set();
>> 767:     _requested_gc_cause = cause;
>> 768:     notify_control_thread();
> 
> So this thing holds `_gc_waiters_lock`. I noticed it when trying to implement JDK-8264851. Fastdebug builds would fail with: `#  assert(false) failed: Attempting to acquire lock ShenandoahControlWaitGC_lock/11 out of order with lock ShenandoahRequestedGC_lock/11 -- possible deadlock`. How is that handled here?

Looking into this.

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr  7 20:31:09 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 7 Apr 2021 20:31:09 GMT
Subject: RFR: Use timed wait to sleep control thread [v2]
In-Reply-To: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
Message-ID: <LQ-dFdM5K688Oji8vMntuOV_hvgyZXppDYOWQQDloHg=.f000069e-80b7-4c96-98df-8e8774e11117@github.com>

> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.

earthling-amzn has updated the pull request incrementally with two additional commits since the last revision:

 - Increase mutex rank of gc waiters
   
   This lets us take the control thread's lock to notify it without tripping the deadlock detector.
 - Remove unnecessary enum namespace

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/28/files
  - new: https://git.openjdk.java.net/shenandoah/pull/28/files/69650c28..f4b50907

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=28&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=28&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/28.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/28/head:pull/28

PR: https://git.openjdk.java.net/shenandoah/pull/28

From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr  7 20:31:10 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 7 Apr 2021 20:31:10 GMT
Subject: RFR: Use timed wait to sleep control thread [v2]
In-Reply-To: <pJ4DgM4qX-AoZdXhZAQ4zUsGvwbPei5kkGcK844sZBs=.97bae674-b96c-43da-92c9-66eeaa8e8408@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <l3rzYdBVZU4CTFNuip4ylNtG5KMrAkgmdu0C2-dYorQ=.620646f5-1cd5-4b18-9506-8efde29e5f9c@github.com>
 <pJ4DgM4qX-AoZdXhZAQ4zUsGvwbPei5kkGcK844sZBs=.97bae674-b96c-43da-92c9-66eeaa8e8408@github.com>
Message-ID: <v6xwSJgijpwaFrInjb8b8tBIyE2SX_oUBv-al5kQyAs=.51d6aa94-0430-4e0c-af73-8663c998a029@github.com>

On Wed, 7 Apr 2021 18:47:03 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 768:
>> 
>>> 766:     _gc_requested.set();
>>> 767:     _requested_gc_cause = cause;
>>> 768:     notify_control_thread();
>> 
>> So this thing holds `_gc_waiters_lock`. I noticed it when trying to implement JDK-8264851. Fastdebug builds would fail with: `#  assert(false) failed: Attempting to acquire lock ShenandoahControlWaitGC_lock/11 out of order with lock ShenandoahRequestedGC_lock/11 -- possible deadlock`. How is that handled here?
>
> Looking into this.

I think this is a false positive. There's no deadlock here because the control thread never tries to hold both these locks at the same time. I changed the rank of the `_gc_waiters_lock` to allow a thread to hold them both.

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr  7 20:32:39 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 7 Apr 2021 20:32:39 GMT
Subject: RFR: Refix ShenandoahPurgeSATBTask
In-Reply-To: <IO94NU252dcTJhXUKhYHr2MoHV5i82mQ2kuOSDWi5Dk=.46701d26-75b6-4c12-8976-271b8ea5e482@github.com>
References: <CfwhM_ZK93mjjWuZNRdpOsBCCmahsemo05XRsWwa9AM=.69ec4bdc-d449-489b-a725-569bc002a525@github.com>
 <wDsmCUqHdidwuVQZ7dkeHhBZNFkgAvAJ7f9NrenSMHE=.5135de25-0acc-46e3-8cd6-81b9c80203eb@github.com>
 <IO94NU252dcTJhXUKhYHr2MoHV5i82mQ2kuOSDWi5Dk=.46701d26-75b6-4c12-8976-271b8ea5e482@github.com>
Message-ID: <UqlzIymRSosra0OOtKpIgLNNqixoweD4eDvRfH6T_3s=.c687601e-c617-4792-9a22-86e2e193bdee@github.com>

On Tue, 23 Mar 2021 19:18:38 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Thanks again for setting this straight.
>
>> Thanks again for setting this straight.
> 
> @earthling-amzn Thanks for reviewing and sorry for the noise.

Can we move this PR forward?

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

PR: https://git.openjdk.java.net/shenandoah/pull/25

From kdnilsen at openjdk.java.net  Wed Apr  7 21:41:22 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 7 Apr 2021 21:41:22 GMT
Subject: RFR: Mixed evacuation
Message-ID: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>

Mixed evacuation

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

Commit messages:
 - Perform mixed collections
 - Perform mixed collections

Changes: https://git.openjdk.java.net/shenandoah/pull/29/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=00
  Stats: 936 lines in 26 files changed: 811 ins; 43 del; 82 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/29/head:pull/29

PR: https://git.openjdk.java.net/shenandoah/pull/29

From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr  7 21:41:22 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 7 Apr 2021 21:41:22 GMT
Subject: RFR: Mixed evacuation
In-Reply-To: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
Message-ID: <FqMwQGP-aan5Ku0Yi52VkDx1zySrYst0YyKP3MRziBc=.9fdfcc65-2e0a-4e99-a444-14e07266e3c9@github.com>

On Wed, 7 Apr 2021 20:43:31 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Mixed evacuation

Think it wants a description of the changes in the body of the PR.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Wed Apr  7 21:41:22 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 7 Apr 2021 21:41:22 GMT
Subject: RFR: Mixed evacuation
In-Reply-To: <FqMwQGP-aan5Ku0Yi52VkDx1zySrYst0YyKP3MRziBc=.9fdfcc65-2e0a-4e99-a444-14e07266e3c9@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <FqMwQGP-aan5Ku0Yi52VkDx1zySrYst0YyKP3MRziBc=.9fdfcc65-2e0a-4e99-a444-14e07266e3c9@github.com>
Message-ID: <lcgGe3fr1UhcJZ7noBzVp1vsJ0ebNAXRFFBoQatlBDk=.880681c4-479c-4cab-b09d-ce5171ffe38c@github.com>

On Wed, 7 Apr 2021 21:03:24 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

>> Mixed evacuation
>
> Think it wants a description of the changes in the body of the PR.

I'm not sure how to address the "empty pull request body" problem.  The purpose of this pull request is described in the commit comments:
This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory.  Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets.  All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected).  After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected.  This code passes TIER1 and hotspot_gc_shenandoah jtreg tests without regressions.  A new jtreg test has been added to exercises concurrent old/young GC.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From zgu at openjdk.java.net  Wed Apr  7 22:06:54 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 7 Apr 2021 22:06:54 GMT
Subject: RFR: Refix ShenandoahPurgeSATBTask
In-Reply-To: <UqlzIymRSosra0OOtKpIgLNNqixoweD4eDvRfH6T_3s=.c687601e-c617-4792-9a22-86e2e193bdee@github.com>
References: <CfwhM_ZK93mjjWuZNRdpOsBCCmahsemo05XRsWwa9AM=.69ec4bdc-d449-489b-a725-569bc002a525@github.com>
 <wDsmCUqHdidwuVQZ7dkeHhBZNFkgAvAJ7f9NrenSMHE=.5135de25-0acc-46e3-8cd6-81b9c80203eb@github.com>
 <IO94NU252dcTJhXUKhYHr2MoHV5i82mQ2kuOSDWi5Dk=.46701d26-75b6-4c12-8976-271b8ea5e482@github.com>
 <UqlzIymRSosra0OOtKpIgLNNqixoweD4eDvRfH6T_3s=.c687601e-c617-4792-9a22-86e2e193bdee@github.com>
Message-ID: <Vc0qgd6DxywOwSnr03ppwSYT9YZbWxgDJZdKuP9E5FQ=.fa475bca-64a4-4aed-bb0d-ccd0ba1fbe68@github.com>

On Wed, 7 Apr 2021 20:29:18 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> Can we move this PR forward?

Roman is on PTO this week, I will ping him next week.

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

PR: https://git.openjdk.java.net/shenandoah/pull/25

From shade at openjdk.java.net  Thu Apr  8 06:30:05 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Apr 2021 06:30:05 GMT
Subject: RFR: Use timed wait to sleep control thread [v2]
In-Reply-To: <LQ-dFdM5K688Oji8vMntuOV_hvgyZXppDYOWQQDloHg=.f000069e-80b7-4c96-98df-8e8774e11117@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <LQ-dFdM5K688Oji8vMntuOV_hvgyZXppDYOWQQDloHg=.f000069e-80b7-4c96-98df-8e8774e11117@github.com>
Message-ID: <C5MbX7_ajLQ7D_WfcX4ubJWKKenwzFTT43JlxdoX5Ss=.74163b24-e509-419e-a925-0c3f6d34cce6@github.com>

On Wed, 7 Apr 2021 20:31:09 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

>> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.
>
> earthling-amzn has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Increase mutex rank of gc waiters
>    
>    This lets us take the control thread's lock to notify it without tripping the deadlock detector.
>  - Remove unnecessary enum namespace

OK then, with one minor stylistic nit.

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 54:

> 52:   ConcurrentGCThread(),
> 53:   _alloc_failure_waiters_lock(Mutex::leaf, "ShenandoahAllocFailureGC_lock", true, Monitor::_safepoint_check_always),
> 54:   _gc_waiters_lock(Mutex::safepoint, "ShenandoahRequestedGC_lock", true, Monitor::_safepoint_check_always),

Look at `src/hotspot/share/runtime/mutexLocker.cpp`: if we need to elevate the lock above/below the `leaf`, the usual thing to do is to say `leaf + 1` or `leaf - 1`. I would prefer to make `_control_lock` into `leaf - 1`, as that one is special, not all other locks.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/28

From zgu at openjdk.java.net  Thu Apr  8 12:13:25 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 8 Apr 2021 12:13:25 GMT
Subject: Integrated: 8264718: Shenandoah: enable string deduplication during
 root scanning
In-Reply-To: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>
References: <JIHUjoQLXoCgtfu1BQNsoDVJykntZ88mlCcGUpcrFO8=.25728a73-f67b-4272-b618-45663aa19f98@github.com>
Message-ID: <_5JKrTptBZMdek4mggI4ovb80P9BdSBcGmMtZDXozek=.0366e58b-1d22-4bb5-86b0-afb390e4a88a@github.com>

On Mon, 5 Apr 2021 21:42:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah used to scan roots at pauses, so it deliberately disables string deduplication during root scanning to avoid extra pause times.
> 
> Now, Shenandoah scans roots in concurrent phase, it is no longer a concern, we should enable it.
> 
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 3aec2d96
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3aec2d96
Stats:     69 lines in 5 files changed: 39 ins; 26 del; 4 mod

8264718: Shenandoah: enable string deduplication during root scanning

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/jdk/pull/3348

From kdnilsen at openjdk.java.net  Thu Apr  8 15:32:13 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 8 Apr 2021 15:32:13 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
Message-ID: <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>

> Mixed evacuation

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

  Chasing bug during prepare_for_old_collection
  
  One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
  optimization error.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/29/files
  - new: https://git.openjdk.java.net/shenandoah/pull/29/files/7bbd6a37..50ffb169

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=00-01

  Stats: 27 lines in 3 files changed: 8 ins; 7 del; 12 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/29/head:pull/29

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kvn at openjdk.java.net  Thu Apr  8 15:32:40 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 15:32:40 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler
Message-ID: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>

As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 

- `jdk.aot` module ? the `jaotc` tool 
- `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
- related HotSpot code guarded by `#if INCLUDE_AOT` 

Additionally, remove tests as well as code in makefiles related to AoT compilation.

Tested hs-tier1-4

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

Commit messages:
 - 8264805: Remove the experimental Ahead-of-Time Compiler

Changes: https://git.openjdk.java.net/jdk/pull/3398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264805
  Stats: 26903 lines in 375 files changed: 4 ins; 26703 del; 196 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

PR: https://git.openjdk.java.net/jdk/pull/3398

From rkennke at openjdk.java.net  Thu Apr  8 15:47:30 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 8 Apr 2021 15:47:30 GMT
Subject: RFR: Mixed evacuation
In-Reply-To: <lcgGe3fr1UhcJZ7noBzVp1vsJ0ebNAXRFFBoQatlBDk=.880681c4-479c-4cab-b09d-ce5171ffe38c@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <FqMwQGP-aan5Ku0Yi52VkDx1zySrYst0YyKP3MRziBc=.9fdfcc65-2e0a-4e99-a444-14e07266e3c9@github.com>
 <lcgGe3fr1UhcJZ7noBzVp1vsJ0ebNAXRFFBoQatlBDk=.880681c4-479c-4cab-b09d-ce5171ffe38c@github.com>
Message-ID: <JwGKU5h8w5ikHMwNLOsrmBY_GGZuxXiSF1mXrGQR8ag=.b1b1a155-2048-443f-969c-cafbbdd7fbb0@github.com>

On Wed, 7 Apr 2021 21:21:30 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> I'm not sure how to address the "empty pull request body" problem. The purpose of this pull request is described in the commit comments:
> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot_gc_shenandoah jtreg tests without regressions. A new jtreg test has been added to exercises concurrent old/young GC.

Please add this text in the PR description above. Klick '...' -> 'Edit' and enter the text there.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kvn at openjdk.java.net  Thu Apr  8 15:58:39 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 15:58:39 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v2]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <fx4j96R0QPbRe0vxfo8psKinNZeKEu-alqxyKTgrJqc=.0b17062e-345e-446c-9c51-c2711eb17441@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

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

 - Merge branch 'master' into JDK-8264805
 - 8264805: Remove the experimental Ahead-of-Time Compiler

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

Changes: https://git.openjdk.java.net/jdk/pull/3398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=01
  Stats: 26906 lines in 375 files changed: 4 ins; 26709 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Thu Apr  8 16:17:33 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 16:17:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v3]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <BlpY5DxuvNwVzjeD5tsKKsGrBMRiF44IpNQTFM8-PDk=.a24899bc-1bf4-4bd1-b3fe-014dfa1f1c23@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

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

 - Merge branch 'master' into JDK-8264805
 - Merge branch 'master' into JDK-8264805
 - 8264805: Remove the experimental Ahead-of-Time Compiler

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

Changes: https://git.openjdk.java.net/jdk/pull/3398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=02
  Stats: 26906 lines in 375 files changed: 4 ins; 26709 del; 193 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

PR: https://git.openjdk.java.net/jdk/pull/3398

From github.com+71722661+earthling-amzn at openjdk.java.net  Thu Apr  8 16:36:53 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Thu, 8 Apr 2021 16:36:53 GMT
Subject: RFR: Use timed wait to sleep control thread [v3]
In-Reply-To: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
Message-ID: <TYZFJ3-htDp-PQxey-iKdS9aNCQQi9ziDnY59Rj_4QU=.bd57a93e-0e44-4272-8022-a1fe75da0424@github.com>

> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.

earthling-amzn has updated the pull request incrementally with one additional commit since the last revision:

  Lower the rank on new control lock (rather than raise it for others)

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/28/files
  - new: https://git.openjdk.java.net/shenandoah/pull/28/files/f4b50907..16d39268

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=28&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=28&range=01-02

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From shade at openjdk.java.net  Thu Apr  8 16:36:55 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Apr 2021 16:36:55 GMT
Subject: RFR: Use timed wait to sleep control thread [v2]
In-Reply-To: <C5MbX7_ajLQ7D_WfcX4ubJWKKenwzFTT43JlxdoX5Ss=.74163b24-e509-419e-a925-0c3f6d34cce6@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <LQ-dFdM5K688Oji8vMntuOV_hvgyZXppDYOWQQDloHg=.f000069e-80b7-4c96-98df-8e8774e11117@github.com>
 <C5MbX7_ajLQ7D_WfcX4ubJWKKenwzFTT43JlxdoX5Ss=.74163b24-e509-419e-a925-0c3f6d34cce6@github.com>
Message-ID: <-JUb-gfVsZ1HgIbQeLRnJWWeJAIZHSViyYbVbt7g8Cs=.c239fad5-16f2-4ca6-91c4-ab90bb0c7603@github.com>

On Thu, 8 Apr 2021 06:26:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> earthling-amzn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Increase mutex rank of gc waiters
>>    
>>    This lets us take the control thread's lock to notify it without tripping the deadlock detector.
>>  - Remove unnecessary enum namespace
>
> OK then, with one minor stylistic nit.

Good to go.

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From github.com+71722661+earthling-amzn at openjdk.java.net  Thu Apr  8 16:36:59 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Thu, 8 Apr 2021 16:36:59 GMT
Subject: RFR: Use timed wait to sleep control thread [v2]
In-Reply-To: <C5MbX7_ajLQ7D_WfcX4ubJWKKenwzFTT43JlxdoX5Ss=.74163b24-e509-419e-a925-0c3f6d34cce6@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <LQ-dFdM5K688Oji8vMntuOV_hvgyZXppDYOWQQDloHg=.f000069e-80b7-4c96-98df-8e8774e11117@github.com>
 <C5MbX7_ajLQ7D_WfcX4ubJWKKenwzFTT43JlxdoX5Ss=.74163b24-e509-419e-a925-0c3f6d34cce6@github.com>
Message-ID: <7RflgC61zTznyorOga6sNlwL55Of58yGdPs2Tsg4LVw=.48fdd930-520b-4aa4-b136-6518673a8977@github.com>

On Thu, 8 Apr 2021 06:26:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> earthling-amzn has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Increase mutex rank of gc waiters
>>    
>>    This lets us take the control thread's lock to notify it without tripping the deadlock detector.
>>  - Remove unnecessary enum namespace
>
> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 54:
> 
>> 52:   ConcurrentGCThread(),
>> 53:   _alloc_failure_waiters_lock(Mutex::leaf, "ShenandoahAllocFailureGC_lock", true, Monitor::_safepoint_check_always),
>> 54:   _gc_waiters_lock(Mutex::safepoint, "ShenandoahRequestedGC_lock", true, Monitor::_safepoint_check_always),
> 
> Look at `src/hotspot/share/runtime/mutexLocker.cpp`: if we need to elevate the lock above/below the `leaf`, the usual thing to do is to say `leaf + 1` or `leaf - 1`. I would prefer to make `_control_lock` into `leaf - 1`, as that one is special, not all other locks.

Yes, good call.

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From shade at openjdk.java.net  Thu Apr  8 17:09:24 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Apr 2021 17:09:24 GMT
Subject: RFR: Use timed wait to sleep control thread [v2]
In-Reply-To: <-JUb-gfVsZ1HgIbQeLRnJWWeJAIZHSViyYbVbt7g8Cs=.c239fad5-16f2-4ca6-91c4-ab90bb0c7603@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <LQ-dFdM5K688Oji8vMntuOV_hvgyZXppDYOWQQDloHg=.f000069e-80b7-4c96-98df-8e8774e11117@github.com>
 <C5MbX7_ajLQ7D_WfcX4ubJWKKenwzFTT43JlxdoX5Ss=.74163b24-e509-419e-a925-0c3f6d34cce6@github.com>
 <-JUb-gfVsZ1HgIbQeLRnJWWeJAIZHSViyYbVbt7g8Cs=.c239fad5-16f2-4ca6-91c4-ab90bb0c7603@github.com>
Message-ID: <UHf0uUfZ72lPvmqUenCITx0bAPUfnxnSL8Z0SslYi6k=.b4feb7ec-d218-4139-99a1-587a25204ea8@github.com>

On Thu, 8 Apr 2021 16:33:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> OK then, with one minor stylistic nit.
>
> Good to go.

OpenJDK infra seems to be at maintenance. Bots would hopefully integrate as infra is online again.

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From kvn at openjdk.java.net  Thu Apr  8 17:24:38 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 17:24:38 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

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

  Remove exports from Graal module to jdk.aot

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3398/files
  - new: https://git.openjdk.java.net/jdk/pull/3398/files/3dbc6210..6cce0f6c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=02-03

  Stats: 39 lines in 3 files changed: 0 ins; 36 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

PR: https://git.openjdk.java.net/jdk/pull/3398

From coleenp at openjdk.java.net  Thu Apr  8 19:35:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 8 Apr 2021 19:35:06 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <nWH5uT6GOy39SQ5N0i0_ebq68fxuz51usnggz0_Zo6k=.948353ee-179b-497c-becf-e959995ae130@github.com>

On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) {
This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want.

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From coleenp at openjdk.java.net  Thu Apr  8 19:42:06 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 8 Apr 2021 19:42:06 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <oP7swTV0ldoNBfWnHMamOyfNybhTuK-iKaHUy2x1E_g=.82aa1f26-0653-4784-bba3-3253af0958ab@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

I looked at the changes in oops, runtime, classfile and code directories.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3398

From erikj at openjdk.java.net  Thu Apr  8 19:54:07 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Thu, 8 Apr 2021 19:54:07 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <fqV6HvSPDuUiTGTAOxfZ7YpMrNmn0tLPFlPCSjf9zJc=.19110c8b-c210-463e-860d-8ec13d0160f0@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

Build changes look good.

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

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3398

From stefank at openjdk.java.net  Thu Apr  8 20:04:07 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 8 Apr 2021 20:04:07 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <qAqfbw9odHV4Our9-TXmABErJnJwQqmCH1j4XJLV2yk=.733aa4d6-7710-4c6f-8db2-6300d399d492@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

GC changes look good.

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

Marked as reviewed by stefank (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Thu Apr  8 20:04:08 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 20:04:08 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <qAqfbw9odHV4Our9-TXmABErJnJwQqmCH1j4XJLV2yk=.733aa4d6-7710-4c6f-8db2-6300d399d492@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <qAqfbw9odHV4Our9-TXmABErJnJwQqmCH1j4XJLV2yk=.733aa4d6-7710-4c6f-8db2-6300d399d492@github.com>
Message-ID: <P7MB60v5xlZO4-xDgE9EzCJfWSDVF36aahOe4R0RK4o=.b205b33f-d376-46ba-a8c7-b2790a91fc25@github.com>

On Thu, 8 Apr 2021 19:58:11 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> GC changes look good.

> void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) {
> This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want.

Thank you, Coleen, for review. I will wait other comments and will remove this code.

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Thu Apr  8 20:04:08 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 20:04:08 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <P7MB60v5xlZO4-xDgE9EzCJfWSDVF36aahOe4R0RK4o=.b205b33f-d376-46ba-a8c7-b2790a91fc25@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <qAqfbw9odHV4Our9-TXmABErJnJwQqmCH1j4XJLV2yk=.733aa4d6-7710-4c6f-8db2-6300d399d492@github.com>
 <P7MB60v5xlZO4-xDgE9EzCJfWSDVF36aahOe4R0RK4o=.b205b33f-d376-46ba-a8c7-b2790a91fc25@github.com>
Message-ID: <ev8mgaenIy2OM_DWsdaeWXqfA9n_mTGHNCqBDLVHvNk=.00135a1c-ac22-4f99-b00a-ce060169037c@github.com>

On Thu, 8 Apr 2021 20:00:30 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> GC changes look good.
>
>> void CodeCache::mark_for_evol_deoptimization(InstanceKlass* dependee) {
>> This function, its caller and the function in jvmtiRedefineClasses.cpp that calls it can be deleted also, but you can file a separate RFE for that if you want.
> 
> Thank you, Coleen, for review. I will wait other comments and will remove this code.

Thank you, Erik and Stefan.

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From iignatyev at openjdk.java.net  Thu Apr  8 20:31:11 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 8 Apr 2021 20:31:11 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <dLbTg3Hf84jb3Sr9JRqByhd0_nh4vMSqp_33XJeikaM=.ce9e08d7-6516-4009-9a0b-0013ed9a12a1@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

Test changes look good to me.

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

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3398

From coleenp at openjdk.java.net  Thu Apr  8 21:03:07 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 8 Apr 2021 21:03:07 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <dLbTg3Hf84jb3Sr9JRqByhd0_nh4vMSqp_33XJeikaM=.ce9e08d7-6516-4009-9a0b-0013ed9a12a1@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <dLbTg3Hf84jb3Sr9JRqByhd0_nh4vMSqp_33XJeikaM=.ce9e08d7-6516-4009-9a0b-0013ed9a12a1@github.com>
Message-ID: <qjBKlSG7kBRP8akJ5LQx0jixIS3nYCGETetypfUb2rY=.3ef64c46-3518-44e1-83cf-c17bd64db662@github.com>

On Thu, 8 Apr 2021 20:28:27 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> Test changes look good to me.

There's a comment above
void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) {
that should be rewritten, so I think we should just file an RFE to remove it afterwards.

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From shade at openjdk.java.net  Thu Apr  8 21:20:32 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 8 Apr 2021 21:20:32 GMT
Subject: git: openjdk/shenandoah: master: Use timed wait to sleep control
 thread
Message-ID: <d26570e6-bf8f-42db-a7c6-83c945aaf137@openjdk.org>

Changeset: 84bb2c3c
Author:    William Kemper <kemperw at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
Date:      2021-04-08 21:18:54 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/84bb2c3c

Use timed wait to sleep control thread

Reviewed-by: shade

! src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp
! src/hotspot/share/gc/shenandoah/shenandoahControlThread.hpp


From github.com+71722661+earthling-amzn at openjdk.java.net  Thu Apr  8 21:24:30 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Thu, 8 Apr 2021 21:24:30 GMT
Subject: Integrated: Use timed wait to sleep control thread
In-Reply-To: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
Message-ID: <FVN_fw2i2geAbIBtIAH2hNFypq5x7H3OL3NS4lxUTUc=.988d341d-d708-48cf-899e-b94c3c499383@github.com>

On Tue, 6 Apr 2021 18:44:02 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> Using a timed `wait` rather than a naked sleep allows the control thread to be more responsive to requests from mutators and the regulator thread to start GC cycles. The sleep time is also changed from `ShenandoahControlIntervalMin` to `ShenandoahControlIntervalMax` to reduce unnecessary polling cycles. We could use a plain `wait`, but the control thread is responsible for periodically sending allocation metrics to the `pacer`.

This pull request has now been integrated.

Changeset: 84bb2c3c
Author:    William Kemper <kemperw at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/84bb2c3c
Stats:     17 lines in 2 files changed: 12 ins; 0 del; 5 mod

Use timed wait to sleep control thread

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From kvn at openjdk.java.net  Thu Apr  8 21:57:07 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Thu, 8 Apr 2021 21:57:07 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <qjBKlSG7kBRP8akJ5LQx0jixIS3nYCGETetypfUb2rY=.3ef64c46-3518-44e1-83cf-c17bd64db662@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <dLbTg3Hf84jb3Sr9JRqByhd0_nh4vMSqp_33XJeikaM=.ce9e08d7-6516-4009-9a0b-0013ed9a12a1@github.com>
 <qjBKlSG7kBRP8akJ5LQx0jixIS3nYCGETetypfUb2rY=.3ef64c46-3518-44e1-83cf-c17bd64db662@github.com>
Message-ID: <UB5Y0bV48eM9xCNqaxfdSEHa1ROJyGKAABlAs0Uu2io=.6cd68e34-d190-4580-be4a-cfb0c669a327@github.com>

On Thu, 8 Apr 2021 20:59:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> There's a comment above
> void VM_RedefineClasses::mark_dependent_code(InstanceKlass* ik) {
> that should be rewritten, so I think we should just file an RFE to remove it afterwards.

https://bugs.openjdk.java.net/browse/JDK-8264941

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From github.com+71722661+earthling-amzn at openjdk.java.net  Thu Apr  8 22:19:28 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Thu, 8 Apr 2021 22:19:28 GMT
Subject: RFR: Use timed wait to sleep control thread [v2]
In-Reply-To: <UHf0uUfZ72lPvmqUenCITx0bAPUfnxnSL8Z0SslYi6k=.b4feb7ec-d218-4139-99a1-587a25204ea8@github.com>
References: <sBAYUJ4SBaSN_sxaKeoXMEtoTviiFXyNfhFQAca0WKs=.8e3f3379-1fa8-4060-8234-8032d0cfbc27@github.com>
 <LQ-dFdM5K688Oji8vMntuOV_hvgyZXppDYOWQQDloHg=.f000069e-80b7-4c96-98df-8e8774e11117@github.com>
 <C5MbX7_ajLQ7D_WfcX4ubJWKKenwzFTT43JlxdoX5Ss=.74163b24-e509-419e-a925-0c3f6d34cce6@github.com>
 <-JUb-gfVsZ1HgIbQeLRnJWWeJAIZHSViyYbVbt7g8Cs=.c239fad5-16f2-4ca6-91c4-ab90bb0c7603@github.com>
 <UHf0uUfZ72lPvmqUenCITx0bAPUfnxnSL8Z0SslYi6k=.b4feb7ec-d218-4139-99a1-587a25204ea8@github.com>
Message-ID: <myE78wzuo1NV28Y7qrTXCyVb7eqTHojZK0fr3ORamNg=.e5dddcf4-4ed9-4233-8b5d-1bbea86923be@github.com>

On Thu, 8 Apr 2021 17:06:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> OpenJDK infra seems to be at maintenance. Bots would hopefully integrate as infra is online again.

Yay bots!

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

PR: https://git.openjdk.java.net/shenandoah/pull/28

From dholmes at openjdk.java.net  Fri Apr  9 04:35:15 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 9 Apr 2021 04:35:15 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

Hi Vladimir,

This looks good to me - I went through all the files.

It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??

I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.

Thanks,
David

src/hotspot/cpu/x86/compiledIC_x86.cpp line 134:

> 132: #ifdef ASSERT
> 133:   CodeBlob *cb = CodeCache::find_blob_unsafe((address) _call);
> 134:   assert(cb, "sanity");

Nit: implied boolean - use "cb != NULL"

src/hotspot/share/memory/heap.hpp line 174:

> 172:   bool contains(const void* p) const             { return low() <= p && p < high(); }
> 173:   bool contains_blob(const CodeBlob* blob) const {
> 174:     const void* start = (void*)blob;

start seems redundant now

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3398

From aph at openjdk.java.net  Fri Apr  9 08:18:18 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 9 Apr 2021 08:18:18 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <7ioJ2_GFIK53zxpqFcYLt9LYDd8WS7ronekRuo6O5Ac=.572d87d5-2f1f-41cf-8c9b-6d018926f0cf@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

AArch64 looks fine.

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

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3398

From shade at openjdk.java.net  Fri Apr  9 08:54:18 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Apr 2021 08:54:18 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

Shenandoah parts look good. I have a few minor comments after reading the rest.

src/hotspot/cpu/x86/globalDefinitions_x86.hpp line 73:

> 71: 
> 72: #if INCLUDE_JVMCI
> 73: #define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS (EnableJVMCI)

Minor nit: can probably drop parentheses here.

src/hotspot/share/code/compiledIC.cpp line 715:

> 713:     tty->print("interpreted");
> 714:   } else {
> 715:     tty->print("unknown");

We can probably split this cleanup into the minor issue, your call. The benefit of separate issue: backportability.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3398

From shade at openjdk.java.net  Fri Apr  9 12:01:24 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Apr 2021 12:01:24 GMT
Subject: RFR: 8264727: Remove extraneous whitespace from phase timings
 report
In-Reply-To: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
References: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
Message-ID: <w2n3Is1reVN89AoP0Vb72j9tEBfWMq7HzxFrYQzcDHE=.cd51e691-ff78-478d-8c93-da0d413584cd@github.com>

On Mon, 5 Apr 2021 16:45:43 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> This extra space doesn't look like it was intended to improve any alignment of text in the report.

@earthling-amzn Still want to integrate this? You need to title this PR correctly for bots to catch it up.

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

PR: https://git.openjdk.java.net/jdk/pull/3342

From zgu at openjdk.java.net  Fri Apr  9 13:55:37 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 9 Apr 2021 13:55:37 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
Message-ID: <oEB9y8xruB6iheT45U2YecmNBUt3KL_VAbi7vRFN0FU=.2acdf2d7-6b3a-45a5-9173-6e14276703f0@github.com>

On Thu, 8 Apr 2021 15:32:13 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chasing bug during prepare_for_old_collection
>   
>   One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
>   optimization error.

Changes requested by zgu (Reviewer).

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

> 437:       // Instead, skip to the following marked object, as indicated by the first following mark bit in
> 438:       // marking_context.
> 439:       int size = obj->size();

I am not sure that it is safe to walk dead oops, e.g. their classes might have been unloaded. I suggest to use marking_context->get_next_marked_addr() instead.

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

> 508:         // Instead, skip to the following marked object, as indicated by the first following mark bit in
> 509:         // marking_context.
> 510:         int size = obj->size();

Same as above

src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp line 167:

> 165:   //
> 166:   // TraceCollectorStats tcs(heap->monitoring_support()->concurrent_collection_counters());
> 167:   // EventMark em("%s", msg);

Yes, I think we want them.

src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp line 67:

> 65:   f(finish_mark,                                    "  Finish Mark")                   \
> 66:   SHENANDOAH_PAR_PHASE_DO(finish_mark_,             "    FM: ", f)                     \
> 67:   f(coalesce_and_fill,                              "Coalesce and Fill Old Dead")      \

Does not seem to be used anywhere.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From iveresov at openjdk.java.net  Fri Apr  9 16:41:20 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 9 Apr 2021 16:41:20 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1184:

> 1182:       }
> 1183:     } else if (jvmci_env()->isa_HotSpotMetaspaceConstantImpl(constant)) {
> 1184:       if (!_immutable_pic_compilation) {

All _immutable_pic_compilation mentions can be removed as well. It is true only for AOT compiles produced by Graal. It's never going to be used without AOT.

src/hotspot/share/oops/instanceKlass.hpp line 257:

> 255:     _misc_declares_nonstatic_concrete_methods = 1 << 6,  // directly declares non-static, concrete methods
> 256:     _misc_has_been_redefined                  = 1 << 7,  // class has been redefined
> 257:     _unused                                   = 1 << 8,  //

Any particular reason we don't want to remove this gap?

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From iklam at openjdk.java.net  Fri Apr  9 16:58:23 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 9 Apr 2021 16:58:23 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

LGTM. Just a small nit.

src/hotspot/share/oops/methodCounters.cpp line 77:

> 75: }
> 76: 
> 77: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) {

MethodCounters::metaspace_pointers_do can be removed altogether (also need to remove the declaration in methodCounter.hpp).

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3398

From github.com+71722661+earthling-amzn at openjdk.java.net  Fri Apr  9 17:10:27 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Fri, 9 Apr 2021 17:10:27 GMT
Subject: Integrated: 8264727: Shenandoah: Remove extraneous whitespace from
 phase timings report
In-Reply-To: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
References: <zLRY-hWfG_917fELOrFRn7DxTq4ZEMPj1lRZRiUAz-g=.a02954be-dfff-49c3-8706-f1e781e28725@github.com>
Message-ID: <NcFw3aLgpsEirgAg1Z-RMQhWHVYXmxRbe9rRAroyrZY=.71fb7339-fbf9-4e7f-a66c-aacae6ba2b76@github.com>

On Mon, 5 Apr 2021 16:45:43 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> This extra space doesn't look like it was intended to improve any alignment of text in the report.

This pull request has now been integrated.

Changeset: ec31b3a1
Author:    William Kemper <kemperw at amazon.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ec31b3a1
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8264727: Shenandoah: Remove extraneous whitespace from phase timings report

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/jdk/pull/3342

From kvn at openjdk.java.net  Fri Apr  9 17:13:17 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:13:17 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
Message-ID: <FkHY159OY-BZJOj3EpameQ-wQhLgiMyMrrjxu2JZQ8k=.f879e3aa-cdb7-40af-8826-3484a299e914@github.com>

On Fri, 9 Apr 2021 04:32:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Hi Vladimir,
> 
> This looks good to me - I went through all the files.
> 
> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??
> 
> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.
> 
> Thanks,
> David

Thank you, David.
We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`.
I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Fri Apr  9 17:42:27 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:42:27 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <FkHY159OY-BZJOj3EpameQ-wQhLgiMyMrrjxu2JZQ8k=.f879e3aa-cdb7-40af-8826-3484a299e914@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
 <FkHY159OY-BZJOj3EpameQ-wQhLgiMyMrrjxu2JZQ8k=.f879e3aa-cdb7-40af-8826-3484a299e914@github.com>
Message-ID: <lC8kkzacpStLbNr77SkZMBiGX6j3frs3zFkSq2OdAXA=.92744f14-5afc-4458-814d-6d61e8644af7@github.com>

On Fri, 9 Apr 2021 17:09:58 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Hi Vladimir,
>> 
>> This looks good to me - I went through all the files.
>> 
>> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??
>> 
>> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.
>> 
>> Thanks,
>> David
>
>> Hi Vladimir,
>> 
>> This looks good to me - I went through all the files.
>> 
>> It was nice to see how nicely compartmentalized the AOT feature was - that made checking the changes quite simple. The one exception was the fingerprinting code, which for some reason was AOT-only but not marked that way, so I'm not sure what the story is there. ??
>> 
>> I was also surprised to see some of the flags were not marked experimental, so there will need to a CSR request to remove those without going through the normal deprecation process.
>> 
>> Thanks,
>> David
> 
> Thank you, David.
> We thought that we could use fingerprint code for other cases that is why we did not put it under `#if INCLUDE_AOT`.
> I filed CSR for AOT product flags removal: https://bugs.openjdk.java.net/browse/JDK-8265000

Thank you, Igor Ignatyev, Igor Veresov, Ioi, Aleksey and Andrew for reviews.
I will update changes based on your comments.

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Fri Apr  9 17:45:20 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 17:45:20 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
Message-ID: <VtF7FHuoaEtc_asbPszw_UIshxBWd7F2CQp0DdzKcZ4=.5f06acbb-7de3-4a23-8602-92a8c31dd8ac@github.com>

On Fri, 9 Apr 2021 02:44:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/compiledIC_x86.cpp line 134:
> 
>> 132: #ifdef ASSERT
>> 133:   CodeBlob *cb = CodeCache::find_blob_unsafe((address) _call);
>> 134:   assert(cb, "sanity");
> 
> Nit: implied boolean - use "cb != NULL"

done

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Fri Apr  9 18:23:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:23:26 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <vf5UREaLiMthQO92Z8gGQJOWM-Y7C5qUHwoqmbzwXY8=.0a34fad1-e6e4-4f68-9e7a-99ce53b0528f@github.com>
Message-ID: <obMOiA-1TtLCLVF4QQ8u16sMgzCJuhb1h_HpwerXte0=.5f118e88-ab6a-4105-86ab-70d87d2fa439@github.com>

On Fri, 9 Apr 2021 03:03:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/memory/heap.hpp line 174:
> 
>> 172:   bool contains(const void* p) const             { return low() <= p && p < high(); }
>> 173:   bool contains_blob(const CodeBlob* blob) const {
>> 174:     const void* start = (void*)blob;
> 
> start seems redundant now

Done:
   bool contains_blob(const CodeBlob* blob) const {
-    const void* start = (void*)blob;
-    return contains(start);
+    return contains((void*)blob);
   }

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Fri Apr  9 18:23:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:23:25 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
Message-ID: <ofskald98fzMljX0LHBVGFyKrGey-skK1S_4gpd07r8=.33f3109a-b923-44a5-bdf1-d99dfbf341fd@github.com>

On Fri, 9 Apr 2021 08:29:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/cpu/x86/globalDefinitions_x86.hpp line 73:
> 
>> 71: 
>> 72: #if INCLUDE_JVMCI
>> 73: #define COMPRESSED_CLASS_POINTERS_DEPENDS_ON_COMPRESSED_OOPS (EnableJVMCI)
> 
> Minor nit: can probably drop parentheses here.

done

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Fri Apr  9 18:32:26 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:32:26 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <BJyk2_cT2V5IMzW2NtL49_Cvaj-Mq-q9R8jWNGF2EmA=.f99b7b06-8093-4f98-ae9e-49919e0e46c8@github.com>
Message-ID: <Cv3I8B_-bwT0M-Ft2JqNPkxYk-PP46aqJKN23mKYblY=.c94b7bfc-cc2a-4a76-87bd-58a7a24d4fba@github.com>

On Fri, 9 Apr 2021 08:32:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/code/compiledIC.cpp line 715:
> 
>> 713:     tty->print("interpreted");
>> 714:   } else {
>> 715:     tty->print("unknown");
> 
> We can probably split this cleanup into the minor issue, your call. The benefit of separate issue: backportability.

Reverted and filed https://bugs.openjdk.java.net/browse/JDK-8265013

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Fri Apr  9 18:36:24 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 18:36:24 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
Message-ID: <8rFTTlGuCqN9XzBEbaAAf9R-YhTTqe45jv9Gh7F506w=.67e92697-68c4-4657-abb4-803231a9d1a9@github.com>

On Fri, 9 Apr 2021 16:30:41 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/instanceKlass.hpp line 257:
> 
>> 255:     _misc_declares_nonstatic_concrete_methods = 1 << 6,  // directly declares non-static, concrete methods
>> 256:     _misc_has_been_redefined                  = 1 << 7,  // class has been redefined
>> 257:     _unused                                   = 1 << 8,  //
> 
> Any particular reason we don't want to remove this gap?

Less changes. We don't get any benefits from removing it. It is opposite - if we need a new value we will use it without changing following values again.

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Fri Apr  9 19:09:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 19:09:25 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <32eWo34nJ7czxicNNgoww6GpOpg0jKq8NZY_pPeQPpI=.e698cb8a-78e7-40a2-b54e-9b29ce1bedb1@github.com>
Message-ID: <qc4oegjT9GB5i8kHO9od5ygICGV2g5kv2RP0wUEoW0w=.69e16fc3-aa93-4cd6-9419-91b83914dfd1@github.com>

On Fri, 9 Apr 2021 16:34:58 GMT, Igor Veresov <iveresov at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/jvmci/jvmciCodeInstaller.cpp line 1184:
> 
>> 1182:       }
>> 1183:     } else if (jvmci_env()->isa_HotSpotMetaspaceConstantImpl(constant)) {
>> 1184:       if (!_immutable_pic_compilation) {
> 
> All _immutable_pic_compilation mentions can be removed as well. It is true only for AOT compiles produced by Graal. It's never going to be used without AOT.

Done. I removed _immutable_pic_compilation in JVMCI in Hotspot.

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From kvn at openjdk.java.net  Fri Apr  9 19:26:22 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 19:26:22 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
Message-ID: <9RiwxlBLMiREzNvRHU14RQBW33nieUT8-Pmkod_GvtA=.ad51b2f9-f244-4346-8844-9fee39c9aa5b@github.com>

On Fri, 9 Apr 2021 16:54:35 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> src/hotspot/share/oops/methodCounters.cpp line 77:
> 
>> 75: }
>> 76: 
>> 77: void MethodCounters::metaspace_pointers_do(MetaspaceClosure* it) {
> 
> MethodCounters::metaspace_pointers_do can be removed altogether (also need to remove the declaration in methodCounter.hpp).

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From mchung at openjdk.java.net  Fri Apr  9 20:53:33 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 9 Apr 2021 20:53:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
Message-ID: <FhGLyUe8AL5wDoKma5NIDtKP8Rmq2c5a9e4uFF5rRWM=.0aca481d-4791-4021-b9ae-b868ea42f11e@github.com>

On Thu, 8 Apr 2021 17:24:38 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove exports from Graal module to jdk.aot

I reviewed the module-loader-map and non-hotspot non-AOT tests.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3398

From zgu at openjdk.java.net  Fri Apr  9 21:20:45 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 9 Apr 2021 21:20:45 GMT
Subject: RFR: 8265012: Shenandoah: Backout JDK-8264718
Message-ID: <2dkdGG9JW1wdsKKluHOS33VAIne3WdE7xxUgIlfSQ2c=.65c62947-47cf-466c-b773-046afcff5fa6@github.com>

It turns out that enquening string deduplication candidates during concurrent root scanning may result lock rank inversion between stack watermark lock and string dedup queue lock, if the scanning is triggered by stack watermark and dedup buffer happens to be full.

Backout JDK-8264718 for now, will retry after Kim's string deduplication refactoring.

Test:
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - JDK-8265012

Changes: https://git.openjdk.java.net/jdk/pull/3423/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3423&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265012
  Stats: 69 lines in 5 files changed: 26 ins; 39 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3423.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3423/head:pull/3423

PR: https://git.openjdk.java.net/jdk/pull/3423

From kvn at openjdk.java.net  Fri Apr  9 21:59:04 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 9 Apr 2021 21:59:04 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <wJ_aASXqtzMg6Fb3Ag8Ia6bjvAzdMIHH_GF5U8OuNEE=.574c044a-9fa1-46a9-8a0d-d1a89ce3fcc3@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3398/files
  - new: https://git.openjdk.java.net/jdk/pull/3398/files/6cce0f6c..71a166c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=03-04

  Stats: 36 lines in 9 files changed: 0 ins; 27 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

PR: https://git.openjdk.java.net/jdk/pull/3398

From iveresov at openjdk.java.net  Fri Apr  9 22:02:33 2021
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Fri, 9 Apr 2021 22:02:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v5]
In-Reply-To: <wJ_aASXqtzMg6Fb3Ag8Ia6bjvAzdMIHH_GF5U8OuNEE=.574c044a-9fa1-46a9-8a0d-d1a89ce3fcc3@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <wJ_aASXqtzMg6Fb3Ag8Ia6bjvAzdMIHH_GF5U8OuNEE=.574c044a-9fa1-46a9-8a0d-d1a89ce3fcc3@github.com>
Message-ID: <qEoLNtb0E3sj735OChUsZUqhMxWzOslXVpFmPslveQ4=.913b5cdb-e9ca-48c8-8246-371e5d881879@github.com>

On Fri, 9 Apr 2021 21:59:04 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
>> 
>> - `jdk.aot` module ? the `jaotc` tool 
>> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
>> - related HotSpot code guarded by `#if INCLUDE_AOT` 
>> 
>> Additionally, remove tests as well as code in makefiles related to AoT compilation.
>> 
>> Tested hs-tier1-4
>
> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by iveresov (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From dlong at openjdk.java.net  Sat Apr 10 04:05:27 2021
From: dlong at openjdk.java.net (Dean Long)
Date: Sat, 10 Apr 2021 04:05:27 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
Message-ID: <R3JbyZHH6VUO_p8svNqSG992mHxBRJhObXokst2aIjM=.f4c8ec54-c2e8-443f-8ace-f58080234fd4@github.com>

On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> LGTM. Just a small nit.

@iklam
I thought the fingerprint code was also used by CDS.

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From shade at openjdk.java.net  Sat Apr 10 05:54:21 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Sat, 10 Apr 2021 05:54:21 GMT
Subject: RFR: 8265012: Shenandoah: Backout JDK-8264718
In-Reply-To: <2dkdGG9JW1wdsKKluHOS33VAIne3WdE7xxUgIlfSQ2c=.65c62947-47cf-466c-b773-046afcff5fa6@github.com>
References: <2dkdGG9JW1wdsKKluHOS33VAIne3WdE7xxUgIlfSQ2c=.65c62947-47cf-466c-b773-046afcff5fa6@github.com>
Message-ID: <gZTJ8fZ1bTvGA8tvSoxupSYgWX64WRRYT4EIEoP04lw=.251f516f-7329-49bc-a2f9-73e36a5261c0@github.com>

On Fri, 9 Apr 2021 21:14:22 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> It turns out that enquening string deduplication candidates during concurrent root scanning may result lock rank inversion between stack watermark lock and string dedup queue lock, if the scanning is triggered by stack watermark and dedup buffer happens to be full.
> 
> Backout JDK-8264718 for now, will retry after Kim's string deduplication refactoring.
> 
> Test:
> - [x] hotspot_gc_shenandoah

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3423

From iklam at openjdk.java.net  Sat Apr 10 06:08:33 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 10 Apr 2021 06:08:33 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v4]
In-Reply-To: <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
 <BWgKL-lOVyFaUlsa5G31YSrK2r7Hul8qFxOSErLiM0c=.1d648251-62cb-449e-b652-c647ce81fd58@github.com>
 <3zISek5YyT0zkmPX3UZtXKy_r63eOZoW6emV3SuRjPg=.4b805fb5-80c9-4b76-92f8-43f2335c525b@github.com>
Message-ID: <GNwoVCz0KZNh5hN9Fiz9iLgzj1zjMfEXzxqKQP0MOpo=.95df12c1-172e-4465-bc9f-c580a6129147@github.com>

On Fri, 9 Apr 2021 16:54:51 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove exports from Graal module to jdk.aot
>
> LGTM. Just a small nit.

> @iklam
> I thought the fingerprint code was also used by CDS.

CDS actually uses a different mechanism (CRC of the classfile bytes) to validate that a class has not changed between archive dumping time and runtime. See

https://github.com/openjdk/jdk/blob/5784f6b7f74d0b8081ac107fea172539d57d6020/src/hotspot/share/classfile/systemDictionaryShared.cpp#L1126-L1130

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From zgu at openjdk.java.net  Mon Apr 12 12:50:51 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 12 Apr 2021 12:50:51 GMT
Subject: Integrated: 8265012: Shenandoah: Backout JDK-8264718
In-Reply-To: <2dkdGG9JW1wdsKKluHOS33VAIne3WdE7xxUgIlfSQ2c=.65c62947-47cf-466c-b773-046afcff5fa6@github.com>
References: <2dkdGG9JW1wdsKKluHOS33VAIne3WdE7xxUgIlfSQ2c=.65c62947-47cf-466c-b773-046afcff5fa6@github.com>
Message-ID: <NppvfQZ5Hlj5TtfJd_sER4XOMgX7pEUFc5Yd_Szf0WI=.a3283a73-09ef-472f-b617-d0a054a557fd@github.com>

On Fri, 9 Apr 2021 21:14:22 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> It turns out that enquening string deduplication candidates during concurrent root scanning may result lock rank inversion between stack watermark lock and string dedup queue lock, if the scanning is triggered by stack watermark and dedup buffer happens to be full.
> 
> Backout JDK-8264718 for now, will retry after Kim's string deduplication refactoring.
> 
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 125184e9
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/125184e9
Stats:     69 lines in 5 files changed: 26 ins; 39 del; 4 mod

8265012: Shenandoah: Backout JDK-8264718

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/jdk/pull/3423

From rkennke at openjdk.java.net  Mon Apr 12 15:38:55 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Apr 2021 15:38:55 GMT
Subject: RFR: Refix ShenandoahPurgeSATBTask
In-Reply-To: <CfwhM_ZK93mjjWuZNRdpOsBCCmahsemo05XRsWwa9AM=.69ec4bdc-d449-489b-a725-569bc002a525@github.com>
References: <CfwhM_ZK93mjjWuZNRdpOsBCCmahsemo05XRsWwa9AM=.69ec4bdc-d449-489b-a725-569bc002a525@github.com>
Message-ID: <iQcMRu6H-ld0XiPqFHcXZBuBAkB-CvycrBJVqC066Ao=.c2351a75-d06e-4ae2-90c5-dc380e32d8da@github.com>

On Tue, 23 Mar 2021 17:45:17 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> My early fix was incomplete and incorrect.
> 
> 1) ShenandoahPurgeSATBTask needs to change thread claim token for iterating threads in parallel, this was missing in early change.
> 2) Threads::threads_do() -> Threads::possibly_parallel_threads_do() was incorrect, the later version only iterates Java and VM threads. This part of changes are reverted.
> 3) A minor change: declaring _trashed_oops as volatile as it is a shared variable.

Looks good, only a minor thing about shared access to _trashed_oops.

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

> 97: 
> 98: public:
> 99:   volatile size_t _trashed_oops;

If it the intention is to make shared access to the field safe, then C++ volatile does not (fully) achieve this. You also need to use Atomic::inc() and similar to change/read it.

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

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/25

From zgu at openjdk.java.net  Mon Apr 12 15:38:56 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 12 Apr 2021 15:38:56 GMT
Subject: Integrated: Refix ShenandoahPurgeSATBTask
In-Reply-To: <CfwhM_ZK93mjjWuZNRdpOsBCCmahsemo05XRsWwa9AM=.69ec4bdc-d449-489b-a725-569bc002a525@github.com>
References: <CfwhM_ZK93mjjWuZNRdpOsBCCmahsemo05XRsWwa9AM=.69ec4bdc-d449-489b-a725-569bc002a525@github.com>
Message-ID: <F3zjV9pbvwASMUSg1ovAuQ2vTnyh_F4KnjZqGo83hN8=.1e6747e9-f748-401d-bbfc-55733918138b@github.com>

On Tue, 23 Mar 2021 17:45:17 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> My early fix was incomplete and incorrect.
> 
> 1) ShenandoahPurgeSATBTask needs to change thread claim token for iterating threads in parallel, this was missing in early change.
> 2) Threads::threads_do() -> Threads::possibly_parallel_threads_do() was incorrect, the later version only iterates Java and VM threads. This part of changes are reverted.
> 3) A minor change: declaring _trashed_oops as volatile as it is a shared variable.

This pull request has now been integrated.

Changeset: 00aae9c8
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/00aae9c8
Stats:     12 lines in 1 file changed: 6 ins; 0 del; 6 mod

Refix ShenandoahPurgeSATBTask

Reviewed-by: rkennke

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

PR: https://git.openjdk.java.net/shenandoah/pull/25

From zgu at openjdk.java.net  Mon Apr 12 15:52:58 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 12 Apr 2021 15:52:58 GMT
Subject: RFR: Refix ShenandoahPurgeSATBTask
In-Reply-To: <iQcMRu6H-ld0XiPqFHcXZBuBAkB-CvycrBJVqC066Ao=.c2351a75-d06e-4ae2-90c5-dc380e32d8da@github.com>
References: <CfwhM_ZK93mjjWuZNRdpOsBCCmahsemo05XRsWwa9AM=.69ec4bdc-d449-489b-a725-569bc002a525@github.com>
 <iQcMRu6H-ld0XiPqFHcXZBuBAkB-CvycrBJVqC066Ao=.c2351a75-d06e-4ae2-90c5-dc380e32d8da@github.com>
Message-ID: <KFneJDy2FrbuqbyVk430-aLbO486MQ3avSUE-SFal6g=.a0bb52ea-cc4c-41d5-ac89-13b54a08f0c8@github.com>

On Mon, 12 Apr 2021 15:33:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> My early fix was incomplete and incorrect.
>> 
>> 1) ShenandoahPurgeSATBTask needs to change thread claim token for iterating threads in parallel, this was missing in early change.
>> 2) Threads::threads_do() -> Threads::possibly_parallel_threads_do() was incorrect, the later version only iterates Java and VM threads. This part of changes are reverted.
>> 3) A minor change: declaring _trashed_oops as volatile as it is a shared variable.
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 99:
> 
>> 97: 
>> 98: public:
>> 99:   volatile size_t _trashed_oops;
> 
> If it the intention is to make shared access to the field safe, then C++ volatile does not (fully) achieve this. You also need to use Atomic::inc() and similar to change/read it.

Adding volatile keyword, mainly just for coding convention on shared variable. It uses Atomic::add() to update variable, so it is correct.

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

PR: https://git.openjdk.java.net/shenandoah/pull/25

From rkennke at openjdk.java.net  Mon Apr 12 20:58:16 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Apr 2021 20:58:16 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
Message-ID: <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>

On Thu, 8 Apr 2021 15:32:13 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chasing bug during prepare_for_old_collection
>   
>   One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
>   optimization error.

Nice progress!
First-pass review follows.

Please, check out jcheck complaints under the 'Checks' tab and fix them. I'll start a review in the meantime.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 92:

> 90:     prepare_for_old_collections();
> 91:   } else {
> 92:     ShenandoahHeap* heap = ShenandoahHeap::heap();

I'd factor out the whole else block here to call prepare_for_young_collection() or whatever is fitting there.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 440:

> 438:   return (_generation->generation_mode() == GLOBAL)
> 439:     || (_generation->generation_mode() == YOUNG && region->affiliation() == YOUNG_GENERATION)
> 440:     || (_generation->generation_mode() == OLD && region->affiliation() == OLD_GENERATION);

I wouldn't change indentation here, or if it needs changing, then line up the || with the _generation above. Iow, shift it 4 spaces to the right instead of 2 spaces to the left.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 454:

> 452:   for (size_t i = 0; i < num_regions; i++) {
> 453:     ShenandoahHeapRegion* region = heap->get_region(i);
> 454:     if (!in_generation(region))

Please always use { and } in if (and else) constructs.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 475:

> 473: 
> 474:   // This loop is written as while rather than for because of
> 475:   // suspected gcc error in translating/optimizing for-loop

WTF, really? Do we have any indication of this?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 515:

> 513:   // evacuated.  In the future, this threshold percentage may be specified on
> 514:   // the command line or preferrably determined by dynamic heuristics.
> 515: #define CollectionThresholdGarbagePercent 50

We already have ShenandoahGarbageThreshold (defaults to 60 iirc) maybe we want to use this? Or use separate global/old/young thresholds?

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 80:

> 78: // For expediency, we'll have a single class that is a "union" of
> 79: // necessary functionality.
> 80: 

Hmmhmm, this seems a suboptimal design. My intuition would have been to not have each heuristic need to know about any old heuristic, but keep them separate, and compose functionality elsewhere, but I leave that to you. The way it looks now it may end up recursive (young-heuristics->old-heuristics->old-heuristics->...-> etc)

src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 518:

> 516:   // precisely where the regulator is allowed to cancel a GC.
> 517:   ShenandoahOldGC gc(generation, _allow_old_preemption);
> 518: 

Lone whitespace change here.

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

> 127: void ShenandoahGeneration::prepare_gc() {
> 128:   reset_mark_bitmap();
> 129: 

Lone whitespace change here.

test/hotspot/jtreg/gc/shenandoah/generational/TestConcurrentEvac.java line 35:

> 33:  *  of old-gen GC passes is very simplistic.  A further shortcoming of the
> 34:  *  Generational Shenandoah as of introduction of this test is that it does
> 35:  *  currently support full GC.  If garbage collection falls behind mutator

You probably meant to say that it "does currently *not* support full GC"

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

Changes requested by rkennke (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/29

From iklam at openjdk.java.net  Tue Apr 13 02:09:12 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 13 Apr 2021 02:09:12 GMT
Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp
Message-ID: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>

oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers.

There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations.

According to https://github.com/iklam/tools/tree/main/headers


[before]

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

Commit messages:
 - fixed copyright year
 - removed unrelated changes
 - 8265103: Remove unnecessary inclusion of oopMap.hpp

Changes: https://git.openjdk.java.net/jdk/pull/3446/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3446&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265103
  Stats: 75 lines in 53 files changed: 58 ins; 4 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3446.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3446/head:pull/3446

PR: https://git.openjdk.java.net/jdk/pull/3446

From dholmes at openjdk.java.net  Tue Apr 13 04:08:58 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 13 Apr 2021 04:08:58 GMT
Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp
In-Reply-To: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
References: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
Message-ID: <NkKVlB0cPaHU2S2cGYMiHP1ihcBNCW-S1MzHXAT6c3s=.f99fd5a8-01bc-4a37-b61d-466c1034d323@github.com>

On Tue, 13 Apr 2021 01:55:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers.
> 
> There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations.
> 
> According to https://github.com/iklam/tools/tree/main/headers
> 
> 
> [before]

Seems okay.

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3446

From stefank at openjdk.java.net  Tue Apr 13 07:06:00 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 13 Apr 2021 07:06:00 GMT
Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp
In-Reply-To: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
References: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
Message-ID: <ORlEMTQAEushgD4HAG1se6MlIdBdv-JvAhZIn7CNl4I=.98e95b28-33ba-4895-b8d3-e26cc6c6585a@github.com>

On Tue, 13 Apr 2021 01:55:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers.
> 
> There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations.
> 
> According to https://github.com/iklam/tools/tree/main/headers
> 
> 
> [before]

Marked as reviewed by stefank (Reviewer).

src/hotspot/share/c1/c1_LinearScan.hpp line 34:

> 32: #include "c1/c1_LIR.hpp"
> 33: #include "c1/c1_LIRGenerator.hpp"
> 34: #include "compiler/oopMap.hpp"

The description states:
> There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations.

But this had to be added. Did you check how many files include c1_LinearScan.hpp?

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

PR: https://git.openjdk.java.net/jdk/pull/3446

From iklam at openjdk.java.net  Tue Apr 13 07:12:59 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 13 Apr 2021 07:12:59 GMT
Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp
In-Reply-To: <ORlEMTQAEushgD4HAG1se6MlIdBdv-JvAhZIn7CNl4I=.98e95b28-33ba-4895-b8d3-e26cc6c6585a@github.com>
References: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
 <ORlEMTQAEushgD4HAG1se6MlIdBdv-JvAhZIn7CNl4I=.98e95b28-33ba-4895-b8d3-e26cc6c6585a@github.com>
Message-ID: <QK7QKwMyRhaJDKSFo580nl7KH_5nzBG63xOjHKQlptE=.7eda7f38-0f2f-4e59-a460-a54d9315d810@github.com>

On Tue, 13 Apr 2021 07:02:34 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> The description states:
> 
> > There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations.
> 
> But this had to be added. Did you check how many files include c1_LinearScan.hpp?

c1_LinearScan.hpp is included in only 6 .o files.

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

PR: https://git.openjdk.java.net/jdk/pull/3446

From stefank at openjdk.java.net  Tue Apr 13 07:17:59 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Tue, 13 Apr 2021 07:17:59 GMT
Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp
In-Reply-To: <QK7QKwMyRhaJDKSFo580nl7KH_5nzBG63xOjHKQlptE=.7eda7f38-0f2f-4e59-a460-a54d9315d810@github.com>
References: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
 <ORlEMTQAEushgD4HAG1se6MlIdBdv-JvAhZIn7CNl4I=.98e95b28-33ba-4895-b8d3-e26cc6c6585a@github.com>
 <QK7QKwMyRhaJDKSFo580nl7KH_5nzBG63xOjHKQlptE=.7eda7f38-0f2f-4e59-a460-a54d9315d810@github.com>
Message-ID: <Dn1-2Vry5Hfxdks4VrU_tYejlgi59KGlIRGCoiZ202A=.79fb7c93-900b-472c-947a-c42bc91efb5c@github.com>

On Tue, 13 Apr 2021 07:09:55 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/c1/c1_LinearScan.hpp line 34:
>> 
>>> 32: #include "c1/c1_LIR.hpp"
>>> 33: #include "c1/c1_LIRGenerator.hpp"
>>> 34: #include "compiler/oopMap.hpp"
>> 
>> The description states:
>>> There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations.
>> 
>> But this had to be added. Did you check how many files include c1_LinearScan.hpp?
>
>> The description states:
>> 
>> > There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations.
>> 
>> But this had to be added. Did you check how many files include c1_LinearScan.hpp?
> 
> c1_LinearScan.hpp is included in only 6 .o files.

Great!

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

PR: https://git.openjdk.java.net/jdk/pull/3446

From bmathiske at openjdk.java.net  Tue Apr 13 21:10:41 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 13 Apr 2021 21:10:41 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions.
Message-ID: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>

Introducing a 3rd kind of LAB for generational mode: "PLAB".

(This PR is in draft form as testing is still ongoing.
Our smoke testing till flags a few unexpected crashes in generational mode.)

Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB. 

When not in generational mode, GCLABs work as before and PLABs are never used.

The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.

Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".

In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?

Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)

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

Commit messages:
 - Track proper affiliation when allocating.
 - Update region affiliation in full GC's "regular bypass".
 - Use PLABs for object promotions to old gen and for old gen evacuations.

Changes: https://git.openjdk.java.net/shenandoah/pull/30/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=30&range=00
  Stats: 312 lines in 15 files changed: 218 ins; 44 del; 50 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/30.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/30/head:pull/30

PR: https://git.openjdk.java.net/shenandoah/pull/30

From bmathiske at openjdk.java.net  Tue Apr 13 21:10:41 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 13 Apr 2021 21:10:41 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions.
In-Reply-To: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
Message-ID: <p_bm1DDUiMw1V5YxV6KBk24DCYqqy9qEXZi3N2_CTzI=.dc189049-7a8b-4ca8-a67a-aae4dbd689a5@github.com>

On Mon, 12 Apr 2021 19:50:45 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

> Introducing a 3rd kind of LAB for generational mode: "PLAB".
> 
> (This PR is in draft form as testing is still ongoing.
> Our smoke testing till flags a few unexpected crashes in generational mode.)
> 
> Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB. 
> 
> When not in generational mode, GCLABs work as before and PLABs are never used.
> 
> The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.
> 
> Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".
> 
> In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?
> 
> Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)

Every time I edit the description text to remove the part about being draft and testing, the GitHub bot edits it back. So, I declare here that the bugs in question at the time of opening the PR as draft have been fixed and that it is now ready for review, not in draft.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From github.com+71722661+earthling-amzn at openjdk.java.net  Tue Apr 13 21:10:46 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Tue, 13 Apr 2021 21:10:46 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions.
In-Reply-To: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
Message-ID: <j6lzsp8KOc8ktaxFBPrJyKVqzFyQOnRRzWU4ZQigiy8=.5a1bc6fa-db7c-45bd-9ca5-1db87af69da9@github.com>

On Mon, 12 Apr 2021 19:50:45 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

> Introducing a 3rd kind of LAB for generational mode: "PLAB".
> 
> (This PR is in draft form as testing is still ongoing.
> Our smoke testing till flags a few unexpected crashes in generational mode.)
> 
> Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB. 
> 
> When not in generational mode, GCLABs work as before and PLABs are never used.
> 
> The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.
> 
> Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".
> 
> In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?
> 
> Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)

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

> 145:             HeapWord *result = try_allocate_in(r, req, in_new_region);
> 146:             if (result != NULL) {
> 147:               if (r->is_old()) {

Sorry, it's not clear to me why we aren't concerned about pointers to young anymore?

src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 248:

> 246:         // We should revisit this.
> 247:         // Furthermore, the object start should be registered for remset scanning.
> 248:         MemRegion mr(cast_from_oop<HeapWord*>(result), result->size());

Don't we need this? The object going into the old region may have pointers to young that need to be scanned.

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

> 100:       do_commit();
> 101:     case _empty_committed:
> 102:       set_affiliation(YOUNG_GENERATION);

It's not clear to me why we would set the affiliation here. Do we know this region isn't going to be used for evacuations in old gen?

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From bmathiske at openjdk.java.net  Tue Apr 13 21:10:51 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 13 Apr 2021 21:10:51 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions.
In-Reply-To: <j6lzsp8KOc8ktaxFBPrJyKVqzFyQOnRRzWU4ZQigiy8=.5a1bc6fa-db7c-45bd-9ca5-1db87af69da9@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <j6lzsp8KOc8ktaxFBPrJyKVqzFyQOnRRzWU4ZQigiy8=.5a1bc6fa-db7c-45bd-9ca5-1db87af69da9@github.com>
Message-ID: <hclRkYkx__4isO1zNzECipNRsV_nVu6_iCXPU8LzJeo=.28a3ba41-2879-4a11-a3cb-30e51aea6017@github.com>

On Mon, 12 Apr 2021 20:48:32 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

>> Introducing a 3rd kind of LAB for generational mode: "PLAB".
>> 
>> (This PR is in draft form as testing is still ongoing.
>> Our smoke testing till flags a few unexpected crashes in generational mode.)
>> 
>> Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB. 
>> 
>> When not in generational mode, GCLABs work as before and PLABs are never used.
>> 
>> The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.
>> 
>> Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".
>> 
>> In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?
>> 
>> Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 147:
> 
>> 145:             HeapWord *result = try_allocate_in(r, req, in_new_region);
>> 146:             if (result != NULL) {
>> 147:               if (r->is_old()) {
> 
> Sorry, it's not clear to me why we aren't concerned about pointers to young anymore?

Not as long as no content has been written into such objects. Here we are merely allocating an object that does not have references yet. If the mutator gets to it afterwards to plant references into it, this will still be in young gen, so no remset action is required. The only way to make this object hold old->young references is by means of promotion. That's covered in try_evacuate_object() for normal-sized objects (see above). For humongous objects, it's supposed to be covered in the course of region promotion.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 248:
> 
>> 246:         // We should revisit this.
>> 247:         // Furthermore, the object start should be registered for remset scanning.
>> 248:         MemRegion mr(cast_from_oop<HeapWord*>(result), result->size());
> 
> Don't we need this? The object going into the old region may have pointers to young that need to be scanned.

We do need this, but not necessarily right here. I moved this close to where the object transitions, in try_evacuate_object. When a thread succeeds in moving the object there, its card is dirtied and it is registered right away. See line ~340, where it says "// Successfully evacuated. Our copy is now the public one!".

> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 102:
> 
>> 100:       do_commit();
>> 101:     case _empty_committed:
>> 102:       set_affiliation(YOUNG_GENERATION);
> 
> It's not clear to me why we would set the affiliation here. Do we know this region isn't going to be used for evacuations in old gen?

This is to fix full single-generational collections. But yes, not good enough in the long run. => I need to put a TODO note to remind us of later repairing proper full collections in generational mode.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From bmathiske at openjdk.java.net  Tue Apr 13 21:10:53 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 13 Apr 2021 21:10:53 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions.
In-Reply-To: <hclRkYkx__4isO1zNzECipNRsV_nVu6_iCXPU8LzJeo=.28a3ba41-2879-4a11-a3cb-30e51aea6017@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <j6lzsp8KOc8ktaxFBPrJyKVqzFyQOnRRzWU4ZQigiy8=.5a1bc6fa-db7c-45bd-9ca5-1db87af69da9@github.com>
 <hclRkYkx__4isO1zNzECipNRsV_nVu6_iCXPU8LzJeo=.28a3ba41-2879-4a11-a3cb-30e51aea6017@github.com>
Message-ID: <b-tXxWTHUaGUwk64JdwNdkXeCLDcjKeQR8J5XKIS8gg=.af1c7288-27f6-4f09-93ba-d92b15c1f49c@github.com>

On Mon, 12 Apr 2021 21:07:17 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 102:
>> 
>>> 100:       do_commit();
>>> 101:     case _empty_committed:
>>> 102:       set_affiliation(YOUNG_GENERATION);
>> 
>> It's not clear to me why we would set the affiliation here. Do we know this region isn't going to be used for evacuations in old gen?
>
> This is to fix full single-generational collections. But yes, not good enough in the long run. => I need to put a TODO note to remind us of later repairing proper full collections in generational mode.

There are two places like this one. This one here is actually a bug that affects regular concurrent collections and I am fixing it in the next commit that I just filed for this PR. 

The other place in the vicinity, in make_regular_bypass(), needs a TODO and I just added it. The text for it is taken from a similar place that needs to be fixed in a very similar way.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From kdnilsen at openjdk.java.net  Tue Apr 13 21:52:21 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 13 Apr 2021 21:52:21 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <oEB9y8xruB6iheT45U2YecmNBUt3KL_VAbi7vRFN0FU=.2acdf2d7-6b3a-45a5-9173-6e14276703f0@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <oEB9y8xruB6iheT45U2YecmNBUt3KL_VAbi7vRFN0FU=.2acdf2d7-6b3a-45a5-9173-6e14276703f0@github.com>
Message-ID: <NyeTJtddnkqS3kXlG9qbokOf7gCon2cCFvwgbGS9ro0=.2128a794-c405-45db-aa0c-5d8c39715337@github.com>

On Fri, 9 Apr 2021 13:18:13 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chasing bug during prepare_for_old_collection
>>   
>>   One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
>>   optimization error.
>
> src/hotspot/share/gc/shenandoah/shenandoahPhaseTimings.hpp line 67:
> 
>> 65:   f(finish_mark,                                    "  Finish Mark")                   \
>> 66:   SHENANDOAH_PAR_PHASE_DO(finish_mark_,             "    FM: ", f)                     \
>> 67:   f(coalesce_and_fill,                              "Coalesce and Fill Old Dead")      \
> 
> Does not seem to be used anywhere.

Is used in shenandoahOldGC.cpp:entry_coalesce_and_fill().

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From iklam at openjdk.java.net  Wed Apr 14 02:46:24 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 14 Apr 2021 02:46:24 GMT
Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp [v2]
In-Reply-To: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
References: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
Message-ID: <yKOLC1rMLCAhRIqEsYpCQnsyuPJo1pUHwNpnTD_XgyM=.e78cfb93-b17e-47e9-9743-52f347e3726f@github.com>

> oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers.
> 
> There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations.
> 
> According to https://github.com/iklam/tools/tree/main/headers
> 
> 
> [before]

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

 - Merge branch 'master' into 8265103-reduce-inclusion-oopMap.hpp
 - fixed copyright year
 - removed unrelated changes
 - 8265103: Remove unnecessary inclusion of oopMap.hpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3446/files
  - new: https://git.openjdk.java.net/jdk/pull/3446/files/80a7f91d..2ee7d02e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3446&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3446&range=00-01

  Stats: 8870 lines in 576 files changed: 4450 ins; 3988 del; 432 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3446.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3446/head:pull/3446

PR: https://git.openjdk.java.net/jdk/pull/3446

From iklam at openjdk.java.net  Wed Apr 14 05:15:02 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 14 Apr 2021 05:15:02 GMT
Subject: RFR: 8265103: Remove unnecessary inclusion of oopMap.hpp [v2]
In-Reply-To: <ORlEMTQAEushgD4HAG1se6MlIdBdv-JvAhZIn7CNl4I=.98e95b28-33ba-4895-b8d3-e26cc6c6585a@github.com>
References: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
 <ORlEMTQAEushgD4HAG1se6MlIdBdv-JvAhZIn7CNl4I=.98e95b28-33ba-4895-b8d3-e26cc6c6585a@github.com>
Message-ID: <k4wXDn4T6l8HfiaoFr0TB_e6Nf5rP3kCHRvRPZP-x5I=.8b577689-2d9a-4854-99e1-132bfd7ae882@github.com>

On Tue, 13 Apr 2021 07:02:39 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8265103-reduce-inclusion-oopMap.hpp
>>  - fixed copyright year
>>  - removed unrelated changes
>>  - 8265103: Remove unnecessary inclusion of oopMap.hpp
>
> Marked as reviewed by stefank (Reviewer).

Thanks @stefank and @dholmes-ora for the review.
Tested again with latest repo: mach5: tier1, builds-tier2, builds-tier3, builds-tier4 and builds-tier5. Also locally: aarch64, arm, ppc64, s390, x86, and zero.

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

PR: https://git.openjdk.java.net/jdk/pull/3446

From iklam at openjdk.java.net  Wed Apr 14 05:15:03 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 14 Apr 2021 05:15:03 GMT
Subject: Integrated: 8265103: Remove unnecessary inclusion of oopMap.hpp
In-Reply-To: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
References: <KHGpG9xCSAdQer-mTipO4pX4yzHbuQcake3OAPWT4vs=.c40ac67c-cf44-431b-8d23-c3984bd8b9c9@github.com>
Message-ID: <_jJ6m46xcXV6PufA-mdiz3NZeld5A_6TEfRd7tI0quE=.b7b0f583-793c-413b-bfa2-304a0a1a653a@github.com>

On Tue, 13 Apr 2021 01:55:13 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> oopMap.hpp is included by about 585 out of about 1000 .o files in HotSpot. In turn, it pulls in other complex headers such as vmreg.hpp, register.hpp and their cpu-dependent headers.
> 
> There are only 4 header files that include oopMap.hpp. All of these can be replaced for forward declarations.
> 
> According to https://github.com/iklam/tools/tree/main/headers
> 
> 
> [before]

This pull request has now been integrated.

Changeset: ea5c55a4
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ea5c55a4
Stats:     75 lines in 53 files changed: 58 ins; 4 del; 13 mod

8265103: Remove unnecessary inclusion of oopMap.hpp

Reviewed-by: dholmes, stefank

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

PR: https://git.openjdk.java.net/jdk/pull/3446

From kdnilsen at openjdk.java.net  Wed Apr 14 16:53:35 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 14 Apr 2021 16:53:35 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <oEB9y8xruB6iheT45U2YecmNBUt3KL_VAbi7vRFN0FU=.2acdf2d7-6b3a-45a5-9173-6e14276703f0@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <oEB9y8xruB6iheT45U2YecmNBUt3KL_VAbi7vRFN0FU=.2acdf2d7-6b3a-45a5-9173-6e14276703f0@github.com>
Message-ID: <ttfQrh-84NOzq2k0QYfWaff6MTRFa_8CLc1gzPmdrX0=.40ae48f0-04b6-47cf-812d-1cabca8025d1@github.com>

On Fri, 9 Apr 2021 12:57:30 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chasing bug during prepare_for_old_collection
>>   
>>   One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
>>   optimization error.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 439:
> 
>> 437:       // Instead, skip to the following marked object, as indicated by the first following mark bit in
>> 438:       // marking_context.
>> 439:       int size = obj->size();
> 
> I am not sure that it is safe to walk dead oops, e.g. their classes might have been unloaded. I suggest to use marking_context->get_next_marked_addr() instead.

I've fixed this now.

> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 510:
> 
>> 508:         // Instead, skip to the following marked object, as indicated by the first following mark bit in
>> 509:         // marking_context.
>> 510:         int size = obj->size();
> 
> Same as above

I've also fixed this now.

> src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp line 167:
> 
>> 165:   //
>> 166:   // TraceCollectorStats tcs(heap->monitoring_support()->concurrent_collection_counters());
>> 167:   // EventMark em("%s", msg);
> 
> Yes, I think we want them.

I've uncommented this so it is now included.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Wed Apr 14 16:53:30 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 14 Apr 2021 16:53:30 GMT
Subject: RFR: Mixed evacuation [v3]
In-Reply-To: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
Message-ID: <uJppySVTDvs8SWuM9qtJlDqCy8jY8K2ncbmd1ODpDNU=.f22c13d9-6317-469b-a13a-1821366d0cbd@github.com>

> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.

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

 - Add collector statistics tracking
   
   As requested by reviewer feedback for draft upstream pull request,
   ShenandoahOldGC::entry_coalesce_and_fill() now gathers additional
   collector statistics.
 - Improve coalesce and fill
   
   In old-gen memory ranges of HeapRegions not selected for collection,
   use marking_context->get_next_marked_addr() instead of visiting each unmarked
   object independently when deciding which ranges of memory to coalesce and
   fill.  This change builds and runs jtreg test=TIER1 and
   test=hotspot_gc_shenandoah wihtout regressions.
 - Fix trailing whitespace error and correct spelling errors in comment

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/29/files
  - new: https://git.openjdk.java.net/shenandoah/pull/29/files/50ffb169..76213506

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=01-02

  Stats: 71 lines in 3 files changed: 4 ins; 40 del; 27 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/29/head:pull/29

PR: https://git.openjdk.java.net/shenandoah/pull/29

From bmathiske at openjdk.java.net  Wed Apr 14 18:05:22 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Wed, 14 Apr 2021 18:05:22 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v2]
In-Reply-To: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
Message-ID: <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>

> Introducing a 3rd kind of LAB for generational mode: "PLAB".
> 
> Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB. 
> 
> When not in generational mode, GCLABs work as before and PLABs are never used.
> 
> The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.
> 
> Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".
> 
> In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?
> 
> Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)

Bernd Mathiske has updated the pull request incrementally with one additional commit since the last revision:

  Register filler objects for unsuccessful non-LAB evacuations.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/30/files
  - new: https://git.openjdk.java.net/shenandoah/pull/30/files/0f0005e7..583c2038

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=30&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=30&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/30.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/30/head:pull/30

PR: https://git.openjdk.java.net/shenandoah/pull/30

From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr 14 21:20:22 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 14 Apr 2021 21:20:22 GMT
Subject: RFR: Update remembered set during old generation mark
Message-ID: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>

This change is to support the concurrent remembered set scanning work which is in progress.

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

Commit messages:
 - Update remembered set during old generation mark

Changes: https://git.openjdk.java.net/shenandoah/pull/31/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=31&range=00
  Stats: 14 lines in 3 files changed: 14 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/31.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/31/head:pull/31

PR: https://git.openjdk.java.net/shenandoah/pull/31

From zgu at openjdk.java.net  Thu Apr 15 00:12:51 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 15 Apr 2021 00:12:51 GMT
Subject: RFR: 8265239: Shenandoah: Shenandoah heap region count could be 1
 short
Message-ID: <-8G7NK-sSvff9jC-zGGQBkkzO9rsoCv_B_tSDhoVlhA=.cbb907e0-f891-46db-af1a-0a2cf520eed4@github.com>

henandoah uses MaxHeapSize to calculate region size, then aligns up heap size to region size alignment, but when it calculates region count, it does not take alignment into account, that may result 1 region short than actual count.

MaxHeapSize eventually aligns to HeapAlignment (which is region size in Shenandoah case) in GCArguments::initialize_heap_flags_and_sizes(), but it is too late.

Test:
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - JDK-8265239

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

PR: https://git.openjdk.java.net/jdk/pull/3504

From kdnilsen at openjdk.java.net  Thu Apr 15 17:40:24 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Thu, 15 Apr 2021 17:40:24 GMT
Subject: RFR: Mixed evacuation [v4]
In-Reply-To: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
Message-ID: <kCOry99YTGuavawpvluzTZBgxMfMGyz1bD4qsmgYD18=.8d9d6959-e8a5-4e56-82b6-31dbd6101390@github.com>

> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.

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

  Refactor choose_collection_set
  
  Divide the implementation of ShenandoahHeuristic::choose_colection_set() into
  prepare_for_other_collection() and prime_collection_set_with_old_candiates() as
  requested by reviewer of draft pull request.  The resulting code passes TIER1 and
  hotspot_gc_shenandoah jtreg regressions and runs additional generational shenandoah
  stress tests.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/29/files
  - new: https://git.openjdk.java.net/shenandoah/pull/29/files/76213506..f6f6a734

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=02-03

  Stats: 328 lines in 2 files changed: 140 ins; 127 del; 61 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/29/head:pull/29

PR: https://git.openjdk.java.net/shenandoah/pull/29

From shade at openjdk.java.net  Fri Apr 16 07:45:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 16 Apr 2021 07:45:36 GMT
Subject: RFR: 8265239: Shenandoah: Shenandoah heap region count could be
 off by 1
In-Reply-To: <-8G7NK-sSvff9jC-zGGQBkkzO9rsoCv_B_tSDhoVlhA=.cbb907e0-f891-46db-af1a-0a2cf520eed4@github.com>
References: <-8G7NK-sSvff9jC-zGGQBkkzO9rsoCv_B_tSDhoVlhA=.cbb907e0-f891-46db-af1a-0a2cf520eed4@github.com>
Message-ID: <11iX8w9PWODsE9sTprWV7G7wDh1JGjmtY0UppsQJb50=.bfb8a717-b01f-425e-842e-be0858dc5e53@github.com>

On Thu, 15 Apr 2021 00:06:05 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> henandoah uses MaxHeapSize to calculate region size, then aligns up heap size to region size alignment, but when it calculates region count, it does not take alignment into account, that may result 1 region short than actual count.
> 
> MaxHeapSize eventually aligns to HeapAlignment (which is region size in Shenandoah case) in GCArguments::initialize_heap_flags_and_sizes(), but it is too late.
> 
> Test:
> - [x] hotspot_gc_shenandoah

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3504

From zgu at openjdk.java.net  Fri Apr 16 12:30:36 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 16 Apr 2021 12:30:36 GMT
Subject: Integrated: 8265239: Shenandoah: Shenandoah heap region count could
 be off by 1
In-Reply-To: <-8G7NK-sSvff9jC-zGGQBkkzO9rsoCv_B_tSDhoVlhA=.cbb907e0-f891-46db-af1a-0a2cf520eed4@github.com>
References: <-8G7NK-sSvff9jC-zGGQBkkzO9rsoCv_B_tSDhoVlhA=.cbb907e0-f891-46db-af1a-0a2cf520eed4@github.com>
Message-ID: <kzOpaZR3uRykuwjM7rbpFxk7quhpz04AprW7a5qyiYg=.07f18378-3067-4923-bc94-0e25fbf3cda7@github.com>

On Thu, 15 Apr 2021 00:06:05 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> henandoah uses MaxHeapSize to calculate region size, then aligns up heap size to region size alignment, but when it calculates region count, it does not take alignment into account, that may result 1 region short than actual count.
> 
> MaxHeapSize eventually aligns to HeapAlignment (which is region size in Shenandoah case) in GCArguments::initialize_heap_flags_and_sizes(), but it is too late.
> 
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: ff5bb8cf
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff5bb8cf
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8265239: Shenandoah: Shenandoah heap region count could be off by 1

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/jdk/pull/3504

From rkennke at openjdk.java.net  Fri Apr 16 14:18:58 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 16 Apr 2021 14:18:58 GMT
Subject: RFR: Mixed evacuation [v4]
In-Reply-To: <kCOry99YTGuavawpvluzTZBgxMfMGyz1bD4qsmgYD18=.8d9d6959-e8a5-4e56-82b6-31dbd6101390@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <kCOry99YTGuavawpvluzTZBgxMfMGyz1bD4qsmgYD18=.8d9d6959-e8a5-4e56-82b6-31dbd6101390@github.com>
Message-ID: <l-1wN5BXsRDP2dAm72zTLwBDDVALzw7Q0FqpmmkpZdw=.89a95652-931e-41bf-982d-47a60ac1dbec@github.com>

On Thu, 15 Apr 2021 17:40:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor choose_collection_set
>   
>   Divide the implementation of ShenandoahHeuristic::choose_colection_set() into
>   prepare_for_other_collection() and prime_collection_set_with_old_candiates() as
>   requested by reviewer of draft pull request.  The resulting code passes TIER1 and
>   hotspot_gc_shenandoah jtreg regressions and runs additional generational shenandoah
>   stress tests.

I am thinking about how to better design the heuristics so to avoid pollution of every single heuristic with a reference to (possibly non-existing) old-gen heuristic. How about this:
- In the base ShenandoahHeuristic add a virtual and empty prime_collection_set() that is called where the block if (_old_heuristics != NULL) { prime_collection_set_with_old_candidates(); } is now.
- Leave all heuristics untouched and also don't introduce a new reference _old_heuristics. Instead:
- Add a new heuristic e.g. ShenandoahGenerationalHeuristic that has pointers to two other heuristics: one for each new-gen and old-gen. Override all relevant methods to delegate to new-gen-heuristics, and implement prime_collection_set() to implement what you're proposing here already. In other words, this heuristic would be mostly composite of old and new gen heuristic.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From zgu at openjdk.java.net  Fri Apr 16 14:34:58 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 16 Apr 2021 14:34:58 GMT
Subject: RFR: 8265348: Shenandoah: Use timed wait to sleep control thread
Message-ID: <oCVNap8yntE9qYmYshpcuSEVX6VJjfOAwkSmHkQ5MFg=.c7783937-34f1-410c-a7ae-0f4274971970@github.com>

I would like to bring the patch with the same synopsis from Shenandoah repo [1] to mainline, it should help what I am working on. 

Test:
- [x] hotspot_gc_shenandoah 

[1] https://github.com/openjdk/shenandoah/pull/28

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

Commit messages:
 - Merge branch 'master' into JDK-8265348-control-timed-wait
 - init

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

PR: https://git.openjdk.java.net/jdk/pull/3547

From zgu at openjdk.java.net  Fri Apr 16 14:34:58 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 16 Apr 2021 14:34:58 GMT
Subject: RFR: 8265348: Shenandoah: Use timed wait to sleep control thread
In-Reply-To: <oCVNap8yntE9qYmYshpcuSEVX6VJjfOAwkSmHkQ5MFg=.c7783937-34f1-410c-a7ae-0f4274971970@github.com>
References: <oCVNap8yntE9qYmYshpcuSEVX6VJjfOAwkSmHkQ5MFg=.c7783937-34f1-410c-a7ae-0f4274971970@github.com>
Message-ID: <_TC5a8CZBDq0pyz6GGxnIV9GPRZ285V1c-X-NL8KYyQ=.c37015fc-8851-498c-810d-3e387341105c@github.com>

On Fri, 16 Apr 2021 14:27:29 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to bring the patch with the same synopsis from Shenandoah repo [1] to mainline, it should help what I am working on. 
> 
> Test:
> - [x] hotspot_gc_shenandoah 
> 
> [1] https://github.com/openjdk/shenandoah/pull/28

add author @earthling-amzn

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

PR: https://git.openjdk.java.net/jdk/pull/3547

From rkennke at openjdk.java.net  Fri Apr 16 14:40:53 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 16 Apr 2021 14:40:53 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v2]
In-Reply-To: <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>
Message-ID: <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>

On Wed, 14 Apr 2021 18:05:22 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

>> Introducing a 3rd kind of LAB for generational mode: "PLAB".
>> 
>> Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB. 
>> 
>> When not in generational mode, GCLABs work as before and PLABs are never used.
>> 
>> The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.
>> 
>> Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".
>> 
>> In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?
>> 
>> Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)
>
> Bernd Mathiske has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Register filler objects for unsuccessful non-LAB evacuations.

Nice progress! I have a few questions/comments.

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

> 123:       result = allocate_with_affiliation(FREE, req, in_new_region);
> 124:       if (result != NULL) {
> 125:         return result;

I am not sure about this. What must not happen here is that we mix new allocations and evacuations into the same region. That is because we need to update references in evacuated objects later, but not for new objects (we're guaranteed to only store to-space refs into new objects). I guess it's similar for promotions: we do need to update refs in promoted objects. That means we can mix promotions and evacuations, but cannot mix either of them with new allocations. Can you clarify this?

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

> 428: 
> 429:   assert(r->is_empty(), "Region must be empty after flipping from mutator to GC.");
> 430:   r->set_affiliation(FREE);

Why is this block needed now?

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

> 880:   return plab->allocate(size);
> 881: }
> 882: 

Is this a full (or almost full) copy of allocate_from_gclab_slow() ? Maybe this warrants some refactoring/sharing?

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From kdnilsen at openjdk.java.net  Fri Apr 16 14:41:02 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 16 Apr 2021 14:41:02 GMT
Subject: RFR: Mixed evacuation [v4]
In-Reply-To: <kCOry99YTGuavawpvluzTZBgxMfMGyz1bD4qsmgYD18=.8d9d6959-e8a5-4e56-82b6-31dbd6101390@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <kCOry99YTGuavawpvluzTZBgxMfMGyz1bD4qsmgYD18=.8d9d6959-e8a5-4e56-82b6-31dbd6101390@github.com>
Message-ID: <uUzTGCagRg8Yy7SrvJot9CF71QYj77fR-LOLCMU0IyY=.c0e322b9-ba74-49ad-b3ad-c82b80cf5e1d@github.com>

On Thu, 15 Apr 2021 17:40:24 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor choose_collection_set
>   
>   Divide the implementation of ShenandoahHeuristic::choose_colection_set() into
>   prepare_for_other_collection() and prime_collection_set_with_old_candiates() as
>   requested by reviewer of draft pull request.  The resulting code passes TIER1 and
>   hotspot_gc_shenandoah jtreg regressions and runs additional generational shenandoah
>   stress tests.

Was actually in the middle of doing something similar to this.  I can redirect towards your solution or continue with the one I am working on.   Here's how mine differs from yours:

1. I would introduce a subclass of ShenandoahHeuristics to be called ShenandoahOldHeuristics.  This would hold all the new methods that are specific to old-generation heuristics, currently added to ShenandoahHeuristics: prime_collection_set()  (renamed from prime_collection_set_with_old_candidates), prepare_for_old_collection(), start_old_evacuations(), unprocessed_old_collection_candidates(), next_old_collection_candidates(), consume_old_collection_candidate(), old_coalesce_and_fill_candidates(), get_coalesce_and_fill_candidates(), should_defer_gc()
2. I would pass a new ShenandoahOldHeuristics* old_heuristics argument to choose_collection_set() (possibly null in the case that we are doing GLOBAL - non-generation GC) and this argument would be passed down into prepare_for_other_collection().
3. I would hoist the check for should_defer_gc() into ShenandoahRegulatorThread::start_old_cycle() so that we don't have to "pollute" all the existing heuristics with this test.

As with your proposal, there would no longer be a _old_heuristics field within ShenandoahHeuristics.  This is why I have to pass in the new old_heuristics argument to the invocation of choose_collection_set().

Are you ok with this approach?

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From rkennke at openjdk.java.net  Fri Apr 16 14:43:59 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 16 Apr 2021 14:43:59 GMT
Subject: RFR: Update remembered set during old generation mark
In-Reply-To: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>
References: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>
Message-ID: <Vpcn9Lvf5Z7vH2VlO76QqHatIy9jwaO6_qsnx9arxss=.d4e40021-13b6-4f00-8ad6-949457f4a25f@github.com>

On Wed, 14 Apr 2021 21:15:10 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> This change is to support the concurrent remembered set scanning work which is in progress.

Looks good to me. Thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/31

From shade at openjdk.java.net  Fri Apr 16 14:58:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 16 Apr 2021 14:58:39 GMT
Subject: RFR: 8265348: Shenandoah: Use timed wait to sleep control thread
In-Reply-To: <oCVNap8yntE9qYmYshpcuSEVX6VJjfOAwkSmHkQ5MFg=.c7783937-34f1-410c-a7ae-0f4274971970@github.com>
References: <oCVNap8yntE9qYmYshpcuSEVX6VJjfOAwkSmHkQ5MFg=.c7783937-34f1-410c-a7ae-0f4274971970@github.com>
Message-ID: <fQeKMAwHDXxKswcqKEQ8ThdiP7OtMSyJ-xLcdOLJ1fQ=.6fe2f53b-8f71-4e83-8cc6-221b8ec93b0d@github.com>

On Fri, 16 Apr 2021 14:27:29 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to bring the patch with the same synopsis from Shenandoah repo [1] to mainline, it should help what I am working on. 
> 
> Test:
> - [x] hotspot_gc_shenandoah 
> 
> [1] https://github.com/openjdk/shenandoah/pull/28

Wait, there are questions about lock ranking. I wanted to address it in https://bugs.openjdk.java.net/browse/JDK-8264851.

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

PR: https://git.openjdk.java.net/jdk/pull/3547

From zgu at openjdk.java.net  Fri Apr 16 15:14:34 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 16 Apr 2021 15:14:34 GMT
Subject: Withdrawn: 8265348: Shenandoah: Use timed wait to sleep control thread
In-Reply-To: <oCVNap8yntE9qYmYshpcuSEVX6VJjfOAwkSmHkQ5MFg=.c7783937-34f1-410c-a7ae-0f4274971970@github.com>
References: <oCVNap8yntE9qYmYshpcuSEVX6VJjfOAwkSmHkQ5MFg=.c7783937-34f1-410c-a7ae-0f4274971970@github.com>
Message-ID: <kzeyBD5zgDnRiCx85wIq_DT50yZQFL1oGh4fvRZFDcQ=.b9987702-85fd-431e-95ac-fc71acfe9786@github.com>

On Fri, 16 Apr 2021 14:27:29 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> I would like to bring the patch with the same synopsis from Shenandoah repo [1] to mainline, it should help what I am working on. 
> 
> Test:
> - [x] hotspot_gc_shenandoah 
> 
> [1] https://github.com/openjdk/shenandoah/pull/28

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/3547

From zgu at openjdk.java.net  Fri Apr 16 15:14:34 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 16 Apr 2021 15:14:34 GMT
Subject: RFR: 8265348: Shenandoah: Use timed wait to sleep control thread
In-Reply-To: <fQeKMAwHDXxKswcqKEQ8ThdiP7OtMSyJ-xLcdOLJ1fQ=.6fe2f53b-8f71-4e83-8cc6-221b8ec93b0d@github.com>
References: <oCVNap8yntE9qYmYshpcuSEVX6VJjfOAwkSmHkQ5MFg=.c7783937-34f1-410c-a7ae-0f4274971970@github.com>
 <fQeKMAwHDXxKswcqKEQ8ThdiP7OtMSyJ-xLcdOLJ1fQ=.6fe2f53b-8f71-4e83-8cc6-221b8ec93b0d@github.com>
Message-ID: <KaLiVtUw9hNn76rufOStHViA85a0fzuz-AEbvAs3mVQ=.9d447cfb-0905-4e68-a360-6ab782477bb7@github.com>

On Fri, 16 Apr 2021 14:55:51 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Wait, there are questions about lock ranking. I wanted to address it in https://bugs.openjdk.java.net/browse/JDK-8264851.

I did not realize JDK-8264851. I am closing this as duplicate.

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

PR: https://git.openjdk.java.net/jdk/pull/3547

From github.com+71722661+earthling-amzn at openjdk.java.net  Fri Apr 16 15:21:00 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Fri, 16 Apr 2021 15:21:00 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v2]
In-Reply-To: <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>
 <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
Message-ID: <3E8adrsU2sm95tr7-mZsDXNMjVaaktgq9P3us0ohjJ0=.dd254c86-0459-4e3e-932d-4db626e04133@github.com>

On Fri, 16 Apr 2021 14:28:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Bernd Mathiske has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Register filler objects for unsuccessful non-LAB evacuations.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 430:
> 
>> 428: 
>> 429:   assert(r->is_empty(), "Region must be empty after flipping from mutator to GC.");
>> 430:   r->set_affiliation(FREE);
> 
> Why is this block needed now?

I think this could be an assert. The region should already be `FREE` at this point.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From github.com+71722661+earthling-amzn at openjdk.java.net  Fri Apr 16 15:36:00 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Fri, 16 Apr 2021 15:36:00 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
Message-ID: <rezRKKkjmfyMvxt-aBTQRAFxP7YhNwZd7693uxirkkc=.bbcc4b48-7d8e-450b-9ce2-8749787a7e5e@github.com>

On Mon, 12 Apr 2021 19:47:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chasing bug during prepare_for_old_collection
>>   
>>   One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
>>   optimization error.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 475:
> 
>> 473: 
>> 474:   // This loop is written as while rather than for because of
>> 475:   // suspected gcc error in translating/optimizing for-loop
> 
> WTF, really? Do we have any indication of this?

We will remove this comment. We saw some pretty strange behavior while debugging, but it turned out to be a bug in `rr`.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From rkennke at openjdk.java.net  Fri Apr 16 16:37:59 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 16 Apr 2021 16:37:59 GMT
Subject: RFR: Mixed evacuation [v4]
In-Reply-To: <uUzTGCagRg8Yy7SrvJot9CF71QYj77fR-LOLCMU0IyY=.c0e322b9-ba74-49ad-b3ad-c82b80cf5e1d@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <kCOry99YTGuavawpvluzTZBgxMfMGyz1bD4qsmgYD18=.8d9d6959-e8a5-4e56-82b6-31dbd6101390@github.com>
 <uUzTGCagRg8Yy7SrvJot9CF71QYj77fR-LOLCMU0IyY=.c0e322b9-ba74-49ad-b3ad-c82b80cf5e1d@github.com>
Message-ID: <yp5koSkK7RFZRUZprIIXhhl-5w835zvOmbknCSWkaJc=.34b052f7-caf4-4ff0-8036-27963e19e50e@github.com>

On Fri, 16 Apr 2021 14:38:10 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> Was actually in the middle of doing something similar to this. I can redirect towards your solution or continue with the one I am working on. Here's how mine differs from yours:
> 
>     1. I would introduce a subclass of ShenandoahHeuristics to be called ShenandoahOldHeuristics.  This would hold all the new methods that are specific to old-generation heuristics, currently added to ShenandoahHeuristics: prime_collection_set()  (renamed from prime_collection_set_with_old_candidates), prepare_for_old_collection(), start_old_evacuations(), unprocessed_old_collection_candidates(), next_old_collection_candidates(), consume_old_collection_candidate(), old_coalesce_and_fill_candidates(), get_coalesce_and_fill_candidates(), should_defer_gc()
> 
>     2. I would pass a new ShenandoahOldHeuristics* old_heuristics argument to choose_collection_set() (possibly null in the case that we are doing GLOBAL - non-generation GC) and this argument would be passed down into prepare_for_other_collection().
> 
>     3. I would hoist the check for should_defer_gc() into ShenandoahRegulatorThread::start_old_cycle() so that we don't have to "pollute" all the existing heuristics with this test.
> 
> 
> As with your proposal, there would no longer be a _old_heuristics field within ShenandoahHeuristics. This is why I have to pass in the new old_heuristics argument to the invocation of choose_collection_set().
> 
> Are you ok with this approach?

That sounds reasonable. Go for it.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From github.com+44619194+bmathiske at openjdk.java.net  Fri Apr 16 17:50:58 2021
From: github.com+44619194+bmathiske at openjdk.java.net (bmathiske)
Date: Fri, 16 Apr 2021 17:50:58 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v2]
In-Reply-To: <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>
 <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
Message-ID: <RJb-UL_qLYKokXx58bupXifpEIGIVlF7RjnEVvtTunI=.e5cdb6dd-6bdf-4867-9374-a6056e827792@github.com>

On Fri, 16 Apr 2021 14:31:32 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Bernd Mathiske has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Register filler objects for unsuccessful non-LAB evacuations.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 882:
> 
>> 880:   return plab->allocate(size);
>> 881: }
>> 882: 
> 
> Is this a full (or almost full) copy of allocate_from_gclab_slow() ? Maybe this warrants some refactoring/sharing?

Yes, this is a full copy. Will refactor.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From bmathiske at openjdk.java.net  Fri Apr 16 19:07:04 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Fri, 16 Apr 2021 19:07:04 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v2]
In-Reply-To: <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>
 <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
Message-ID: <BqMf7Gm5HaaenmVvMLWvlnrqsv6YnZppNZ-21w4lVRE=.59586ce5-b3f4-428b-a477-837e92808afa@github.com>

On Fri, 16 Apr 2021 14:26:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Bernd Mathiske has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Register filler objects for unsuccessful non-LAB evacuations.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 125:
> 
>> 123:       result = allocate_with_affiliation(FREE, req, in_new_region);
>> 124:       if (result != NULL) {
>> 125:         return result;
> 
> I am not sure about this. What must not happen here is that we mix new allocations and evacuations into the same region. That is because we need to update references in evacuated objects later, but not for new objects (we're guaranteed to only store to-space refs into new objects). I guess it's similar for promotions: we do need to update refs in promoted objects. That means we can mix promotions and evacuations, but cannot mix either of them with new allocations. Can you clarify this?

There is no mixing between new allocations and evacuations or promotions, because new allocations are handled in the separate switch cases _alloc_tlab and _alloc_shared, only using the mutator view. Here we use the GC view (except for overflow into trash/empty mutator regions that get "flipped").

Even though from an old gen perspective promotions are "incoming allocations", they bypass the to-space invariant by copying object content without passing barriers. In that they are in the same boat/region/PLAB with evacuations from old gen to old gen. Yes, they also need to be processed by update-refs. And we mix them in PLABs, just as we already did in case _alloc_shared_gc.

allocate_with_affiliation() is introduced for separating the hunt for a suitable region in the same generation from the hunt for a free region. Instead of taking whichever comes first, we now attempt to fit into a non-free region first. I can undo this if there is a good reason to not try to pack existing non-free regions first.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From kdnilsen at openjdk.java.net  Mon Apr 19 21:06:06 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 19 Apr 2021 21:06:06 GMT
Subject: RFR: Mixed evacuation [v5]
In-Reply-To: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
Message-ID: <bM-4rpf7GIEiJesxFRkmebHO1lrJVT7cEnwfV1oJcz8=.a2a8eb6c-7795-47c9-8e77-d433f190b0ef@github.com>

> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.

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

  Refactor ShenandoahOldHeuristics
  
  Code reviewers of the draft mixed-evacuation pull request raised a concern
  about entanglement between young-gen and old-gen heuristics.  In response to
  suggestions by reviewers, this patch refactors the old-gen heuristics
  implementation as follows:
  
  1. Add old_heuristics argument and pass it so we no longer depend on
     _old_heuristics field.
  
     Done, tested with run-milestone8-github, "make test TEST=tier1" and
     "make test TEST=hotspot_gc_shenandoah"
  
  2. Hoist test for should_defer_gc() into
     ShenandoahRegulatorThread::start_old_cycle().  Remove all other
     invocations of should_defer_gc().
  
     Done, tested with run-milestone8-github, "make test TEST=tier1" and
     "make test TEST=hotspot_gc_shenandoah"
  
  3. Remove _old_heuristics field and constructor and initializer
     argument from ShenandoahPassiveHeuristics,
     ShenandoahStaticHeuristics, ShenandoahAdaptiveHeuristics,
     ShenandoahAggresiveHeuristics,
     ShenandoahMode::initialize_heuristics(),
     ShenandoahPassiveMode:::initialize_heuristics(),
     ShenandoahGeneration::initialize_heuristics().
  
     Done, tested with run-milestone8-github, "make test TEST=tier1" and
     "make test TEST=hotspot_gc_shenandoah".  Note that GC behavior
     changed a little in run-milestone8-github.  Without confirmed
     review of output files, my impression is that full GC triggered
     earlier, at GC(101), and piggyback collections each processed fewer
     old-gen candidates (18 rather than 30).
  
  4. Introduce a new ShenandoahOldHeuristics subclass of
     ShenandoahHeuristics.  Move certain old-gen specific methods there,
     including: prime_collection_set() (renamed from
     prime_collection_set_with_old_candidates()),
     prepare_for_old_collection(), start_old_evacuations(),
     unprocessed_old_collection_candidates(),
     next_old_collection_candidates(),
     consume_old_collection_candidates(),
     old_coalesce_and_fill_candidates(),
     get_coalesce_and_fill_candidates(), should_defer_gc().
     Remove the _old_heuristics argument from prime_collection_set() and
     prepare_for_old_collection(); adjust the invocations.
  
  5. Make the following subclasses of ShenandoahOldHeuristics.  In the
     initial implementation, these subclasses have the same behavior
     as the young-gen heuristics from which they were copied.  Future
     refinement may result in tailored behavior of the old-gen
     versions of each heuristic: ShenandoahAdaptiveOldHeuristics,
     ShenandoahAggresiveOldHeuristics, ShenandoahCompactHeuristics,
     ShenandoahPassiveOldHeuristics, ShenandoahStaticOldHeuristics.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/29/files
  - new: https://git.openjdk.java.net/shenandoah/pull/29/files/f6f6a734..c883f237

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=03-04

  Stats: 1842 lines in 34 files changed: 1402 ins; 396 del; 44 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/29/head:pull/29

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Mon Apr 19 21:11:32 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 19 Apr 2021 21:11:32 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
Message-ID: <q9O2ECRWbNY4gBCv-21jq33qU__apxTUst5Rh7lO9XU=.b1bc38e3-8d41-4117-933a-94bad5939555@github.com>

On Mon, 12 Apr 2021 19:41:17 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chasing bug during prepare_for_old_collection
>>   
>>   One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
>>   optimization error.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 92:
> 
>> 90:     prepare_for_old_collections();
>> 91:   } else {
>> 92:     ShenandoahHeap* heap = ShenandoahHeap::heap();
> 
> I'd factor out the whole else block here to call prepare_for_young_collection() or whatever is fitting there.

I've refactored this code.  This comment is no longer relevant.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Mon Apr 19 21:19:31 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 19 Apr 2021 21:19:31 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
Message-ID: <ZOcFkQ-KMwd4tWDX5Rbw-0tO_oszTBIno-EoVF-UFqQ=.86f29530-d69a-4cf5-be8b-3499d2e7ef60@github.com>

On Mon, 12 Apr 2021 19:53:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chasing bug during prepare_for_old_collection
>>   
>>   One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
>>   optimization error.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 80:
> 
>> 78: // For expediency, we'll have a single class that is a "union" of
>> 79: // necessary functionality.
>> 80: 
> 
> Hmmhmm, this seems a suboptimal design. My intuition would have been to not have each heuristic need to know about any old heuristic, but keep them separate, and compose functionality elsewhere, but I leave that to you. The way it looks now it may end up recursive (young-heuristics->old-heuristics->old-heuristics->...-> etc)

This has been addressed with recently committed refactoring of ShenandoahOldHeuristics and subclasses.

> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 518:
> 
>> 516:   // precisely where the regulator is allowed to cancel a GC.
>> 517:   ShenandoahOldGC gc(generation, _allow_old_preemption);
>> 518: 
> 
> Lone whitespace change here.

To be fixed in next commit

> test/hotspot/jtreg/gc/shenandoah/generational/TestConcurrentEvac.java line 35:
> 
>> 33:  *  of old-gen GC passes is very simplistic.  A further shortcoming of the
>> 34:  *  Generational Shenandoah as of introduction of this test is that it does
>> 35:  *  currently support full GC.  If garbage collection falls behind mutator
> 
> You probably meant to say that it "does currently *not* support full GC"

You are right.  Will be corrected in next commit.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Mon Apr 19 21:27:23 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 19 Apr 2021 21:27:23 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
Message-ID: <mwZyO_0VaHhMn7TT1H5ZJLs7Q5ZRxBzV-hkFbjqOz9U=.70898d22-120a-4866-9598-bc90caa7657f@github.com>

On Mon, 12 Apr 2021 19:43:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chasing bug during prepare_for_old_collection
>>   
>>   One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
>>   optimization error.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 440:
> 
>> 438:   return (_generation->generation_mode() == GLOBAL)
>> 439:     || (_generation->generation_mode() == YOUNG && region->affiliation() == YOUNG_GENERATION)
>> 440:     || (_generation->generation_mode() == OLD && region->affiliation() == OLD_GENERATION);
> 
> I wouldn't change indentation here, or if it needs changing, then line up the || with the _generation above. Iow, shift it 4 spaces to the right instead of 2 spaces to the left.

I think I've fixed this now.  Auto-indent of my editor got carried away and I apparently lost track of original spacing.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 454:
> 
>> 452:   for (size_t i = 0; i < num_regions; i++) {
>> 453:     ShenandoahHeapRegion* region = heap->get_region(i);
>> 454:     if (!in_generation(region))
> 
> Please always use { and } in if (and else) constructs.

Ok.  Fixed.  (This code moved to shenadoahOldHeuristics.cpp)

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Mon Apr 19 21:27:24 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 19 Apr 2021 21:27:24 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <rezRKKkjmfyMvxt-aBTQRAFxP7YhNwZd7693uxirkkc=.bbcc4b48-7d8e-450b-9ce2-8749787a7e5e@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
 <rezRKKkjmfyMvxt-aBTQRAFxP7YhNwZd7693uxirkkc=.bbcc4b48-7d8e-450b-9ce2-8749787a7e5e@github.com>
Message-ID: <MTalFJit8vxb-XsxGi_PPO78X9YEdcUubbert_qMVDw=.974e041a-bdce-4cf1-8c9c-e33e20b5b163@github.com>

On Fri, 16 Apr 2021 15:33:25 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 475:
>> 
>>> 473: 
>>> 474:   // This loop is written as while rather than for because of
>>> 475:   // suspected gcc error in translating/optimizing for-loop
>> 
>> WTF, really? Do we have any indication of this?
>
> We will remove this comment. We saw some pretty strange behavior while debugging, but it turned out to be a bug in `rr`.

Comment will be gone in next commit.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Mon Apr 19 21:38:38 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 19 Apr 2021 21:38:38 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <ZOcFkQ-KMwd4tWDX5Rbw-0tO_oszTBIno-EoVF-UFqQ=.86f29530-d69a-4cf5-be8b-3499d2e7ef60@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
 <ZOcFkQ-KMwd4tWDX5Rbw-0tO_oszTBIno-EoVF-UFqQ=.86f29530-d69a-4cf5-be8b-3499d2e7ef60@github.com>
Message-ID: <rm4YkZ_w_5ItvuH-dRCfaZBBzyV6tvAM9WBBoOypAMY=.d3b2ab99-0dff-4f6a-a805-824db2a4f867@github.com>

On Mon, 19 Apr 2021 21:17:28 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 80:
>> 
>>> 78: // For expediency, we'll have a single class that is a "union" of
>>> 79: // necessary functionality.
>>> 80: 
>> 
>> Hmmhmm, this seems a suboptimal design. My intuition would have been to not have each heuristic need to know about any old heuristic, but keep them separate, and compose functionality elsewhere, but I leave that to you. The way it looks now it may end up recursive (young-heuristics->old-heuristics->old-heuristics->...-> etc)
>
> This has been addressed with recently committed refactoring of ShenandoahOldHeuristics and subclasses.

This has been addressed with recently pushed refactoring of ShenandoahOldHeuristics and subclasses.

>> src/hotspot/share/gc/shenandoah/shenandoahControlThread.cpp line 518:
>> 
>>> 516:   // precisely where the regulator is allowed to cancel a GC.
>>> 517:   ShenandoahOldGC gc(generation, _allow_old_preemption);
>>> 518: 
>> 
>> Lone whitespace change here.
>
> To be fixed in next commit

Removed this blank line.

>> test/hotspot/jtreg/gc/shenandoah/generational/TestConcurrentEvac.java line 35:
>> 
>>> 33:  *  of old-gen GC passes is very simplistic.  A further shortcoming of the
>>> 34:  *  Generational Shenandoah as of introduction of this test is that it does
>>> 35:  *  currently support full GC.  If garbage collection falls behind mutator
>> 
>> You probably meant to say that it "does currently *not* support full GC"
>
> You are right.  Will be corrected in next commit.

Yes.  Corrected.  Thanks.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Mon Apr 19 21:38:39 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Mon, 19 Apr 2021 21:38:39 GMT
Subject: RFR: Mixed evacuation [v5]
In-Reply-To: <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
Message-ID: <wPfSG6Q99dVfZhD1fkUQ1ZKiplo8qrP77PO2ZfVPONA=.90704cde-6bef-446d-a354-e009942d5db3@github.com>

On Mon, 12 Apr 2021 19:55:48 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor ShenandoahOldHeuristics
>>   
>>   Code reviewers of the draft mixed-evacuation pull request raised a concern
>>   about entanglement between young-gen and old-gen heuristics.  In response to
>>   suggestions by reviewers, this patch refactors the old-gen heuristics
>>   implementation as follows:
>>   
>>   1. Add old_heuristics argument and pass it so we no longer depend on
>>      _old_heuristics field.
>>   
>>      Done, tested with run-milestone8-github, "make test TEST=tier1" and
>>      "make test TEST=hotspot_gc_shenandoah"
>>   
>>   2. Hoist test for should_defer_gc() into
>>      ShenandoahRegulatorThread::start_old_cycle().  Remove all other
>>      invocations of should_defer_gc().
>>   
>>      Done, tested with run-milestone8-github, "make test TEST=tier1" and
>>      "make test TEST=hotspot_gc_shenandoah"
>>   
>>   3. Remove _old_heuristics field and constructor and initializer
>>      argument from ShenandoahPassiveHeuristics,
>>      ShenandoahStaticHeuristics, ShenandoahAdaptiveHeuristics,
>>      ShenandoahAggresiveHeuristics,
>>      ShenandoahMode::initialize_heuristics(),
>>      ShenandoahPassiveMode:::initialize_heuristics(),
>>      ShenandoahGeneration::initialize_heuristics().
>>   
>>      Done, tested with run-milestone8-github, "make test TEST=tier1" and
>>      "make test TEST=hotspot_gc_shenandoah".  Note that GC behavior
>>      changed a little in run-milestone8-github.  Without confirmed
>>      review of output files, my impression is that full GC triggered
>>      earlier, at GC(101), and piggyback collections each processed fewer
>>      old-gen candidates (18 rather than 30).
>>   
>>   4. Introduce a new ShenandoahOldHeuristics subclass of
>>      ShenandoahHeuristics.  Move certain old-gen specific methods there,
>>      including: prime_collection_set() (renamed from
>>      prime_collection_set_with_old_candidates()),
>>      prepare_for_old_collection(), start_old_evacuations(),
>>      unprocessed_old_collection_candidates(),
>>      next_old_collection_candidates(),
>>      consume_old_collection_candidates(),
>>      old_coalesce_and_fill_candidates(),
>>      get_coalesce_and_fill_candidates(), should_defer_gc().
>>      Remove the _old_heuristics argument from prime_collection_set() and
>>      prepare_for_old_collection(); adjust the invocations.
>>   
>>   5. Make the following subclasses of ShenandoahOldHeuristics.  In the
>>      initial implementation, these subclasses have the same behavior
>>      as the young-gen heuristics from which they were copied.  Future
>>      refinement may result in tailored behavior of the old-gen
>>      versions of each heuristic: ShenandoahAdaptiveOldHeuristics,
>>      ShenandoahAggresiveOldHeuristics, ShenandoahCompactHeuristics,
>>      ShenandoahPassiveOldHeuristics, ShenandoahStaticOldHeuristics.
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 129:
> 
>> 127: void ShenandoahGeneration::prepare_gc() {
>> 128:   reset_mark_bitmap();
>> 129: 
> 
> Lone whitespace change here.

Added this blank line back in.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Tue Apr 20 00:01:30 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 20 Apr 2021 00:01:30 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <MTalFJit8vxb-XsxGi_PPO78X9YEdcUubbert_qMVDw=.974e041a-bdce-4cf1-8c9c-e33e20b5b163@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
 <rezRKKkjmfyMvxt-aBTQRAFxP7YhNwZd7693uxirkkc=.bbcc4b48-7d8e-450b-9ce2-8749787a7e5e@github.com>
 <MTalFJit8vxb-XsxGi_PPO78X9YEdcUubbert_qMVDw=.974e041a-bdce-4cf1-8c9c-e33e20b5b163@github.com>
Message-ID: <cfJ4YNtI1Qdk-d_Ii_-hbJ_Oq7FnOGoQTmrK5Qdy7UY=.cbdb0a3f-5def-4a56-97e6-783ec0b99806@github.com>

On Mon, 19 Apr 2021 21:24:51 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> We will remove this comment. We saw some pretty strange behavior while debugging, but it turned out to be a bug in `rr`.
>
> Comment will be gone in next commit.

Comment has been removed.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Tue Apr 20 00:10:04 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 20 Apr 2021 00:10:04 GMT
Subject: RFR: Mixed evacuation [v6]
In-Reply-To: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
Message-ID: <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>

> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.

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

  Change definition of CollectionThresholdGarbagePercent
  
  This is now defined to equal ShenandoahGarbageThreshold, which seems to have
  a default value of 25.  The effect on running workloads is to choose more
  regions for the collection set than was observed with the previous
  configuration.
  
  Also addressed several improvements in white space and comments.
  
  The code now runs tier1 and hotspot_gc_shenandoah without regressions.  It
  also succsessfully runs an Extremem stress test up until the point of
  failure due to triggering of full GC (after 113 completed GC passes, including
  two old-gen GC passes).

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/29/files
  - new: https://git.openjdk.java.net/shenandoah/pull/29/files/c883f237..c8377a53

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=04-05

  Stats: 17 lines in 5 files changed: 3 ins; 3 del; 11 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/29/head:pull/29

PR: https://git.openjdk.java.net/shenandoah/pull/29

From gnu.andrew at redhat.com  Tue Apr 20 19:48:55 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 20 Apr 2021 20:48:55 +0100
Subject: [RFR] [8u] 8u292-b10 Upstream Sync
Message-ID: <20210420194855.GA451386@rincewind>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/

Merge changesets:
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/corba/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/jaxp/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/jaxws/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/jdk/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/hotspot/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/langtools/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/nashorn/merge.changeset
http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/root/merge.changeset

Changes in aarch64-shenandoah-jdk8u292-b10:
  - JDK-8227467: Better class method invocations
  - JDK-8244473: Contextualize registration for JNDI
  - JDK-8244543: Enhanced handling of abstract classes
  - JDK-8249906: Enhance opening JARs
  - JDK-8250568: Less ambiguous processing
  - JDK-8253799: Make lists of normal filenames
  - JDK-8258247: Couple of issues in fix for JDK-8249906
  - JDK-8259428: AlgorithmId.getEncodedParams() should return copy
  - JDK-8261183: Follow on to Make lists of normal filenames

Main issues of note:
None, clean merge (HotSpot changes are relatively simple and to stable code).

diffstat for root
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for corba
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jaxp
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jaxws
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for langtools
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for nashorn
 b/.hgtags |    1 +
 1 file changed, 1 insertion(+)

diffstat for jdk
 b/.hgtags                                                                             |    1 
 b/src/share/classes/com/sun/jndi/ldap/Obj.java                                        |    5 
 b/src/share/classes/com/sun/jndi/ldap/VersionHelper12.java                            |   51 +-
 b/src/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java                |  115 +++++
 b/src/share/classes/com/sun/naming/internal/VersionHelper.java                        |    3 
 b/src/share/classes/com/sun/naming/internal/VersionHelper12.java                      |   13 
 b/src/share/classes/java/io/File.java                                                 |   49 +-
 b/src/share/classes/java/security/cert/CertPathHelperImpl.java                        |    6 
 b/src/share/classes/java/security/cert/TrustAnchor.java                               |   23 -
 b/src/share/classes/javax/naming/spi/NamingManager.java                               |   13 
 b/src/share/classes/sun/security/pkcs/SignerInfo.java                                 |  143 +++---
 b/src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java              |  135 ++----
 b/src/share/classes/sun/security/provider/certpath/CertPathConstraintsParameters.java |  127 +++++
 b/src/share/classes/sun/security/provider/certpath/CertPathHelper.java                |   11 
 b/src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java      |   25 -
 b/src/share/classes/sun/security/provider/certpath/OCSP.java                          |    3 
 b/src/share/classes/sun/security/provider/certpath/OCSPResponse.java                  |    9 
 b/src/share/classes/sun/security/provider/certpath/PKIX.java                          |   23 -
 b/src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java         |   19 
 b/src/share/classes/sun/security/provider/certpath/RevocationChecker.java             |    4 
 b/src/share/classes/sun/security/ssl/SSLContextImpl.java                              |    2 
 b/src/share/classes/sun/security/ssl/X509KeyManagerImpl.java                          |    3 
 b/src/share/classes/sun/security/util/AnchorCertificates.java                         |   23 -
 b/src/share/classes/sun/security/util/ConstraintsParameters.java                      |  174 +------
 b/src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java               |  221 +++++-----
 b/src/share/classes/sun/security/util/JarConstraintsParameters.java                   |  188 ++++++++
 b/src/share/classes/sun/security/util/ManifestEntryVerifier.java                      |   60 ++
 b/src/share/classes/sun/security/util/SignatureFileVerifier.java                      |   62 +-
 b/src/share/classes/sun/security/validator/PKIXValidator.java                         |    2 
 b/src/share/classes/sun/security/validator/SimpleValidator.java                       |    2 
 b/src/share/classes/sun/security/x509/AlgorithmId.java                                |   52 +-
 b/src/share/lib/security/java.security-aix                                            |   23 +
 b/src/share/lib/security/java.security-linux                                          |   23 +
 b/src/share/lib/security/java.security-macosx                                         |   23 +
 b/src/share/lib/security/java.security-solaris                                        |   23 +
 b/src/share/lib/security/java.security-windows                                        |   23 +
 b/src/windows/classes/java/lang/ProcessImpl.java                                      |   27 -
 b/test/java/security/cert/X509Certificate/GetSigAlgParams.java                        |   46 ++
 b/test/sun/security/pkcs/pkcs8/PKCS8Test.java                                         |    4 
 b/test/sun/security/tools/jarsigner/TimestampCheck.java                               |    5 
 b/test/sun/security/x509/AlgorithmId/AlgorithmIdEqualsHashCode.java                   |   46 +-
 41 files changed, 1264 insertions(+), 546 deletions(-)

diffstat for hotspot
 b/.hgtags                             |    1 
 b/src/share/vm/code/dependencies.cpp  |   49 ++++++++++++++++++++++++++++------
 b/src/share/vm/oops/instanceKlass.cpp |   14 ++++++---
 b/src/share/vm/oops/instanceKlass.hpp |    7 +++-
 4 files changed, 56 insertions(+), 15 deletions(-)

Successfully built on x86, x86_64, s390 (Zero), s390x (Zero), ppc (Zero),
ppc64, ppc64le & aarch64.

Ok to push?

Thanks,
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Tue Apr 20 19:56:01 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 20 Apr 2021 21:56:01 +0200
Subject: [RFR] [8u] 8u292-b10 Upstream Sync
In-Reply-To: <20210420194855.GA451386@rincewind>
References: <20210420194855.GA451386@rincewind>
Message-ID: <00e69b8f-42a4-f7f8-79b4-71cd0406c096@redhat.com>

On 4/20/21 9:48 PM, Andrew Hughes wrote:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/jaxws/merge.changeset

Looks trivially good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/jdk/merge.changeset

Looks good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/hotspot/merge.changeset

Looks good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/root/merge.changeset

Looks trivially good.

> Ok to push?

Yes.

-- 
Thanks,
-Aleksey


From gnu.andrew at redhat.com  Tue Apr 20 20:01:14 2021
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Tue, 20 Apr 2021 21:01:14 +0100
Subject: [RFR] [8u] 8u292-b10 Upstream Sync
In-Reply-To: <00e69b8f-42a4-f7f8-79b4-71cd0406c096@redhat.com>
References: <20210420194855.GA451386@rincewind>
 <00e69b8f-42a4-f7f8-79b4-71cd0406c096@redhat.com>
Message-ID: <20210420200114.GB451386@rincewind>

On 21:56 Tue 20 Apr     , Aleksey Shipilev wrote:
> On 4/20/21 9:48 PM, Andrew Hughes wrote:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/jaxws/merge.changeset
> 
> Looks trivially good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/jdk/merge.changeset
> 
> Looks good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/hotspot/merge.changeset
> 
> Looks good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/nashorn/merge.changeset > http://cr.openjdk.java.net/~andrew/shenandoah-8/u292-b10/root/merge.changeset
> 
> Looks trivially good.
> 
> > Ok to push?
> 
> Yes.
> 
> -- 
> Thanks,
> -Aleksey
> 

Thanks, pushed.
-- 
Andrew :)

Senior Free Java Software Engineer
OpenJDK Package Owner
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222

From shade at redhat.com  Wed Apr 21 07:19:11 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 21 Apr 2021 09:19:11 +0200
Subject: [8u] RFC: Pick up 8u292-b10 to sh/jdk8
Message-ID: <fa9f4685-69c4-66ac-3bfa-a209349918db@redhat.com>

Upstream had posted the 8u292-b10 tags, let's pick those up to sh/jdk8. Since sh/jdk8 is currently a 
clean downstream, no merges needed, I just pulled all changes to all repos.

Testing: hotspot_gc_shenandoah {fastdebug,release}

-- 
Thanks,
-Aleksey


From kdnilsen at openjdk.java.net  Wed Apr 21 09:21:08 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 21 Apr 2021 09:21:08 GMT
Subject: RFR: Mixed evacuation [v2]
In-Reply-To: <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <ezhh7OZgGHkUXqtLEVrReVfQA1l3tVEnmOF7i6Tu8cc=.a4d0d96f-8f42-4e8c-bf6e-8dd20062cd83@github.com>
 <QkIWpbLBdKH5MWyZp8aOic40YHET-TTkdWh_5hbQWj4=.418309b8-afd5-40a5-b912-44ec37b148f2@github.com>
Message-ID: <MghhcGm-j4A9SJxatvl5o1aDK66EOEXRHIbJt-lsTdQ=.1cb05d52-d495-452f-ae57-7038ba85b0c2@github.com>

On Mon, 12 Apr 2021 19:49:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chasing bug during prepare_for_old_collection
>>   
>>   One bug fix, a few cosmetic improvements, a change in loop structure to possibly avoid a gcc
>>   optimization error.
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 515:
> 
>> 513:   // evacuated.  In the future, this threshold percentage may be specified on
>> 514:   // the command line or preferrably determined by dynamic heuristics.
>> 515: #define CollectionThresholdGarbagePercent 50
> 
> We already have ShenandoahGarbageThreshold (defaults to 60 iirc) maybe we want to use this? Or use separate global/old/young thresholds?

I've made and tested this change now.  Appears to me that default of ShenandoahGarbageThreshold is 25.  On established stress workloads, this change has the effect of choosing larger collection sets for old-gen.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From rkennke at openjdk.java.net  Wed Apr 21 11:22:05 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 21 Apr 2021 11:22:05 GMT
Subject: RFR: Mixed evacuation [v6]
In-Reply-To: <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>
Message-ID: <5kYRNqZI6fd2xolzGO9ryvE4cacS9vpGOwdk2aWFTTo=.f9d9c56d-af34-4a12-8760-3629af67a716@github.com>

On Tue, 20 Apr 2021 00:10:04 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change definition of CollectionThresholdGarbagePercent
>   
>   This is now defined to equal ShenandoahGarbageThreshold, which seems to have
>   a default value of 25.  The effect on running workloads is to choose more
>   regions for the collection set than was observed with the previous
>   configuration.
>   
>   Also addressed several improvements in white space and comments.
>   
>   The code now runs tier1 and hotspot_gc_shenandoah without regressions.  It
>   also succsessfully runs an Extremem stress test up until the point of
>   failure due to triggering of full GC (after 113 completed GC passes, including
>   two old-gen GC passes).

Nice. I believe I only have complaints about cosmetic issues.
One design-related question remains: why is it necessary to duplicate all heuristics as old variants? Is there any chance the existing heuristics can be reused? Or does it make sense to have different variants for old? Asking out of curiosity, I'm leaving the design to you.

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

> 97:                      byte_size_in_proper_unit(min_garbage), proper_unit_for_byte_size(min_garbage));
> 98: 
> 99: 

We have a lone newline here.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveOldHeuristics.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Please, only put first and last year in copyright notice (from-to).

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveOldHeuristics.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Same as above.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveOldHeuristics.hpp line 29:

> 27: 
> 28: #include "gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp"
> 29: #include "gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp"

I don't think you need to include shenandoahAdaptiveHeuristics.hpp here.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019 Red Hat, Inc. All rights reserved.

Please don't remove the comma.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveOldHeuristics.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Same as above. Only put in begin and end year.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveOldHeuristics.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Same as above.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactOldHeuristics.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Same as above.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactOldHeuristics.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Same as above.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2020, 2021, Red Hat, Inc. All rights reserved.

Same as above.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 167:

> 165:       old_heuristics->prime_collection_set(collection_set);
> 166:     }
> 167:     // else, thisi s global collection and doesn't need to prime_collection_set()

Typo here 'thisi s'

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 172:

> 170:   size_t collectable_garbage = collection_set->garbage() + immediate_garbage;
> 171:   size_t collectable_garbage_percent = (total_garbage == 0) ? 0 : (collectable_garbage * 100 / total_garbage);
> 172: 

Stray newline change.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 204:

> 202: 
> 203: bool ShenandoahHeuristics::should_start_gc() {
> 204: 

Stray newline change.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 155:

> 153:   double time_since_last_gc() const;
> 154: 
> 155: 

Stray newlines.

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

> 24: 
> 25: #include "gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp"
> 26: #include "precompiled.hpp"

Convention is to always put include for precompiled.hpp first.

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

> 65:   // collection set selection.  Here, we'd rather fall back to this contingent behavior than force a full STW
> 66:   // collection.
> 67: #define PROMOTION_BUDGET_BYTES (ShenandoahHeapRegion::region_size_bytes() / 2)

I'd put macro definitions at the top of the file, right below the includes.

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

> 218:   // future, this threshold percentage may be specified on the command
> 219:   // line or preferrably determined by dynamic heuristics.
> 220: #define CollectionThresholdGarbagePercent ShenandoahGarbageThreshold

Same as above: please place define at top of file.

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

> 247:   _old_coalesce_and_fill_candidates = 0;
> 248: 
> 249: #undef CollectionThresholdGarbagePercent

I don't think the constants need to be undef-ed when defined at top of file. Alternatively, you may consider making them true C++ constants.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveOldHeuristics.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Same as above, only use first and last years.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveOldHeuristics.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Same as above.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp line 32:

> 30: // TODO: Make this a subclass of ShenandoahHeuristics and create a "tailored" copy of this class to be subclass of
> 31: // ShenandoahOldHeuristics.  Fix the constructor implementation to invoke ShenandoahHeuristics() superclass constructor.
> 32: // Change ShenandoahMode::initialize_old_heuristics() to return the subclass of ShenandoahOldHeuristics.

Is this comment still valid? You seem to propose a ShenandoahStaticOldHeuristics too.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticOldHeuristics.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Same as above.

src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticOldHeuristics.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.

Same as above.

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

Changes requested by rkennke (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/29

From rkennke at openjdk.java.net  Wed Apr 21 11:23:57 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 21 Apr 2021 11:23:57 GMT
Subject: RFR: Update remembered set during old generation mark
In-Reply-To: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>
References: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>
Message-ID: <iWQkJOwmL3VV66Sth72A2MAr2qkX1ELZMGncwhLUuVY=.c7bdf785-0238-4586-9648-7de32c9cdd29@github.com>

On Wed, 14 Apr 2021 21:15:10 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> This change is to support the concurrent remembered set scanning work which is in progress.

Hmm, strange that you cannot seem to integrate the change. You have committer status and should be able to integrate on your own. I'll check that with ops and will sponsor the change in the meantime.

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

PR: https://git.openjdk.java.net/shenandoah/pull/31

From rkennke at openjdk.java.net  Wed Apr 21 11:25:19 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 21 Apr 2021 11:25:19 GMT
Subject: git: openjdk/shenandoah: master: Update remembered set during old
 generation mark
Message-ID: <69ae8eac-cb08-4edc-ac08-010c83f73b05@openjdk.org>

Changeset: eebec31d
Author:    William Kemper <kemperw at amazon.com>
Committer: Roman Kennke <rkennke at openjdk.org>
Date:      2021-04-21 11:24:47 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/eebec31d

Update remembered set during old generation mark

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp
! src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp


From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr 21 11:27:50 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 21 Apr 2021 11:27:50 GMT
Subject: Integrated: Update remembered set during old generation mark
In-Reply-To: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>
References: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>
Message-ID: <r88bPvOdjPwHXOW1hF3PXuXtOwhMA4vatD9tPDcUahI=.7daa8f7f-b5ed-4ccd-9859-0509dfb9f322@github.com>

On Wed, 14 Apr 2021 21:15:10 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> This change is to support the concurrent remembered set scanning work which is in progress.

This pull request has now been integrated.

Changeset: eebec31d
Author:    William Kemper <kemperw at amazon.com>
Committer: Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/eebec31d
Stats:     14 lines in 3 files changed: 14 ins; 0 del; 0 mod

Update remembered set during old generation mark

Reviewed-by: rkennke

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

PR: https://git.openjdk.java.net/shenandoah/pull/31

From zgu at redhat.com  Wed Apr 21 12:01:00 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 21 Apr 2021 08:01:00 -0400
Subject: [8u] RFC: Pick up 8u292-b10 to sh/jdk8
In-Reply-To: <fa9f4685-69c4-66ac-3bfa-a209349918db@redhat.com>
References: <fa9f4685-69c4-66ac-3bfa-a209349918db@redhat.com>
Message-ID: <2781a56d-7d09-803e-2991-3ec3cf53150a@redhat.com>

Great.

-Zhengyu

On 4/21/21 3:19 AM, Aleksey Shipilev wrote:
> Upstream had posted the 8u292-b10 tags, let's pick those up to sh/jdk8. 
> Since sh/jdk8 is currently a clean downstream, no merges needed, I just 
> pulled all changes to all repos.
> 
> Testing: hotspot_gc_shenandoah {fastdebug,release}
> 


From shade at redhat.com  Wed Apr 21 12:30:34 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 21 Apr 2021 14:30:34 +0200
Subject: [8u] RFC: Pick up 8u292-b10 to sh/jdk8
In-Reply-To: <2781a56d-7d09-803e-2991-3ec3cf53150a@redhat.com>
References: <fa9f4685-69c4-66ac-3bfa-a209349918db@redhat.com>
 <2781a56d-7d09-803e-2991-3ec3cf53150a@redhat.com>
Message-ID: <52efcaef-2da0-7bea-cc53-9750bc925f64@redhat.com>

On 4/21/21 2:01 PM, Zhengyu Gu wrote:
> Great.

Thanks, pushed.

-- 
-Aleksey


From shade at openjdk.java.net  Wed Apr 21 12:37:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 21 Apr 2021 12:37:38 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v3]
In-Reply-To: <OeK5Ff0cZaQ7qV2HFv8IsffVTbME9-ozEXSSu-gWsO8=.72593252-988a-478d-9360-51282530b8a6@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <OeK5Ff0cZaQ7qV2HFv8IsffVTbME9-ozEXSSu-gWsO8=.72593252-988a-478d-9360-51282530b8a6@github.com>
Message-ID: <5eFYUAN5vePIHfJMyvgAz2XNf6kxbtEhR7ktB2hBNjA=.ef0c8a80-d56d-494f-83d0-2857e463650e@github.com>

On Tue, 16 Feb 2021 10:26:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.
>> 
>> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough.
>> 
>> For the forwardee load side, we need to guarantee "acquire". We do not do it now, reading the markword without memory semantics. It does not seem to pose a practical problem today, because GC does not access the object contents in the new copy, and mutators get this from the JRT-called stub that separates the fwdptr access and object contents access by a lot. It still should be cleaner to "acquire" the mark on load to avoid surprises.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 `tier1` with Shenandoah
>
> 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 six additional commits since the last revision:
> 
>  - A few minor touchups
>  - Add a blurb to x86 code as well
>  - Use implicit "consume" in AArch64, add more notes.
>  - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
>  - Make sure to access fwdptr with acquire semantics in assembler code
>  - 8261492: Shenandoah: reconsider forwardee accesses memory ordering

Not yet, bot. Waiting for JDK-8261579 to remeasure perf differences.

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

PR: https://git.openjdk.java.net/jdk/pull/2496

From shade at openjdk.java.net  Wed Apr 21 12:37:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 21 Apr 2021 12:37:40 GMT
Subject: RFR: 8261495: Shenandoah: reconsider update references memory
 ordering [v4]
In-Reply-To: <mmDtPov974Ez620ICbTzeSGQ6DJpv9CMAzfRW0Ai3ro=.a3b6d2c2-7b2e-4902-a5dc-c7241b7e6ada@github.com>
References: <4RLKvcdaWu0Cu6owC3yGoVY1KVEsYjBZEFJhfdwnhWg=.65fbeae1-58f6-48d3-a2ed-981858ef7da9@github.com>
 <mmDtPov974Ez620ICbTzeSGQ6DJpv9CMAzfRW0Ai3ro=.a3b6d2c2-7b2e-4902-a5dc-c7241b7e6ada@github.com>
Message-ID: <owZfMYsVA5rO2aZxog7GpNEiJwt58AlfEwmSek0sH3Q=.df6a3ba0-44c2-4e7b-9d6a-21adedf8c3e8@github.com>

On Tue, 16 Feb 2021 13:21:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah update heap references code uses default Atomic::cmpxchg to avoid races with mutator updates. Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64.
>> 
>> This seems to be excessive for Shenandoah update references code, and "release" is enough. We do not seem to piggyback on update-references memory effects anywhere (in fact, if not for mutator, we would not even need a CAS). But, there is an interplay with concurrent evacuation and updates from self-healing.
>> 
>> Average time goes down, the number of GC cycles go up, since the cycles are shorter.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 hotspot_gc_shenandoah
>>  - [x] Linux AArch64 hotspot_gc_shenandoah
>>  - [x] Linux AArch64 tier1 with Shenandoah
>
> 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 10 additional commits since the last revision:
> 
>  - Comment touchup
>  - Specialize out witness-checking methods, drop acquire again
>  - Even more explanation
>  - Move the comment
>  - Also handle clearing the oops
>  - Minor touchups to the comment
>  - Merge branch 'master' into JDK-8261495-shenandoah-updaterefs-memord
>  - Use release only
>  - Do acq_rel instead
>  - 8261495: Shenandoah: reconsider update references memory ordering

Not yet, bot. Waiting for JDK-8261579 to remeasure perf differences.

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

PR: https://git.openjdk.java.net/jdk/pull/2498

From shade at redhat.com  Wed Apr 21 12:30:02 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 21 Apr 2021 12:30:02 +0000
Subject: hg: shenandoah/jdk8/corba: 15 new changesets
Message-ID: <202104211230.13LCU3q2012820@aojmv0008.oracle.com>

Changeset: b7bd2ab7cd4e
Author:    andrew
Date:      2021-03-08 03:47 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/b7bd2ab7cd4e

Added tag jdk8u292-b06 for changeset 78f287f3333a

! .hgtags

Changeset: b36556d5a6d0
Author:    andrew
Date:      2021-03-21 04:12 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/b36556d5a6d0

Merge jdk8u292-b06

! .hgtags

Changeset: e2deb998d350
Author:    andrew
Date:      2021-03-21 04:12 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e2deb998d350

Added tag aarch64-shenandoah-jdk8u292-b06 for changeset b36556d5a6d0

! .hgtags

Changeset: e871cfba551f
Author:    andrew
Date:      2021-03-16 08:08 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/e871cfba551f

Added tag jdk8u292-b07 for changeset b7bd2ab7cd4e

! .hgtags

Changeset: 14b02f03d863
Author:    andrew
Date:      2021-03-25 03:22 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/14b02f03d863

Merge jdk8u292-b07

! .hgtags

Changeset: 363d7c3cafc4
Author:    andrew
Date:      2021-03-25 03:23 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/363d7c3cafc4

Added tag aarch64-shenandoah-jdk8u292-b07 for changeset 14b02f03d863

! .hgtags

Changeset: 93fa17c348d1
Author:    andrew
Date:      2021-03-22 06:46 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/93fa17c348d1

Added tag jdk8u292-b08 for changeset e871cfba551f

! .hgtags

Changeset: 744ee637a097
Author:    andrew
Date:      2021-03-27 02:41 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/744ee637a097

Merge jdk8u292-b08

! .hgtags

Changeset: 533e66d72c9c
Author:    andrew
Date:      2021-03-27 02:41 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/533e66d72c9c

Added tag aarch64-shenandoah-jdk8u292-b08 for changeset 744ee637a097

! .hgtags

Changeset: fa3e1caed3f0
Author:    andrew
Date:      2021-03-27 19:01 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/fa3e1caed3f0

Added tag jdk8u292-b09 for changeset 93fa17c348d1

! .hgtags

Changeset: 6c5b809ec6fc
Author:    andrew
Date:      2021-03-29 20:20 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/6c5b809ec6fc

Merge jdk8u292-b09

! .hgtags

Changeset: 2d5cc2b6daf0
Author:    andrew
Date:      2021-03-29 20:21 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/2d5cc2b6daf0

Added tag aarch64-shenandoah-jdk8u292-b09 for changeset 6c5b809ec6fc

! .hgtags

Changeset: 29ecf71489fe
Author:    andrew
Date:      2021-04-07 06:42 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/29ecf71489fe

Added tag jdk8u292-b10 for changeset fa3e1caed3f0

! .hgtags

Changeset: 88ef2f7de32d
Author:    andrew
Date:      2021-04-08 05:53 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/88ef2f7de32d

Merge jdk8u292-b10

! .hgtags

Changeset: 0b3f5cf61a7a
Author:    andrew
Date:      2021-04-08 06:00 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/0b3f5cf61a7a

Added tag aarch64-shenandoah-jdk8u292-b10 for changeset 88ef2f7de32d

! .hgtags


From shade at redhat.com  Wed Apr 21 12:30:03 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 21 Apr 2021 12:30:03 +0000
Subject: hg: shenandoah/jdk8/langtools: 15 new changesets
Message-ID: <202104211230.13LCU39h012823@aojmv0008.oracle.com>

Changeset: 376b8ec147cf
Author:    andrew
Date:      2021-03-08 03:47 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/376b8ec147cf

Added tag jdk8u292-b06 for changeset 21738367961e

! .hgtags

Changeset: b18274e78c90
Author:    andrew
Date:      2021-03-21 04:12 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/b18274e78c90

Merge jdk8u292-b06

! .hgtags

Changeset: de8d69f0c4e0
Author:    andrew
Date:      2021-03-21 04:12 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/de8d69f0c4e0

Added tag aarch64-shenandoah-jdk8u292-b06 for changeset b18274e78c90

! .hgtags

Changeset: 65614a3f68a2
Author:    andrew
Date:      2021-03-16 08:08 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/65614a3f68a2

Added tag jdk8u292-b07 for changeset 376b8ec147cf

! .hgtags

Changeset: b1ab7f524b5e
Author:    andrew
Date:      2021-03-25 03:23 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/b1ab7f524b5e

Merge jdk8u292-b07

! .hgtags

Changeset: d0ee47d7375d
Author:    andrew
Date:      2021-03-25 03:23 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/d0ee47d7375d

Added tag aarch64-shenandoah-jdk8u292-b07 for changeset b1ab7f524b5e

! .hgtags

Changeset: eabecd4e5adc
Author:    andrew
Date:      2021-03-22 06:46 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/eabecd4e5adc

Added tag jdk8u292-b08 for changeset 65614a3f68a2

! .hgtags

Changeset: 24b246b8baf6
Author:    andrew
Date:      2021-03-27 02:41 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/24b246b8baf6

Merge jdk8u292-b08

! .hgtags

Changeset: 9c747a2e7a03
Author:    andrew
Date:      2021-03-27 02:41 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/9c747a2e7a03

Added tag aarch64-shenandoah-jdk8u292-b08 for changeset 24b246b8baf6

! .hgtags

Changeset: e096ebc661e8
Author:    andrew
Date:      2021-03-27 19:01 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/e096ebc661e8

Added tag jdk8u292-b09 for changeset eabecd4e5adc

! .hgtags

Changeset: f544e07ed901
Author:    andrew
Date:      2021-03-29 20:20 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/f544e07ed901

Merge jdk8u292-b09

! .hgtags

Changeset: 8d19822c737e
Author:    andrew
Date:      2021-03-29 20:21 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/8d19822c737e

Added tag aarch64-shenandoah-jdk8u292-b09 for changeset f544e07ed901

! .hgtags

Changeset: b28f63187ccc
Author:    andrew
Date:      2021-04-07 06:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/b28f63187ccc

Added tag jdk8u292-b10 for changeset e096ebc661e8

! .hgtags

Changeset: 060c8b96c774
Author:    andrew
Date:      2021-04-08 05:53 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/060c8b96c774

Merge jdk8u292-b10

! .hgtags

Changeset: d5cd4b84ea7f
Author:    andrew
Date:      2021-04-08 06:00 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/langtools/rev/d5cd4b84ea7f

Added tag aarch64-shenandoah-jdk8u292-b10 for changeset 060c8b96c774

! .hgtags


From shade at redhat.com  Wed Apr 21 12:30:13 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 21 Apr 2021 12:30:13 +0000
Subject: hg: shenandoah/jdk8/jdk: 23 new changesets
Message-ID: <202104211230.13LCUEsT012883@aojmv0008.oracle.com>

Changeset: 42f6981cebc5
Author:    andrew
Date:      2021-03-05 19:33 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/42f6981cebc5

8259048: (tz) Upgrade time-zone data to tzdata2020f
Reviewed-by: dcherepanov

! make/data/tzdata/VERSION
! make/data/tzdata/africa
! make/data/tzdata/asia
! make/data/tzdata/australasia
! make/data/tzdata/backward
! make/data/tzdata/etcetera
! make/data/tzdata/europe
! make/data/tzdata/leapseconds
! make/data/tzdata/northamerica
! make/data/tzdata/zone.tab
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/australasia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/etcetera
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/zone.tab

Changeset: 99b8202e7f71
Author:    andrew
Date:      2021-03-08 03:47 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/99b8202e7f71

Added tag jdk8u292-b06 for changeset 42f6981cebc5

! .hgtags

Changeset: 2ff418bafc95
Author:    andrew
Date:      2021-03-21 04:12 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2ff418bafc95

Merge jdk8u292-b06

! .hgtags
! make/data/tzdata/VERSION
! make/data/tzdata/africa
! make/data/tzdata/asia
! make/data/tzdata/australasia
! make/data/tzdata/backward
! make/data/tzdata/etcetera
! make/data/tzdata/europe
! make/data/tzdata/leapseconds
! make/data/tzdata/northamerica
! make/data/tzdata/zone.tab
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/asia
! test/sun/util/calendar/zi/tzdata/australasia
! test/sun/util/calendar/zi/tzdata/backward
! test/sun/util/calendar/zi/tzdata/etcetera
! test/sun/util/calendar/zi/tzdata/europe
! test/sun/util/calendar/zi/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/northamerica
! test/sun/util/calendar/zi/tzdata/zone.tab

Changeset: d5ecc5f51cf4
Author:    andrew
Date:      2021-03-21 04:12 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d5ecc5f51cf4

Added tag aarch64-shenandoah-jdk8u292-b06 for changeset 2ff418bafc95

! .hgtags

Changeset: 6c09694ccb80
Author:    andrew
Date:      2021-03-16 08:08 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6c09694ccb80

Added tag jdk8u292-b07 for changeset 99b8202e7f71

! .hgtags

Changeset: f96e316f9711
Author:    andrew
Date:      2021-03-25 03:23 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f96e316f9711

Merge jdk8u292-b07

! .hgtags

Changeset: 6d71ac835cb9
Author:    andrew
Date:      2021-03-25 03:23 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6d71ac835cb9

Added tag aarch64-shenandoah-jdk8u292-b07 for changeset f96e316f9711

! .hgtags

Changeset: 8c34226ce118
Author:    rhalade
Date:      2021-02-04 19:11 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/8c34226ce118

8256421: Add 2 HARICA roots to cacerts truststore
Reviewed-by: mullan

+ make/data/cacerts/haricaeccrootca2015
+ make/data/cacerts/haricarootca2015
+ test/security/infra/java/security/cert/CertPathValidator/certification/HaricaCA.java
! test/sun/security/lib/cacerts/VerifyCACerts.java

Changeset: d103481ecd91
Author:    andrew
Date:      2021-03-22 06:11 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d103481ecd91

8260356: (tz) Upgrade time-zone data to tzdata2021a
Reviewed-by: dcherepanov

! make/data/tzdata/VERSION
! make/data/tzdata/africa
! make/data/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/leapseconds

Changeset: 364cf530fbd3
Author:    andrew
Date:      2021-03-22 06:46 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/364cf530fbd3

Added tag jdk8u292-b08 for changeset d103481ecd91

! .hgtags

Changeset: 1635dfecb928
Author:    andrew
Date:      2021-03-27 02:41 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1635dfecb928

Merge jdk8u292-b08

! .hgtags
! make/data/tzdata/VERSION
! make/data/tzdata/africa
! make/data/tzdata/leapseconds
! test/sun/util/calendar/zi/tzdata/VERSION
! test/sun/util/calendar/zi/tzdata/africa
! test/sun/util/calendar/zi/tzdata/leapseconds

Changeset: 381ae4a6029f
Author:    andrew
Date:      2021-03-27 02:41 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/381ae4a6029f

Added tag aarch64-shenandoah-jdk8u292-b08 for changeset 1635dfecb928

! .hgtags

Changeset: a7ef81ab119b
Author:    andrew
Date:      2021-03-27 19:01 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a7ef81ab119b

Added tag jdk8u292-b09 for changeset 364cf530fbd3

! .hgtags

Changeset: bff5a03ca3f6
Author:    andrew
Date:      2021-03-29 20:20 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/bff5a03ca3f6

Merge jdk8u292-b09

! .hgtags

Changeset: 6c8496de4a52
Author:    andrew
Date:      2021-03-29 20:21 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6c8496de4a52

Added tag aarch64-shenandoah-jdk8u292-b09 for changeset bff5a03ca3f6

! .hgtags

Changeset: f396f4a7ee5d
Author:    mbalao
Date:      2021-04-07 05:55 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f396f4a7ee5d

8244473: Contextualize registration for JNDI
Reviewed-by: bae, andrew

! src/share/classes/com/sun/jndi/ldap/Obj.java
! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java
+ src/share/classes/com/sun/naming/internal/ObjectFactoriesFilter.java
! src/share/classes/com/sun/naming/internal/VersionHelper.java
! src/share/classes/com/sun/naming/internal/VersionHelper12.java
! src/share/classes/javax/naming/spi/NamingManager.java
! src/share/lib/security/java.security-aix
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows

Changeset: 412d2b1381a4
Author:    avoitylov
Date:      2021-04-07 05:57 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/412d2b1381a4

8249906: Enhance opening JARs
8258247: Couple of issues in fix for JDK-8249906
8259428: AlgorithmId.getEncodedParams() should return copy
Reviewed-by: mbalao, andrew

! src/share/classes/java/security/cert/CertPathHelperImpl.java
! src/share/classes/java/security/cert/TrustAnchor.java
! src/share/classes/sun/security/pkcs/SignerInfo.java
! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java
+ src/share/classes/sun/security/provider/certpath/CertPathConstraintsParameters.java
! src/share/classes/sun/security/provider/certpath/CertPathHelper.java
! src/share/classes/sun/security/provider/certpath/DistributionPointFetcher.java
! src/share/classes/sun/security/provider/certpath/OCSP.java
! src/share/classes/sun/security/provider/certpath/OCSPResponse.java
! src/share/classes/sun/security/provider/certpath/PKIX.java
! src/share/classes/sun/security/provider/certpath/PKIXCertPathValidator.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/util/AnchorCertificates.java
! src/share/classes/sun/security/util/ConstraintsParameters.java
! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
+ src/share/classes/sun/security/util/JarConstraintsParameters.java
! src/share/classes/sun/security/util/ManifestEntryVerifier.java
! src/share/classes/sun/security/util/SignatureFileVerifier.java
! src/share/classes/sun/security/validator/PKIXValidator.java
! src/share/classes/sun/security/validator/SimpleValidator.java
! src/share/classes/sun/security/x509/AlgorithmId.java
+ test/java/security/cert/X509Certificate/GetSigAlgParams.java
! test/sun/security/pkcs/pkcs8/PKCS8Test.java
! test/sun/security/tools/jarsigner/TimestampCheck.java
! test/sun/security/x509/AlgorithmId/AlgorithmIdEqualsHashCode.java

Changeset: b423d9afa01f
Author:    avoitylov
Date:      2021-02-04 00:32 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b423d9afa01f

8250568: Less ambiguous processing
Reviewed-by: mbalao, andrew

! src/windows/classes/java/lang/ProcessImpl.java

Changeset: b138d2995b90
Author:    yan
Date:      2020-12-18 17:58 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b138d2995b90

8253799: Make lists of normal filenames
Reviewed-by: mbalao, andrew

! src/share/classes/java/io/File.java

Changeset: 4eae74c62a51
Author:    yan
Date:      2021-02-18 17:34 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/4eae74c62a51

8261183: Follow on to Make lists of normal filenames
Reviewed-by: mbalao, andrew

! src/share/classes/java/io/File.java

Changeset: 28b74705f731
Author:    andrew
Date:      2021-04-07 06:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/28b74705f731

Added tag jdk8u292-b10 for changeset 4eae74c62a51

! .hgtags

Changeset: 6e0ee1656bad
Author:    andrew
Date:      2021-04-08 05:53 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/6e0ee1656bad

Merge jdk8u292-b10

! .hgtags
! src/share/classes/com/sun/jndi/ldap/VersionHelper12.java
! src/share/classes/java/io/File.java
! src/share/classes/java/security/cert/TrustAnchor.java
! src/share/classes/sun/security/provider/certpath/AlgorithmChecker.java
! src/share/classes/sun/security/provider/certpath/RevocationChecker.java
! src/share/classes/sun/security/ssl/SSLContextImpl.java
! src/share/classes/sun/security/ssl/X509KeyManagerImpl.java
! src/share/classes/sun/security/util/ConstraintsParameters.java
! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
! src/share/lib/security/java.security-aix
! src/share/lib/security/java.security-linux
! src/share/lib/security/java.security-macosx
! src/share/lib/security/java.security-solaris
! src/share/lib/security/java.security-windows
! test/sun/security/tools/jarsigner/TimestampCheck.java

Changeset: 80d1c6423c2f
Author:    andrew
Date:      2021-04-08 06:00 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/80d1c6423c2f

Added tag aarch64-shenandoah-jdk8u292-b10 for changeset 6e0ee1656bad

! .hgtags


From shade at redhat.com  Wed Apr 21 12:30:31 2021
From: shade at redhat.com (shade at redhat.com)
Date: Wed, 21 Apr 2021 12:30:31 +0000
Subject: hg: shenandoah/jdk8/hotspot: 21 new changesets
Message-ID: <202104211230.13LCUVAe012975@aojmv0008.oracle.com>

Changeset: 7dd9c893c8dd
Author:    andrew
Date:      2021-03-08 03:47 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/7dd9c893c8dd

Added tag jdk8u292-b06 for changeset a5795acea814

! .hgtags

Changeset: 0e7e9a56a112
Author:    andrew
Date:      2021-03-21 04:12 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/0e7e9a56a112

Merge jdk8u292-b06

! .hgtags

Changeset: c8b891f5d456
Author:    andrew
Date:      2021-03-21 04:12 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c8b891f5d456

Added tag aarch64-shenandoah-jdk8u292-b06 for changeset 0e7e9a56a112

! .hgtags

Changeset: a04fea0a0dc0
Author:    dongbohe
Date:      2021-03-04 18:28 +0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a04fea0a0dc0

8263008: AARCH64: Add debug info for libsaproc.so
Reviewed-by: sgehwolf
Contributed-by: zhanggaofeng9 at huawei.com

! make/linux/makefiles/defs.make

Changeset: f206e4bfcef9
Author:    andrew
Date:      2021-03-12 02:57 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/f206e4bfcef9

Merge


Changeset: 616812f93bca
Author:    andrew
Date:      2021-03-16 08:08 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/616812f93bca

Added tag jdk8u292-b07 for changeset f206e4bfcef9

! .hgtags

Changeset: 69f03e090d1c
Author:    andrew
Date:      2021-03-25 03:23 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/69f03e090d1c

Merge jdk8u292-b07

! .hgtags
! make/linux/makefiles/defs.make

Changeset: 8d3d2b52382c
Author:    andrew
Date:      2021-03-25 03:23 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/8d3d2b52382c

Added tag aarch64-shenandoah-jdk8u292-b07 for changeset 69f03e090d1c

! .hgtags

Changeset: 85c5bc8157df
Author:    rbackman
Date:      2018-01-18 19:21 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/85c5bc8157df

8191915: JCK tests produce incorrect results with C2
Reviewed-by: thartmann, vlivanov, goetz, andrew

! src/share/vm/opto/mathexactnode.cpp
! src/share/vm/opto/mathexactnode.hpp
+ test/compiler/intrinsics/mathexact/LongMulOverflowTest.java

Changeset: b8703bf4625d
Author:    andrew
Date:      2021-03-22 06:46 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/b8703bf4625d

Added tag jdk8u292-b08 for changeset 85c5bc8157df

! .hgtags

Changeset: a751a67bedc9
Author:    andrew
Date:      2021-03-27 02:41 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a751a67bedc9

Merge jdk8u292-b08

! .hgtags
! src/share/vm/opto/mathexactnode.cpp
! src/share/vm/opto/mathexactnode.hpp

Changeset: 5ea3b519d70a
Author:    andrew
Date:      2021-03-27 02:41 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/5ea3b519d70a

Added tag aarch64-shenandoah-jdk8u292-b08 for changeset a751a67bedc9

! .hgtags

Changeset: 655498b9a44d
Author:    mdoerr
Date:      2021-03-25 14:55 +0800
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/655498b9a44d

8264171: Missing aarch64 parts of JDK-8236179 (C1 register allocation failure with T_ADDRESS)
Reviewed-by: rkennke, vlivanov, roland, mdoerr, shade, aph
Contributed-by: Aditya Mandaleeka <adityam at microsoft.com>

! src/cpu/aarch64/vm/c1_FrameMap_aarch64.cpp
! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp

Changeset: 65907019826a
Author:    andrew
Date:      2021-03-27 18:53 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/65907019826a

Merge


Changeset: 91b61f678a19
Author:    andrew
Date:      2021-03-27 19:01 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/91b61f678a19

Added tag jdk8u292-b09 for changeset 65907019826a

! .hgtags

Changeset: a47191f809c7
Author:    andrew
Date:      2021-03-29 20:20 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/a47191f809c7

Merge jdk8u292-b09

! .hgtags
! src/cpu/aarch64/vm/c1_FrameMap_aarch64.cpp
! src/cpu/aarch64/vm/c1_LIRAssembler_aarch64.cpp

Changeset: 288c7ba0c76f
Author:    andrew
Date:      2021-03-29 20:21 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/288c7ba0c76f

Added tag aarch64-shenandoah-jdk8u292-b09 for changeset a47191f809c7

! .hgtags

Changeset: 2a6952bb3909
Author:    andrew
Date:      2021-03-31 17:51 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/2a6952bb3909

8244543: Enhanced handling of abstract classes
8227467: Better class method invocations
Summary: Includes changes to find_instance_method from JDK-8010319
Reviewed-by: mbalao
Contributed-by: alvdavi at amazon.com

! src/share/vm/code/dependencies.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp

Changeset: c137543b09a7
Author:    andrew
Date:      2021-04-07 06:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/c137543b09a7

Added tag jdk8u292-b10 for changeset 2a6952bb3909

! .hgtags

Changeset: 9e58eb00ef60
Author:    andrew
Date:      2021-04-08 05:53 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/9e58eb00ef60

Merge jdk8u292-b10

! .hgtags
! src/share/vm/code/dependencies.cpp
! src/share/vm/oops/instanceKlass.cpp
! src/share/vm/oops/instanceKlass.hpp

Changeset: 435f8b27e9a5
Author:    andrew
Date:      2021-04-08 06:00 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/435f8b27e9a5

Added tag aarch64-shenandoah-jdk8u292-b10 for changeset 9e58eb00ef60

! .hgtags


From zgu at openjdk.java.net  Wed Apr 21 13:14:07 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 21 Apr 2021 13:14:07 GMT
Subject: RFR: Update remembered set during old generation mark
In-Reply-To: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>
References: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>
Message-ID: <2Z-lTb06Yjln8CXIDVC-mbNbfrhyrcfLx5PXj0aCpas=.6bac2ecb-fcb6-459b-b325-9aec13f67a18@github.com>

On Wed, 14 Apr 2021 21:15:10 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

> This change is to support the concurrent remembered set scanning work which is in progress.

src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 278:

> 276:       // Old mark, found a young pointer.
> 277:       assert(ShenandoahHeap::heap()->is_in_young(obj), "Expected young object.");
> 278:       ShenandoahHeap::heap()->mark_card_as_dirty((HeapWord*)p);

Just a nit, please use cast_from_oop<HeapWord*>(p) instead.

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

PR: https://git.openjdk.java.net/shenandoah/pull/31

From kdnilsen at openjdk.java.net  Wed Apr 21 14:30:52 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 21 Apr 2021 14:30:52 GMT
Subject: RFR: Mixed evacuation [v6]
In-Reply-To: <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>
Message-ID: <otwmICsTIWTpCGCJZY6FZQbSNQ1Y1-hkwGxTwn0-RBU=.fd6f3b33-2504-4b46-b1d5-752fe52af28c@github.com>

On Tue, 20 Apr 2021 00:10:04 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change definition of CollectionThresholdGarbagePercent
>   
>   This is now defined to equal ShenandoahGarbageThreshold, which seems to have
>   a default value of 25.  The effect on running workloads is to choose more
>   regions for the collection set than was observed with the previous
>   configuration.
>   
>   Also addressed several improvements in white space and comments.
>   
>   The code now runs tier1 and hotspot_gc_shenandoah without regressions.  It
>   also succsessfully runs an Extremem stress test up until the point of
>   failure due to triggering of full GC (after 113 completed GC passes, including
>   two old-gen GC passes).

Thanks much for the quick feedback.  I believe I can get through all of these later today.

Regarding the question of whether it makes sense to duplicate the heuristics, I believe the answer is yes.  Here is some of the rationale:

1. In general, we expect old-gen to behave very differently than young-gen.  If all is properly configured, young-gen will experience high allocation rates and very high infant mortality.  While old-gen will experience relatively low allocation (promotion) rates and no infant mortality.  If properly configured, we do not promote to old-gen until we have confirmed that an object is no more likely to die in infancy than to die in old age.

2. The old-gen heuristics need to maintain additional information that is not required by the young-gen heuristics, so all of the old-gen subclass heuristics need to derive from a different base class.  Among information required by old-gen is the candidate collection set, the coalesce-and-fill set, and awareness of whether previously selected old-gen candidate collection set has been fully processed.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From bmathiske at openjdk.java.net  Wed Apr 21 19:36:07 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Wed, 21 Apr 2021 19:36:07 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v2]
In-Reply-To: <3E8adrsU2sm95tr7-mZsDXNMjVaaktgq9P3us0ohjJ0=.dd254c86-0459-4e3e-932d-4db626e04133@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>
 <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
 <3E8adrsU2sm95tr7-mZsDXNMjVaaktgq9P3us0ohjJ0=.dd254c86-0459-4e3e-932d-4db626e04133@github.com>
Message-ID: <erB2buuUoTNlk_q1e1971Lngum9_6d35_8IRuH0LTgI=.272996d8-a236-4794-9f54-b20efb3358b7@github.com>

On Fri, 16 Apr 2021 15:17:52 GMT, earthling-amzn <github.com+71722661+earthling-amzn at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 430:
>> 
>>> 428: 
>>> 429:   assert(r->is_empty(), "Region must be empty after flipping from mutator to GC.");
>>> 430:   r->set_affiliation(FREE);
>> 
>> Why is this block needed now?
>
> I think this could be an assert. The region should already be `FREE` at this point.

When debugging, I came across regions that were "trash" but not "FREE".

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From kdnilsen at openjdk.java.net  Wed Apr 21 20:03:58 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 21 Apr 2021 20:03:58 GMT
Subject: RFR: Mixed evacuation [v6]
In-Reply-To: <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>
Message-ID: <r9IbmW0Jc925xjPeqmo3R949XNuPhjvj4Gx7vvvsbcU=.978f4859-2023-434b-b717-c39747a330b5@github.com>

On Tue, 20 Apr 2021 00:10:04 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change definition of CollectionThresholdGarbagePercent
>   
>   This is now defined to equal ShenandoahGarbageThreshold, which seems to have
>   a default value of 25.  The effect on running workloads is to choose more
>   regions for the collection set than was observed with the previous
>   configuration.
>   
>   Also addressed several improvements in white space and comments.
>   
>   The code now runs tier1 and hotspot_gc_shenandoah without regressions.  It
>   also succsessfully runs an Extremem stress test up until the point of
>   failure due to triggering of full GC (after 113 completed GC passes, including
>   two old-gen GC passes).

Thanks for the quick turnaround on this review.  I will try to get through all these changes today.

Regarding the question of whether it makes sense to separate out the old-gen and new-gen heuristics, I think it very much makes sense to do so for the following reasons:

1. When properly configured, we expect the characteristic behaviors of young-gen and old-gen heaps to be very different.  Young-gen heap normally has a high allocation rate and a high infant mortality rate, resulting in a relatively small percentage of total heap surviving each GC.  In contrast, the old-gen heap typically has a relatively low allocation (promotion) rate, and no infant mortality rate.  If we have properly configured the promotion heuristics, any object just promoted to old-gen has the same probability of becoming garbage on the next GC pass as any other object already existing in old-gen memory.

2. Eventually, we will expect old-gen heuristics to be a bit more sophisticated and deliberate in their analysis.  In contrast, we expect young-gen to be fast and furious.  For example, old-gen will probably want to bias collection set selection not only on which regions have highest percentage of garbage, but may also consider which regions have not been collected in a very long time.  It is more likely that old-gen regions can sit and become stale.  Not very likely this would ever happen in young-gen.

3. As currently implemented, the old-gen heuristics already need to keep track of additional information that is not relevant to young-gen collections, such as (a) which old-gen regions have been selected as candidates for future evacuations, (b) which old-gen regions need to be coalesced-and-filled so their memory is parseable by GC, and (c) how many previously selected candidates for collection have not yet been evacuated.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From github.com+71722661+earthling-amzn at openjdk.java.net  Wed Apr 21 20:13:57 2021
From: github.com+71722661+earthling-amzn at openjdk.java.net (earthling-amzn)
Date: Wed, 21 Apr 2021 20:13:57 GMT
Subject: RFR: Update remembered set during old generation mark
In-Reply-To: <2Z-lTb06Yjln8CXIDVC-mbNbfrhyrcfLx5PXj0aCpas=.6bac2ecb-fcb6-459b-b325-9aec13f67a18@github.com>
References: <4oVGZXvF0jhL9Zu33QXiWY6oF5i-XaRrmp0QkSmbo8U=.8736794b-17e0-4c1f-9c73-7e3f7b3491d2@github.com>
 <2Z-lTb06Yjln8CXIDVC-mbNbfrhyrcfLx5PXj0aCpas=.6bac2ecb-fcb6-459b-b325-9aec13f67a18@github.com>
Message-ID: <PYMjyV6Ctq4rDsZDmiLIWMxWqMGv83TQ5gkzGWyvKX4=.92f7b9b3-2d3b-4bc7-a2e4-f7f52900de2b@github.com>

On Wed, 21 Apr 2021 13:10:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> This change is to support the concurrent remembered set scanning work which is in progress.
>
> src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 278:
> 
>> 276:       // Old mark, found a young pointer.
>> 277:       assert(ShenandoahHeap::heap()->is_in_young(obj), "Expected young object.");
>> 278:       ShenandoahHeap::heap()->mark_card_as_dirty((HeapWord*)p);
> 
> Just a nit, please use cast_from_oop<HeapWord*>(p) instead.

Sure, will fix this.

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

PR: https://git.openjdk.java.net/shenandoah/pull/31

From bmathiske at openjdk.java.net  Wed Apr 21 20:37:35 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Wed, 21 Apr 2021 20:37:35 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v2]
In-Reply-To: <RJb-UL_qLYKokXx58bupXifpEIGIVlF7RjnEVvtTunI=.e5cdb6dd-6bdf-4867-9374-a6056e827792@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>
 <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
 <RJb-UL_qLYKokXx58bupXifpEIGIVlF7RjnEVvtTunI=.e5cdb6dd-6bdf-4867-9374-a6056e827792@github.com>
Message-ID: <lyyzYGraykkYx7gXv_w9JKoeJLUaNuXShxzFjLbuJBI=.9a8b6d48-5553-48b5-858a-62eb9ba13be2@github.com>

On Fri, 16 Apr 2021 17:00:23 GMT, bmathiske <github.com+44619194+bmathiske at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 882:
>> 
>>> 880:   return plab->allocate(size);
>>> 881: }
>>> 882: 
>> 
>> Is this a full (or almost full) copy of allocate_from_gclab_slow() ? Maybe this warrants some refactoring/sharing?
>
> Yes, this is a full copy. Will refactor.

I tried to refactor: it quickly gets quite ugly. A lot of gclab values are hardwired into identifier names. For example, check out the upper part of allocate_from_gclab_slow()!  How can we abstract over ShenandoahThreadLocalData::gclab_size() vs. ShenandoahThreadLocalData::plab_size()? This issues repeats with other tags/labels/identifers, e.g., when creating a ShenandoahAllocRequest(). I'd have to come up with a whole new way of addressing LABs generically and that would touch a lot of code.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From kdnilsen at openjdk.java.net  Wed Apr 21 21:02:49 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 21 Apr 2021 21:02:49 GMT
Subject: RFR: Mixed evacuation [v6]
In-Reply-To: <5kYRNqZI6fd2xolzGO9ryvE4cacS9vpGOwdk2aWFTTo=.f9d9c56d-af34-4a12-8760-3629af67a716@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>
 <5kYRNqZI6fd2xolzGO9ryvE4cacS9vpGOwdk2aWFTTo=.f9d9c56d-af34-4a12-8760-3629af67a716@github.com>
Message-ID: <KWtAIBRJ1cxS-CL2pe1LBuaRINte43vOQrKpAUYJi64=.5eb440e8-595e-4476-9d91-8531f82d22fe@github.com>

On Wed, 21 Apr 2021 10:45:22 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change definition of CollectionThresholdGarbagePercent
>>   
>>   This is now defined to equal ShenandoahGarbageThreshold, which seems to have
>>   a default value of 25.  The effect on running workloads is to choose more
>>   regions for the collection set than was observed with the previous
>>   configuration.
>>   
>>   Also addressed several improvements in white space and comments.
>>   
>>   The code now runs tier1 and hotspot_gc_shenandoah without regressions.  It
>>   also succsessfully runs an Extremem stress test up until the point of
>>   failure due to triggering of full GC (after 113 completed GC passes, including
>>   two old-gen GC passes).
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 99:
> 
>> 97:                      byte_size_in_proper_unit(min_garbage), proper_unit_for_byte_size(min_garbage));
>> 98: 
>> 99: 
> 
> We have a lone newline here.

Fixed in next commit

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveOldHeuristics.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Please, only put first and last year in copyright notice (from-to).

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveOldHeuristics.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above.

Fixed in next commit.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Wed Apr 21 21:29:42 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 21 Apr 2021 21:29:42 GMT
Subject: RFR: Mixed evacuation [v6]
In-Reply-To: <5kYRNqZI6fd2xolzGO9ryvE4cacS9vpGOwdk2aWFTTo=.f9d9c56d-af34-4a12-8760-3629af67a716@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>
 <5kYRNqZI6fd2xolzGO9ryvE4cacS9vpGOwdk2aWFTTo=.f9d9c56d-af34-4a12-8760-3629af67a716@github.com>
Message-ID: <PzREp7L2oC5HMDN0aoDXQXUfRxiq4gwHX-z3G5h-thc=.2a04bdce-100c-4e84-a38f-19beb01e93da@github.com>

On Wed, 21 Apr 2021 10:56:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change definition of CollectionThresholdGarbagePercent
>>   
>>   This is now defined to equal ShenandoahGarbageThreshold, which seems to have
>>   a default value of 25.  The effect on running workloads is to choose more
>>   regions for the collection set than was observed with the previous
>>   configuration.
>>   
>>   Also addressed several improvements in white space and comments.
>>   
>>   The code now runs tier1 and hotspot_gc_shenandoah without regressions.  It
>>   also succsessfully runs an Extremem stress test up until the point of
>>   failure due to triggering of full GC (after 113 completed GC passes, including
>>   two old-gen GC passes).
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveOldHeuristics.hpp line 29:
> 
>> 27: 
>> 28: #include "gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp"
>> 29: #include "gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.hpp"
> 
> I don't think you need to include shenandoahAdaptiveHeuristics.hpp here.

The reason for including is to provide definition of ShenandoahAllocationRate, which is used by both ShenandoahAdatpvieHeuristics and ShenandoahAdaptiveOldHeuristics.  The code will compile if I remove the include here, but insert it into shenandoahAdaptiveOldHeuristics.cpp.  That's how the new commit does it.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveHeuristics.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019 Red Hat, Inc. All rights reserved.
> 
> Please don't remove the comma.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveOldHeuristics.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above. Only put in begin and end year.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAggressiveOldHeuristics.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactOldHeuristics.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahCompactOldHeuristics.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2020, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 167:
> 
>> 165:       old_heuristics->prime_collection_set(collection_set);
>> 166:     }
>> 167:     // else, thisi s global collection and doesn't need to prime_collection_set()
> 
> Typo here 'thisi s'

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 172:
> 
>> 170:   size_t collectable_garbage = collection_set->garbage() + immediate_garbage;
>> 171:   size_t collectable_garbage_percent = (total_garbage == 0) ? 0 : (collectable_garbage * 100 / total_garbage);
>> 172: 
> 
> Stray newline change.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.cpp line 204:
> 
>> 202: 
>> 203: bool ShenandoahHeuristics::should_start_gc() {
>> 204: 
> 
> Stray newline change.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahHeuristics.hpp line 155:
> 
>> 153:   double time_since_last_gc() const;
>> 154: 
>> 155: 
> 
> Stray newlines.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 26:
> 
>> 24: 
>> 25: #include "gc/shenandoah/heuristics/shenandoahOldHeuristics.hpp"
>> 26: #include "precompiled.hpp"
> 
> Convention is to always put include for precompiled.hpp first.

Fixed in next commit.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From bmathiske at openjdk.java.net  Wed Apr 21 20:50:46 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Wed, 21 Apr 2021 20:50:46 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v2]
In-Reply-To: <lyyzYGraykkYx7gXv_w9JKoeJLUaNuXShxzFjLbuJBI=.9a8b6d48-5553-48b5-858a-62eb9ba13be2@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>
 <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
 <RJb-UL_qLYKokXx58bupXifpEIGIVlF7RjnEVvtTunI=.e5cdb6dd-6bdf-4867-9374-a6056e827792@github.com>
 <lyyzYGraykkYx7gXv_w9JKoeJLUaNuXShxzFjLbuJBI=.9a8b6d48-5553-48b5-858a-62eb9ba13be2@github.com>
Message-ID: <TSYScjPSYyZwBeKv8aOSp3MAUTqfvpSopD1J0zbJdo0=.4e8392f5-e73e-435e-aa01-62ce1abaaa91@github.com>

On Wed, 21 Apr 2021 20:34:39 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

>> Yes, this is a full copy. Will refactor.
>
> I tried to refactor: it quickly gets quite ugly. A lot of gclab values are hardwired into identifier names. For example, check out the upper part of allocate_from_gclab_slow()!  How can we abstract over ShenandoahThreadLocalData::gclab_size() vs. ShenandoahThreadLocalData::plab_size()? This issues repeats with other tags/labels/identifers, e.g., when creating a ShenandoahAllocRequest(). I'd have to come up with a whole new way of addressing LABs generically and that would touch a lot of code.

A template with 4 parameters might work, but I have doubts that methods as template parameters would increase readability.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From kdnilsen at openjdk.java.net  Wed Apr 21 22:07:46 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 21 Apr 2021 22:07:46 GMT
Subject: RFR: Mixed evacuation [v6]
In-Reply-To: <5kYRNqZI6fd2xolzGO9ryvE4cacS9vpGOwdk2aWFTTo=.f9d9c56d-af34-4a12-8760-3629af67a716@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <GYD8mAj_RusaWUc_SbPGO1g9rtWBLtXuZu6bZs3FQSo=.1f1ca5ac-95f4-4ebd-8a62-31b60401f626@github.com>
 <5kYRNqZI6fd2xolzGO9ryvE4cacS9vpGOwdk2aWFTTo=.f9d9c56d-af34-4a12-8760-3629af67a716@github.com>
Message-ID: <dnt5IRHsSFiusic6r9dttbTutjBcKODUeNMO-6opZ7E=.dde2801a-59a9-4808-aa3b-77ae47c67345@github.com>

On Wed, 21 Apr 2021 11:05:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change definition of CollectionThresholdGarbagePercent
>>   
>>   This is now defined to equal ShenandoahGarbageThreshold, which seems to have
>>   a default value of 25.  The effect on running workloads is to choose more
>>   regions for the collection set than was observed with the previous
>>   configuration.
>>   
>>   Also addressed several improvements in white space and comments.
>>   
>>   The code now runs tier1 and hotspot_gc_shenandoah without regressions.  It
>>   also succsessfully runs an Extremem stress test up until the point of
>>   failure due to triggering of full GC (after 113 completed GC passes, including
>>   two old-gen GC passes).
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 67:
> 
>> 65:   // collection set selection.  Here, we'd rather fall back to this contingent behavior than force a full STW
>> 66:   // collection.
>> 67: #define PROMOTION_BUDGET_BYTES (ShenandoahHeapRegion::region_size_bytes() / 2)
> 
> I'd put macro definitions at the top of the file, right below the includes.

replaced with C++ constant in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 220:
> 
>> 218:   // future, this threshold percentage may be specified on the command
>> 219:   // line or preferrably determined by dynamic heuristics.
>> 220: #define CollectionThresholdGarbagePercent ShenandoahGarbageThreshold
> 
> Same as above: please place define at top of file.

replaced with C++ constant in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 249:
> 
>> 247:   _old_coalesce_and_fill_candidates = 0;
>> 248: 
>> 249: #undef CollectionThresholdGarbagePercent
> 
> I don't think the constants need to be undef-ed when defined at top of file. Alternatively, you may consider making them true C++ constants.

Replaced with C++ constant in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveOldHeuristics.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above, only use first and last years.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahPassiveOldHeuristics.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp line 32:
> 
>> 30: // TODO: Make this a subclass of ShenandoahHeuristics and create a "tailored" copy of this class to be subclass of
>> 31: // ShenandoahOldHeuristics.  Fix the constructor implementation to invoke ShenandoahHeuristics() superclass constructor.
>> 32: // Change ShenandoahMode::initialize_old_heuristics() to return the subclass of ShenandoahOldHeuristics.
> 
> Is this comment still valid? You seem to propose a ShenandoahStaticOldHeuristics too.

Oops.  Forgot to remove that.  Removed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticOldHeuristics.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above.

Fixed in next commit.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahStaticOldHeuristics.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2018, 2019, 2021, Red Hat, Inc. All rights reserved.
> 
> Same as above.

Fixed in next commit.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Wed Apr 21 23:48:09 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Wed, 21 Apr 2021 23:48:09 GMT
Subject: RFR: Mixed evacuation [v7]
In-Reply-To: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
Message-ID: <gIvJpLvquwBlbUUfihO0W_3_mns-e1opjqNjagULz-M=.e211b71e-b84e-43f2-8e91-8afeb73495af@github.com>

> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.

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

  Cosmetic improvements requested by review
  
  Following these changes, we ran jtreg TIER1 and hotspot_gc_shenandoah tests with no regressions.
  Also ran a stress Extremem workload.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/29/files
  - new: https://git.openjdk.java.net/shenandoah/pull/29/files/c8377a53..d6fa428b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=05-06

  Stats: 81 lines in 16 files changed: 17 ins; 13 del; 51 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/29/head:pull/29

PR: https://git.openjdk.java.net/shenandoah/pull/29

From rkennke at openjdk.java.net  Thu Apr 22 08:38:43 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 22 Apr 2021 08:38:43 GMT
Subject: RFR: Mixed evacuation [v7]
In-Reply-To: <gIvJpLvquwBlbUUfihO0W_3_mns-e1opjqNjagULz-M=.e211b71e-b84e-43f2-8e91-8afeb73495af@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <gIvJpLvquwBlbUUfihO0W_3_mns-e1opjqNjagULz-M=.e211b71e-b84e-43f2-8e91-8afeb73495af@github.com>
Message-ID: <TNWAKrrZrg-SzzPcGun1s1czyBFHpCzyyH7mvuM9OIM=.b5a802b6-3dcd-419c-9846-f73b0fafd918@github.com>

On Wed, 21 Apr 2021 23:48:09 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cosmetic improvements requested by review
>   
>   Following these changes, we ran jtreg TIER1 and hotspot_gc_shenandoah tests with no regressions.
>   Also ran a stress Extremem workload.

Looks good to me, thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/29

From rkennke at openjdk.java.net  Thu Apr 22 15:24:34 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 22 Apr 2021 15:24:34 GMT
Subject: RFR: 8265759: Shenandoah: Avoid race for referent in assert
Message-ID: <vwlS_DDIGkSwJMDYDOc_yjNvSb7FLDfsebRHO8OZtI4=.c7c4055b-d758-4412-ab81-68774b2d79ff@github.com>

There is an assert is ShenandoahReferenceProcessor::drop() which is racy: when referent is concurrently cleaned it may enter mark-bit-map with NULL even though we just checked that the referent is not NULL.

Testing:
 - [x] hotspot_gc_shenandoah

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

Commit messages:
 - 8265759: Shenandoah: Avoid race for referent in assert

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

PR: https://git.openjdk.java.net/jdk/pull/3632

From shade at openjdk.java.net  Thu Apr 22 16:39:23 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 22 Apr 2021 16:39:23 GMT
Subject: RFR: 8265759: Shenandoah: Avoid race for referent in assert
In-Reply-To: <vwlS_DDIGkSwJMDYDOc_yjNvSb7FLDfsebRHO8OZtI4=.c7c4055b-d758-4412-ab81-68774b2d79ff@github.com>
References: <vwlS_DDIGkSwJMDYDOc_yjNvSb7FLDfsebRHO8OZtI4=.c7c4055b-d758-4412-ab81-68774b2d79ff@github.com>
Message-ID: <SFjanBrIQfmLyjMk5jC_aaKLQ33StQ2Mm2iWymHM4Xs=.cff802d3-eb62-4e43-a316-65ad0b264742@github.com>

On Thu, 22 Apr 2021 15:17:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> There is an assert is ShenandoahReferenceProcessor::drop() which is racy: when referent is concurrently cleaned it may enter mark-bit-map with NULL even though we just checked that the referent is not NULL.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah

Looks good! Minor nit:

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.cpp line 392:

> 390:   oop referent = reference_referent<T>(reference);
> 391:   assert(referent == NULL ||
> 392:          ShenandoahHeap::heap()->marking_context()->is_marked(referent), "only drop references with alive referents");

I would prefer it to be line-broken like this: 

assert(referent == NULL || ShenandoahHeap::heap()->marking_context()->is_marked(referent), 
       "only drop references with alive referents");

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3632

From zgu at openjdk.java.net  Thu Apr 22 17:58:49 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 22 Apr 2021 17:58:49 GMT
Subject: RFR: Mixed evacuation [v7]
In-Reply-To: <gIvJpLvquwBlbUUfihO0W_3_mns-e1opjqNjagULz-M=.e211b71e-b84e-43f2-8e91-8afeb73495af@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <gIvJpLvquwBlbUUfihO0W_3_mns-e1opjqNjagULz-M=.e211b71e-b84e-43f2-8e91-8afeb73495af@github.com>
Message-ID: <MlBXKPzBRTArIEVfQszkSnLAMvqk5_N95mIvGa9EZ0Y=.4324fdcb-a161-41fd-8901-076a57b2e8f2@github.com>

On Wed, 21 Apr 2021 23:48:09 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cosmetic improvements requested by review
>   
>   Following these changes, we ran jtreg TIER1 and hotspot_gc_shenandoah tests with no regressions.
>   Also ran a stress Extremem workload.

Changes requested by zgu (Reviewer).

src/hotspot/share/gc/shenandoah/mode/shenandoahMode.cpp line 58:

> 56: ShenandoahOldHeuristics* ShenandoahMode::initialize_old_heuristics(ShenandoahGeneration* generation) const {
> 57: 
> 58:   if (ShenandoahGCHeuristics != NULL) {

Should be assert or guarantee ?

src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp line 65:

> 63: 
> 64: ShenandoahOldHeuristics* ShenandoahPassiveMode::initialize_old_heuristics(ShenandoahGeneration* generation) const {
> 65:   if (ShenandoahGCHeuristics != NULL) {

Looks like you can convert this if stmt to assert or guarantee?

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

> 128:   virtual bool is_concurrent_mark_in_progress() = 0;
> 129: 
> 130:  private:

Style nit: no leading space. The same as "protected" above (pre-exist)

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

> 494:   CollectedHeap(),
> 495:   _gc_generation(NULL),
> 496:   _old_heuristics(NULL),

Minor style nit: jdk17 started to use nullptr to replace NULL

src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp line 88:

> 86:   entry_coalesce_and_fill();
> 87: 
> 88:   old_heuristics->start_old_evacuations();

Could you encapsulate in entry_old_evacuations() with proper timing/logging?  it really helps future debugging the crashes with hs_err file.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From zgu at openjdk.java.net  Thu Apr 22 18:36:25 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 22 Apr 2021 18:36:25 GMT
Subject: RFR: 8265759: Shenandoah: Avoid race for referent in assert
In-Reply-To: <vwlS_DDIGkSwJMDYDOc_yjNvSb7FLDfsebRHO8OZtI4=.c7c4055b-d758-4412-ab81-68774b2d79ff@github.com>
References: <vwlS_DDIGkSwJMDYDOc_yjNvSb7FLDfsebRHO8OZtI4=.c7c4055b-d758-4412-ab81-68774b2d79ff@github.com>
Message-ID: <0KmTMHHuk4LL2JNO_JqNJBeurroj1Ha-4BinnPxgRkQ=.82e6fee7-273b-42c1-8880-73848f8c43af@github.com>

On Thu, 22 Apr 2021 15:17:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> There is an assert is ShenandoahReferenceProcessor::drop() which is racy: when referent is concurrently cleaned it may enter mark-bit-map with NULL even though we just checked that the referent is not NULL.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah

Marked as reviewed by zgu (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3632

From rkennke at openjdk.java.net  Thu Apr 22 19:19:48 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 22 Apr 2021 19:19:48 GMT
Subject: RFR: 8265759: Shenandoah: Avoid race for referent in assert [v2]
In-Reply-To: <vwlS_DDIGkSwJMDYDOc_yjNvSb7FLDfsebRHO8OZtI4=.c7c4055b-d758-4412-ab81-68774b2d79ff@github.com>
References: <vwlS_DDIGkSwJMDYDOc_yjNvSb7FLDfsebRHO8OZtI4=.c7c4055b-d758-4412-ab81-68774b2d79ff@github.com>
Message-ID: <YUVKpaJP8LRabaTrI36Vl8rHcGNECAmNcGSIV9d8eEg=.b9523ca9-ff74-4f94-85d0-b20a746e152b@github.com>

> There is an assert is ShenandoahReferenceProcessor::drop() which is racy: when referent is concurrently cleaned it may enter mark-bit-map with NULL even though we just checked that the referent is not NULL.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Fix formatting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3632/files
  - new: https://git.openjdk.java.net/jdk/pull/3632/files/73a36ca4..18b8a6f5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3632&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3632&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/3632

From zgu at redhat.com  Thu Apr 22 21:30:20 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Thu, 22 Apr 2021 17:30:20 -0400
Subject: [sh/jdk8u] Process weak roots for class unloading cycles
Message-ID: <679daa2b-fe2a-11fb-c26f-e58ad44c1b8f@redhat.com>

In jdk8u, Shenandoah marks through weak roots if class unloading is off 
for the cycle, so that, Shenandoah only needs to process weak roots for 
class unloading cycle.

Currently, we have following logic:

  490   if (_heap->process_references()) {
  491     weak_refs_work(full_gc);
  492   } else {
  493     weak_roots_work(full_gc);
  494   }

which suggests weak roots have something to do with reference 
processing, that seems wrong. I thought we have corrected this before, 
maybe in 11u?

Webrev: 
http://cr.openjdk.java.net/~zgu/shenandoah/weak_roots_processing/webrev/

Test:
   hotspot_gc_shenandoah

Thanks,

-Zhengyu


From rkennke at openjdk.java.net  Fri Apr 23 08:04:26 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 23 Apr 2021 08:04:26 GMT
Subject: Integrated: 8265759: Shenandoah: Avoid race for referent in assert
In-Reply-To: <vwlS_DDIGkSwJMDYDOc_yjNvSb7FLDfsebRHO8OZtI4=.c7c4055b-d758-4412-ab81-68774b2d79ff@github.com>
References: <vwlS_DDIGkSwJMDYDOc_yjNvSb7FLDfsebRHO8OZtI4=.c7c4055b-d758-4412-ab81-68774b2d79ff@github.com>
Message-ID: <4d05qb-uXi2pvxRf6fawk5ReEwXIQevn6F-zt2tH8Zw=.c1c630c7-6b33-4525-8c08-3c834217e11c@github.com>

On Thu, 22 Apr 2021 15:17:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> There is an assert is ShenandoahReferenceProcessor::drop() which is racy: when referent is concurrently cleaned it may enter mark-bit-map with NULL even though we just checked that the referent is not NULL.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 191f1fc4
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/191f1fc4
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8265759: Shenandoah: Avoid race for referent in assert

Reviewed-by: shade, zgu

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

PR: https://git.openjdk.java.net/jdk/pull/3632

From rkennke at redhat.com  Fri Apr 23 11:49:04 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 23 Apr 2021 13:49:04 +0200
Subject: [sh/jdk8u] Process weak roots for class unloading cycles
In-Reply-To: <679daa2b-fe2a-11fb-c26f-e58ad44c1b8f@redhat.com>
References: <679daa2b-fe2a-11fb-c26f-e58ad44c1b8f@redhat.com>
Message-ID: <427c8c3f-8809-bca0-69ac-5fd3466ed6e5@redhat.com>

Looks good to me. Thank you!

Roman

> In jdk8u, Shenandoah marks through weak roots if class unloading is off 
> for the cycle, so that, Shenandoah only needs to process weak roots for 
> class unloading cycle.
> 
> Currently, we have following logic:
> 
> 490?? if (_heap->process_references()) {
> 491???? weak_refs_work(full_gc);
> 492?? } else {
> 493???? weak_roots_work(full_gc);
> 494?? }
> 
> which suggests weak roots have something to do with reference 
> processing, that seems wrong. I thought we have corrected this before, 
> maybe in 11u?
> 
> Webrev: 
> http://cr.openjdk.java.net/~zgu/shenandoah/weak_roots_processing/webrev/
> 
> Test:
>  ?hotspot_gc_shenandoah
> 
> Thanks,
> 
> -Zhengyu
> 


From zgu at redhat.com  Fri Apr 23 15:02:40 2021
From: zgu at redhat.com (zgu at redhat.com)
Date: Fri, 23 Apr 2021 15:02:40 +0000
Subject: hg: shenandoah/jdk8/hotspot: Shenandoah: Process weak roots during
 class unloading cycle
Message-ID: <202104231502.13NF2epg011086@aojmv0008.oracle.com>

Changeset: 245830973eba
Author:    zgu
Date:      2021-04-23 11:02 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/hotspot/rev/245830973eba

Shenandoah: Process weak roots during class unloading cycle
Reviewed-by: rkennke

! src/share/vm/gc_implementation/shenandoah/shenandoahConcurrentMark.cpp
! src/share/vm/gc_implementation/shenandoah/shenandoahParallelCleaning.hpp


From ayang at openjdk.java.net  Fri Apr 23 20:11:35 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 23 Apr 2021 20:11:35 GMT
Subject: RFR: 8234446: Post-CMS workgroup hierarchy cleanup
Message-ID: <nDYB1awSv8VTQx6_xcTguPcqC0-c3LzFHE2qDPOBq48=.52d85827-7783-4415-9280-dbe3b067e88f@github.com>

Collapse workgroup hierarchy and some general cleanup.

Tested; hotspot_gc

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

Commit messages:
 - rename GangWorker
 - AbstractGangWorker
 - WorkGang
 - cleanup

Changes: https://git.openjdk.java.net/jdk/pull/3663/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3663&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8234446
  Stats: 291 lines in 5 files changed: 86 ins; 165 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3663/head:pull/3663

PR: https://git.openjdk.java.net/jdk/pull/3663

From kdnilsen at openjdk.java.net  Sat Apr 24 14:23:47 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Sat, 24 Apr 2021 14:23:47 GMT
Subject: RFR: Mixed evacuation [v7]
In-Reply-To: <MlBXKPzBRTArIEVfQszkSnLAMvqk5_N95mIvGa9EZ0Y=.4324fdcb-a161-41fd-8901-076a57b2e8f2@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <gIvJpLvquwBlbUUfihO0W_3_mns-e1opjqNjagULz-M=.e211b71e-b84e-43f2-8e91-8afeb73495af@github.com>
 <MlBXKPzBRTArIEVfQszkSnLAMvqk5_N95mIvGa9EZ0Y=.4324fdcb-a161-41fd-8901-076a57b2e8f2@github.com>
Message-ID: <NWJ4pqSL4nfBudkIvs7GlALQ_Mzyrqly6GTrCid58Js=.ae9b51e3-96ee-4cf6-b105-707ce5e3d93a@github.com>

On Thu, 22 Apr 2021 15:12:58 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cosmetic improvements requested by review
>>   
>>   Following these changes, we ran jtreg TIER1 and hotspot_gc_shenandoah tests with no regressions.
>>   Also ran a stress Extremem workload.
>
> src/hotspot/share/gc/shenandoah/mode/shenandoahMode.cpp line 58:
> 
>> 56: ShenandoahOldHeuristics* ShenandoahMode::initialize_old_heuristics(ShenandoahGeneration* generation) const {
>> 57: 
>> 58:   if (ShenandoahGCHeuristics != NULL) {
> 
> Should be assert or guarantee ?

Thanks.  Replaced with assert.  Will see in next commit.

> src/hotspot/share/gc/shenandoah/mode/shenandoahPassiveMode.cpp line 65:
> 
>> 63: 
>> 64: ShenandoahOldHeuristics* ShenandoahPassiveMode::initialize_old_heuristics(ShenandoahGeneration* generation) const {
>> 65:   if (ShenandoahGCHeuristics != NULL) {
> 
> Looks like you can convert this if stmt to assert or guarantee?

Thanks for careful second review of the code.  This is changed to assert in next commit.

> src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp line 130:
> 
>> 128:   virtual bool is_concurrent_mark_in_progress() = 0;
>> 129: 
>> 130:  private:
> 
> Style nit: no leading space. The same as "protected" above (pre-exist)

Thanks.  I've fixed private.  Also fixed protected above.  They both had spaces.  Will see these changes in next commit.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 496:
> 
>> 494:   CollectedHeap(),
>> 495:   _gc_generation(NULL),
>> 496:   _old_heuristics(NULL),
> 
> Minor style nit: jdk17 started to use nullptr to replace NULL

Thanks.  Fixed in next commit.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Sat Apr 24 14:31:48 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Sat, 24 Apr 2021 14:31:48 GMT
Subject: RFR: Mixed evacuation [v7]
In-Reply-To: <MlBXKPzBRTArIEVfQszkSnLAMvqk5_N95mIvGa9EZ0Y=.4324fdcb-a161-41fd-8901-076a57b2e8f2@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <gIvJpLvquwBlbUUfihO0W_3_mns-e1opjqNjagULz-M=.e211b71e-b84e-43f2-8e91-8afeb73495af@github.com>
 <MlBXKPzBRTArIEVfQszkSnLAMvqk5_N95mIvGa9EZ0Y=.4324fdcb-a161-41fd-8901-076a57b2e8f2@github.com>
Message-ID: <9Y-irXYzM21Di0lSHi02iE863AF8pGsi6cRY8Lb7K9U=.20da6bfa-60b4-4723-9d33-ae86984b49ea@github.com>

On Thu, 22 Apr 2021 17:53:30 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cosmetic improvements requested by review
>>   
>>   Following these changes, we ran jtreg TIER1 and hotspot_gc_shenandoah tests with no regressions.
>>   Also ran a stress Extremem workload.
>
> src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp line 88:
> 
>> 86:   entry_coalesce_and_fill();
>> 87: 
>> 88:   old_heuristics->start_old_evacuations();
> 
> Could you encapsulate in entry_old_evacuations() with proper timing/logging?  it really helps future debugging the crashes with hs_err file.

Thanks.  I've created new function entry_old_evacuations(), which calls entry_coalesce_and_fill() followed by old_heuristics->start_old_evacuations().  There is already timing/logging in entry_coalesce_and_fill().  old_heuristics->start_old_evacuations() just "flips a switch" so that subsequent evacuations will fold in old-gen collection sets so I don't think we need any timing there.

This will show up in next commit.

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Sat Apr 24 16:03:16 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Sat, 24 Apr 2021 16:03:16 GMT
Subject: RFR: Mixed evacuation [v8]
In-Reply-To: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
Message-ID: <k4fJ7X725LqZG1JTJ8lgBsBZ6G3ogMiPpswbSATmNlo=.4a99a152-8c13-4a44-99c9-944f29c33d85@github.com>

> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.

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

  Additional changes requested by reviewers
  
  This code builds and tests TIER1 and hotspot_gc_shenandoah with no regressions.  It also runs a generational GC stress test.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/29/files
  - new: https://git.openjdk.java.net/shenandoah/pull/29/files/d6fa428b..0c99ef2b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=29&range=06-07

  Stats: 38 lines in 6 files changed: 10 ins; 10 del; 18 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/29.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/29/head:pull/29

PR: https://git.openjdk.java.net/shenandoah/pull/29

From zgu at openjdk.java.net  Sat Apr 24 23:03:48 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Sat, 24 Apr 2021 23:03:48 GMT
Subject: RFR: Mixed evacuation [v8]
In-Reply-To: <k4fJ7X725LqZG1JTJ8lgBsBZ6G3ogMiPpswbSATmNlo=.4a99a152-8c13-4a44-99c9-944f29c33d85@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <k4fJ7X725LqZG1JTJ8lgBsBZ6G3ogMiPpswbSATmNlo=.4a99a152-8c13-4a44-99c9-944f29c33d85@github.com>
Message-ID: <D6fnG_7EhcT31UjWCaAdGiIWy5a0b2fgSzYvjE1wS4s=.b01aa6ff-86c5-4cf1-800a-65698f971147@github.com>

On Sat, 24 Apr 2021 16:03:16 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional changes requested by reviewers
>   
>   This code builds and tests TIER1 and hotspot_gc_shenandoah with no regressions.  It also runs a generational GC stress test.

Marked as reviewed by zgu (Reviewer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From zgu at openjdk.java.net  Mon Apr 26 19:18:50 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Mon, 26 Apr 2021 19:18:50 GMT
Subject: RFR: 8265995: Shenandoah: Move ShenandoahInitMarkRootsClosure close
 to its use
Message-ID: <DjWMMaU7QzSNpcIcDo2PfuaryhT2nDtXOfl2sevwWxw=.ee32ba12-0dcf-4fc9-b6dd-66796587857a@github.com>

ShenandoahInitMarkRootsClosure is only used by STW mark, let's move it there.

Test:
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - JDK-8265995

Changes: https://git.openjdk.java.net/jdk/pull/3701/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3701&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8265995
  Stats: 49 lines in 4 files changed: 24 ins; 25 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3701.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3701/head:pull/3701

PR: https://git.openjdk.java.net/jdk/pull/3701

From kvn at openjdk.java.net  Mon Apr 26 22:45:25 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 26 Apr 2021 22:45:25 GMT
Subject: RFR: 8264805: Remove the experimental Ahead-of-Time Compiler [v6]
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <nltrVq6SKEmgbuz4LuFlhxOqflGrSyf04EhJefvGxUA=.b01a8293-d4c2-4f8f-8e59-9d2ca2a7db4e@github.com>

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

Vladimir Kozlov 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 JDK-8264805
 - Address review comments
 - Remove exports from Graal module to jdk.aot
 - Merge branch 'master' into JDK-8264805
 - Merge branch 'master' into JDK-8264805
 - 8264805: Remove the experimental Ahead-of-Time Compiler

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

Changes: https://git.openjdk.java.net/jdk/pull/3398/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3398&range=05
  Stats: 26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3398.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3398/head:pull/3398

PR: https://git.openjdk.java.net/jdk/pull/3398

From bmathiske at openjdk.java.net  Mon Apr 26 23:03:03 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Mon, 26 Apr 2021 23:03:03 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v2]
In-Reply-To: <erB2buuUoTNlk_q1e1971Lngum9_6d35_8IRuH0LTgI=.272996d8-a236-4794-9f54-b20efb3358b7@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <a1Th6W_q8UFGtPxA04nMaea3b1ZmVoCy8geWodlRuDg=.2acd053f-3545-4eed-8c90-f686b047e178@github.com>
 <5jkA4CqYYC3eMiyxet4LIbREmo9fOP4Sjox7svgtFDY=.36fa1217-9f12-491a-bd28-cf6b9b62e07f@github.com>
 <3E8adrsU2sm95tr7-mZsDXNMjVaaktgq9P3us0ohjJ0=.dd254c86-0459-4e3e-932d-4db626e04133@github.com>
 <erB2buuUoTNlk_q1e1971Lngum9_6d35_8IRuH0LTgI=.272996d8-a236-4794-9f54-b20efb3358b7@github.com>
Message-ID: <bxTorTtZoyX2DKG97tbbuZzqTrP6aMsLnqoLjaq3Wu4=.de810abb-7397-471a-acaa-beefff45c840@github.com>

On Wed, 21 Apr 2021 19:33:25 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

>> I think this could be an assert. The region should already be `FREE` at this point.
>
> When debugging, I came across regions that were "trash" but not "FREE".

Turns out that was OK, because the code at hand here is actually always followed by code that does the same (in try_allocate_in()). My code insertion here is thus redundant. I will remove it.

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

PR: https://git.openjdk.java.net/shenandoah/pull/30

From bmathiske at openjdk.java.net  Mon Apr 26 23:19:21 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Mon, 26 Apr 2021 23:19:21 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v3]
In-Reply-To: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
Message-ID: <AAmmuCA0fh5g9PQuXQE1vZs3TawvbrBnv9SckxBG4ms=.7cacd2cb-fec1-4bdf-b5f9-dba4967a14ce@github.com>

> Introducing a 3rd kind of LAB for generational mode: "PLAB".
> 
> Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB. 
> 
> When not in generational mode, GCLABs work as before and PLABs are never used.
> 
> The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.
> 
> Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".
> 
> In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?
> 
> Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)

Bernd Mathiske has updated the pull request incrementally with four additional commits since the last revision:

 - Remove redundant trash recycling in flip_to_gc().
 - Only register old filler objects when evacuation copy fails
 - Register 'filler' objects with remembered set when plabs are retired
 - Register object starts when allocating from PLAB

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/30/files
  - new: https://git.openjdk.java.net/shenandoah/pull/30/files/583c2038..3b36cc7f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=30&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=30&range=01-02

  Stats: 41 lines in 6 files changed: 29 ins; 3 del; 9 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/30.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/30/head:pull/30

PR: https://git.openjdk.java.net/shenandoah/pull/30

From kvn at openjdk.java.net  Tue Apr 27 01:15:37 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Tue, 27 Apr 2021 01:15:37 GMT
Subject: Integrated: 8264805: Remove the experimental Ahead-of-Time Compiler
In-Reply-To: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
References: <htGZLWVSRYCCgAxxxVYXEqMOOc2KFQV-v-8pprU4Cx0=.99fe39f9-612f-4403-b3d2-7ae8f1566734@github.com>
Message-ID: <3MIAR4n0RJot9rerXkZf7hB7NlYhJbPI6ri5q9IP3SM=.c6fecb4a-0d84-4c78-bf41-b750ee03d6df@github.com>

On Thu, 8 Apr 2021 15:23:52 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> As part of [JEP 410](http://openjdk.java.net/jeps/410) remove code related to Ahead-of-Time Compiler from JDK: 
> 
> - `jdk.aot` module ? the `jaotc` tool 
> - `src/hotspot/share/aot` ? loads AoT compiled code into VM for execution 
> - related HotSpot code guarded by `#if INCLUDE_AOT` 
> 
> Additionally, remove tests as well as code in makefiles related to AoT compilation.
> 
> Tested hs-tier1-4

This pull request has now been integrated.

Changeset: 694acedf
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/694acedf
Stats:     26972 lines in 378 files changed: 2 ins; 26772 del; 198 mod

8264805: Remove the experimental Ahead-of-Time Compiler

Reviewed-by: coleenp, erikj, stefank, iignatyev, dholmes, aph, shade, iklam, mchung, iveresov

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

PR: https://git.openjdk.java.net/jdk/pull/3398

From shade at openjdk.java.net  Tue Apr 27 06:15:36 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Apr 2021 06:15:36 GMT
Subject: RFR: 8265995: Shenandoah: Move ShenandoahInitMarkRootsClosure
 close to its use
In-Reply-To: <DjWMMaU7QzSNpcIcDo2PfuaryhT2nDtXOfl2sevwWxw=.ee32ba12-0dcf-4fc9-b6dd-66796587857a@github.com>
References: <DjWMMaU7QzSNpcIcDo2PfuaryhT2nDtXOfl2sevwWxw=.ee32ba12-0dcf-4fc9-b6dd-66796587857a@github.com>
Message-ID: <r3-mAlIN86eV7RvtOVa6RElAo1wrQm99WLSKJptxWBo=.5220a931-34e9-4db4-bb07-f94db28b2d87@github.com>

On Mon, 26 Apr 2021 17:55:41 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahInitMarkRootsClosure is only used by STW mark, let's move it there.
> 
> Test:
> - [x] hotspot_gc_shenandoah

Looks fine.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3701

From zgu at openjdk.java.net  Tue Apr 27 12:43:36 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 27 Apr 2021 12:43:36 GMT
Subject: Integrated: 8265995: Shenandoah: Move ShenandoahInitMarkRootsClosure
 close to its use
In-Reply-To: <DjWMMaU7QzSNpcIcDo2PfuaryhT2nDtXOfl2sevwWxw=.ee32ba12-0dcf-4fc9-b6dd-66796587857a@github.com>
References: <DjWMMaU7QzSNpcIcDo2PfuaryhT2nDtXOfl2sevwWxw=.ee32ba12-0dcf-4fc9-b6dd-66796587857a@github.com>
Message-ID: <QFNx8lJwWKNP-uOOf4fTjTW-srhPMsYEE6ylaEHB2cY=.d94644b9-737e-4297-9afe-43fd23f05754@github.com>

On Mon, 26 Apr 2021 17:55:41 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> ShenandoahInitMarkRootsClosure is only used by STW mark, let's move it there.
> 
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 9adbf156
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9adbf156
Stats:     49 lines in 4 files changed: 24 ins; 25 del; 0 mod

8265995: Shenandoah: Move ShenandoahInitMarkRootsClosure close to its use

Reviewed-by: shade

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

PR: https://git.openjdk.java.net/jdk/pull/3701

From kdnilsen at openjdk.java.net  Tue Apr 27 13:55:07 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 27 Apr 2021 13:55:07 GMT
Subject: RFR: Mixed evacuation [v8]
In-Reply-To: <k4fJ7X725LqZG1JTJ8lgBsBZ6G3ogMiPpswbSATmNlo=.4a99a152-8c13-4a44-99c9-944f29c33d85@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <k4fJ7X725LqZG1JTJ8lgBsBZ6G3ogMiPpswbSATmNlo=.4a99a152-8c13-4a44-99c9-944f29c33d85@github.com>
Message-ID: <a3U-JojkKrB_fXwIs1Gq_lXVm1ELDnsaeLX2X6g-hlQ=.26e66067-113f-400d-b167-704cabfdc6e6@github.com>

On Sat, 24 Apr 2021 16:03:16 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional changes requested by reviewers
>   
>   This code builds and tests TIER1 and hotspot_gc_shenandoah with no regressions.  It also runs a generational GC stress test.

Are we looking for further reviews or is this ok to be merged now?

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Tue Apr 27 14:07:10 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 27 Apr 2021 14:07:10 GMT
Subject: RFR: Mixed evacuation [v8]
In-Reply-To: <k4fJ7X725LqZG1JTJ8lgBsBZ6G3ogMiPpswbSATmNlo=.4a99a152-8c13-4a44-99c9-944f29c33d85@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
 <k4fJ7X725LqZG1JTJ8lgBsBZ6G3ogMiPpswbSATmNlo=.4a99a152-8c13-4a44-99c9-944f29c33d85@github.com>
Message-ID: <pX_K7VFLAes48KEmW8CQGsmeeFn6_5oGXHcMjguiC20=.6de01e11-42f0-47a5-b353-330fa34eb962@github.com>

On Sat, 24 Apr 2021 16:03:16 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Additional changes requested by reviewers
>   
>   This code builds and tests TIER1 and hotspot_gc_shenandoah with no regressions.  It also runs a generational GC stress test.

Thanks

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From kdnilsen at openjdk.java.net  Tue Apr 27 14:07:12 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Tue, 27 Apr 2021 14:07:12 GMT
Subject: Integrated: Mixed evacuation
In-Reply-To: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
References: <UoIije6QwOKOZSF0h9nxywMBTrKm04bjh7KoppgNf80=.16c08fb3-c4c9-4571-a2c2-21c3a21ad16a@github.com>
Message-ID: <F9oEq6e0a7gUA8uEVdFpNsKM51zqGW0hHv4caNQqv8k=.46bc5a4b-a4ca-493c-a4d6-62e14d4da6f7@github.com>

On Wed, 7 Apr 2021 20:43:31 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> This code adds to generational Shenandoah the ability to perform concurrent garbage collection of young-gen and old-gen memory. Following completion of an old-gen concurrent marking effort, we select certain old-gen heap regions to serve as candidates for future collection sets. All dead objects within the old-gen heap regions that are not part of this candidate set are coalesced and filled so that remembered-set scanning of these old-gen heap regions will not be confused by "zombie objects" (objects that old-gen has decided are dead, which reside in regions that have not yet been collected). After concurrently coalescing and filling these dead objects, each subsequent young-gen evacuation pass includes a subset of the old-gen candidates until all candidates have been collected. This code passes TIER1 and hotspot-gc-shenandoah jtreg tests without regressions. A new jtreg test has been added to exercise concurrent old/young GC.

This pull request has now been integrated.

Changeset: 68ce49bd
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
Committer: Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/68ce49bd
Stats:     1846 lines in 31 files changed: 1786 ins; 30 del; 30 mod

Mixed evacuation

Reviewed-by: zgu, rkennke

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

PR: https://git.openjdk.java.net/shenandoah/pull/29

From tschatzl at openjdk.java.net  Tue Apr 27 14:11:36 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Tue, 27 Apr 2021 14:11:36 GMT
Subject: RFR: 8234446: Post-CMS workgroup hierarchy cleanup
In-Reply-To: <nDYB1awSv8VTQx6_xcTguPcqC0-c3LzFHE2qDPOBq48=.52d85827-7783-4415-9280-dbe3b067e88f@github.com>
References: <nDYB1awSv8VTQx6_xcTguPcqC0-c3LzFHE2qDPOBq48=.52d85827-7783-4415-9280-dbe3b067e88f@github.com>
Message-ID: <uq1A89MQ7yGHMN60o2u3pCbwLIyN_EwUCGWKBprqpls=.49e18bd7-0116-43be-8208-5d6e862951c5@github.com>

On Fri, 23 Apr 2021 20:06:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Collapse workgroup hierarchy and some general cleanup.
> 
> Tested; hotspot_gc

Mostly further cleanup suggestions.

src/hotspot/share/gc/shared/workerManager.hpp line 53:

> 51:   // If initializing = false, there are already some number of worker
> 52:   // threads and a failure would not be optimal but should not be fatal.
> 53:   static uint add_workers (WorkGang* holder,

s/holder/workers

src/hotspot/share/gc/shared/workerManager.hpp line 61:

> 59: 
> 60:   // Log (at trace level) a change in the number of created workers.
> 61:   static void log_worker_creation(WorkGang* holder,

s/holder/workers

src/hotspot/share/gc/shared/workgroup.cpp line 133:

> 131: 
> 132: WorkGang::WorkGang(const char* name, uint workers, bool are_GC_task_threads, bool are_ConcurrentGC_threads) :
> 133:       _workers(NULL),

Pre-existing: the indentation is completely arbitrary here. Please use something like 2 spaces.

src/hotspot/share/gc/shared/workgroup.hpp line 84:

> 82: // The work gang is the collection of workers to execute tasks.
> 83: // The number of workers run for a task is "_active_workers"
> 84: // while "_total_workers" is the number of available of workers.

Pre-existing: The second "of" is one too many.

src/hotspot/share/gc/shared/workgroup.hpp line 86:

> 84: // while "_total_workers" is the number of available of workers.
> 85: class WorkGang : public CHeapObj<mtInternal> {
> 86:  private:

The `private` can be removed.

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

Changes requested by tschatzl (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3663

From ayang at openjdk.java.net  Tue Apr 27 14:25:56 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 27 Apr 2021 14:25:56 GMT
Subject: RFR: 8234446: Post-CMS workgroup hierarchy cleanup [v2]
In-Reply-To: <nDYB1awSv8VTQx6_xcTguPcqC0-c3LzFHE2qDPOBq48=.52d85827-7783-4415-9280-dbe3b067e88f@github.com>
References: <nDYB1awSv8VTQx6_xcTguPcqC0-c3LzFHE2qDPOBq48=.52d85827-7783-4415-9280-dbe3b067e88f@github.com>
Message-ID: <jqwF7XT9Ijvqy6lMxGE4QibatGX_VwTIzNKBc-HJE0k=.1bee9a01-46d9-459d-8bf3-a75356593dc7@github.com>

> Collapse workgroup hierarchy and some general cleanup.
> 
> Tested; hotspot_gc

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

  review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3663/files
  - new: https://git.openjdk.java.net/jdk/pull/3663/files/ea674346..a194f5ff

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3663&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3663&range=00-01

  Stats: 17 lines in 3 files changed: 0 ins; 1 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3663/head:pull/3663

PR: https://git.openjdk.java.net/jdk/pull/3663

From zgu at openjdk.java.net  Tue Apr 27 18:42:45 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 27 Apr 2021 18:42:45 GMT
Subject: RFR: 8266083: Shenandoah: Consolidate dedup/no dedup oop closures
Message-ID: <ubBlgKxnMm5bigU1FcbEHheyQkNiibZ0et8H_lQ6n-Q=.50bb3ade-98d5-4acc-8b83-8ee6432bd337@github.com>

We can use template to consolidate dedup/no dedup oop closures.

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

Commit messages:
 - update
 - init

Changes: https://git.openjdk.java.net/jdk/pull/3724/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3724&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8266083
  Stats: 90 lines in 3 files changed: 13 ins; 53 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3724.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3724/head:pull/3724

PR: https://git.openjdk.java.net/jdk/pull/3724

From zgu at redhat.com  Wed Apr 28 18:14:33 2021
From: zgu at redhat.com (Zhengyu Gu)
Date: Wed, 28 Apr 2021 14:14:33 -0400
Subject: [sh/jdk8u] RFR 8265239: Shenandoah: Shenandoah heap region count
 could be off by 1
Message-ID: <b17ed2c3-fd90-0c93-36c9-cee4525c0fc8@redhat.com>

I would like to backport this patch to Shenandoah 8u. Shenandoah may 
under calculate the number of heap regions, that results some of 
otherwise, available regions unused.

The original bug: https://bugs.openjdk.java.net/browse/JDK-8265239
The original patch: https://github.com/openjdk/jdk/commit/ff5bb8cf

The original patch does not apply cleanly and 8u patch is somewhat 
different from the original patch.

In 8u, heap size adjustment is more than aligning up to region boundary, 
but more complicated. For example, TestAlignmentToUseLargePages.java, 
region count is actually off by 4 (36 vs. 40).

In 8u patch, I chosed to defer region count calculation until size 
adjustment is done.

Test:
   hotspot_gc_shenandoah

Thanks,

-Zhengyu



From ayang at openjdk.java.net  Thu Apr 29 09:07:18 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 29 Apr 2021 09:07:18 GMT
Subject: RFR: 8234446: Post-CMS workgroup hierarchy cleanup [v3]
In-Reply-To: <nDYB1awSv8VTQx6_xcTguPcqC0-c3LzFHE2qDPOBq48=.52d85827-7783-4415-9280-dbe3b067e88f@github.com>
References: <nDYB1awSv8VTQx6_xcTguPcqC0-c3LzFHE2qDPOBq48=.52d85827-7783-4415-9280-dbe3b067e88f@github.com>
Message-ID: <IbwV1WM6_DtCQWpGYsj52hO1ZcXAiMfLaFxgZh2A7nk=.c0aa7545-60b9-4a4c-89b2-874b930975fb@github.com>

> Collapse workgroup hierarchy and some general cleanup.
> 
> Tested; hotspot_gc

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

  undo indentation change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3663/files
  - new: https://git.openjdk.java.net/jdk/pull/3663/files/a194f5ff..c435e98d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3663&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3663&range=01-02

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3663.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3663/head:pull/3663

PR: https://git.openjdk.java.net/jdk/pull/3663

From ayang at openjdk.java.net  Thu Apr 29 09:13:53 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Thu, 29 Apr 2021 09:13:53 GMT
Subject: RFR: 8234446: Post-CMS workgroup hierarchy cleanup [v3]
In-Reply-To: <IbwV1WM6_DtCQWpGYsj52hO1ZcXAiMfLaFxgZh2A7nk=.c0aa7545-60b9-4a4c-89b2-874b930975fb@github.com>
References: <nDYB1awSv8VTQx6_xcTguPcqC0-c3LzFHE2qDPOBq48=.52d85827-7783-4415-9280-dbe3b067e88f@github.com>
 <IbwV1WM6_DtCQWpGYsj52hO1ZcXAiMfLaFxgZh2A7nk=.c0aa7545-60b9-4a4c-89b2-874b930975fb@github.com>
Message-ID: <cbzmum98eZE9UIT1xXt-ZjAd0YfRRGmDbvV6qeHCxS0=.41feda8d-2708-4395-9d8c-5c613f5d66f6@github.com>

On Thu, 29 Apr 2021 09:07:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Collapse workgroup hierarchy and some general cleanup.
>> 
>> Tested; hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo indentation change

There is some preexisting inconsistency regarding the indentation of fields initializers in constructors, e.g. `SubTasksDone` uses 2-space, while `WorkGang` uses 4-space. In order not to make the review process unnecessarily harder, I have kept the original indentation, despite the inconsistency.

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

PR: https://git.openjdk.java.net/jdk/pull/3663

From tschatzl at openjdk.java.net  Thu Apr 29 10:44:51 2021
From: tschatzl at openjdk.java.net (Thomas Schatzl)
Date: Thu, 29 Apr 2021 10:44:51 GMT
Subject: RFR: 8234446: Post-CMS workgroup hierarchy cleanup [v3]
In-Reply-To: <IbwV1WM6_DtCQWpGYsj52hO1ZcXAiMfLaFxgZh2A7nk=.c0aa7545-60b9-4a4c-89b2-874b930975fb@github.com>
References: <nDYB1awSv8VTQx6_xcTguPcqC0-c3LzFHE2qDPOBq48=.52d85827-7783-4415-9280-dbe3b067e88f@github.com>
 <IbwV1WM6_DtCQWpGYsj52hO1ZcXAiMfLaFxgZh2A7nk=.c0aa7545-60b9-4a4c-89b2-874b930975fb@github.com>
Message-ID: <1AcuG6nFsJraQVqow5JpD3HVspIwAsOrGshicEAUM4o=.49ed01ab-d2bd-4f6d-85ec-34fc9aea264e@github.com>

On Thu, 29 Apr 2021 09:07:18 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Collapse workgroup hierarchy and some general cleanup.
>> 
>> Tested; hotspot_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo indentation change

Marked as reviewed by tschatzl (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3663

From bmathiske at openjdk.java.net  Thu Apr 29 19:13:56 2021
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Thu, 29 Apr 2021 19:13:56 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v4]
In-Reply-To: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
Message-ID: <mw5dNIYTc9XilK2Npj0g5yfeWoTpeCYOcqOKgjVNGgY=.dc7da7e9-12fb-4cf8-880b-d82070eca9eb@github.com>

> Introducing a 3rd kind of LAB for generational mode: "PLAB".
> 
> Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB. 
> 
> When not in generational mode, GCLABs work as before and PLABs are never used.
> 
> The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.
> 
> Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".
> 
> In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?
> 
> Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)

Bernd Mathiske has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into plab
 - Remove redundant trash recycling in flip_to_gc().
 - Only register old filler objects when evacuation copy fails
 - Register 'filler' objects with remembered set when plabs are retired
 - Register object starts when allocating from PLAB
 - Register filler objects for unsuccessful non-LAB evacuations.
 - Track proper affiliation when allocating.
 - Update region affiliation in full GC's "regular bypass".
 - Use PLABs for object promotions to old gen and for old gen evacuations.

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

Changes: https://git.openjdk.java.net/shenandoah/pull/30/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=30&range=03
  Stats: 341 lines in 17 files changed: 246 ins; 45 del; 50 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/30.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/30/head:pull/30

PR: https://git.openjdk.java.net/shenandoah/pull/30

From sjohanss at openjdk.java.net  Thu Apr 29 20:55:29 2021
From: sjohanss at openjdk.java.net (Stefan Johansson)
Date: Thu, 29 Apr 2021 20:55:29 GMT
Subject: RFR: 8261527: Record page size used for underlying mapping in
 ReservedSpace
Message-ID: <Enix4NQ5pCJxvz_enr5SWYpgqKq_9YV91PApY0TDmrY=.34f394d4-ffe1-4b93-b3b4-500eb2c915f0@github.com>

Please review this change to use the actual page size rather than `bool large` when creating and initializing `ReservedSpace`. This allows us to then get rid of the helper `ReservedSpace::actual_reserved_page_size()` and instead use the "real" page size for logging and other use.

The PR consist of two commits, one that changes `ReservedSpace` to use and store a page size and one that removes `actual_reserved_page_size()` and instead uses `ReservedSpace::page_size()`. Hopefully this might help ease the review a bit. 

There are two changes in behavior:
* In `JfrVirtualMemorySegment::initialize()` we now always pass down `os::vm_page_size()` which means never use large pages. This differs from the old condition where large pages were enabled if transparent huge pages were enabled. This change has been discussed with the JFR team and they will later investigate how to re-enable large page use.
* In `ReservedSpace::reserve()`, if a file is used, the page size is always set to `os::vm_page_size()`. So when logging the page_size for such mapping it will not report a large page size. This was incorrectly done in the past when using `ReservedSpace::actual_reserved_page_size()` to figure out the page size. This makes the `runtime/os/TestTracePageSizes.java` test pass even if run with `-XX:AllocateHeapAt=/tmp`.

**Testing**
Mach5 tier1-4 and a lot of local testing.

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

Commit messages:
 - Use ReservedSpace.page_size() instead of actual_reserved_page_size()
 - 8261527: Record page size used for underlying mapping in ReservedSpace

Changes: https://git.openjdk.java.net/jdk/pull/3802/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3802&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261527
  Stats: 135 lines in 20 files changed: 18 ins; 26 del; 91 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3802.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3802/head:pull/3802

PR: https://git.openjdk.java.net/jdk/pull/3802

From wkemper at openjdk.java.net  Thu Apr 29 22:06:32 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 29 Apr 2021 22:06:32 GMT
Subject: RFR: Fix barrier set cast for aarch64
Message-ID: <vuXgNEMwrVBErj704QQE1JFyUWeSkSczvCe1XVdEaWo=.dc46e827-9f1e-4d0c-b860-303b242514c6@github.com>

Simple fix for aarch64 (`ShenandoahBarrierSet` no longer extends from `CardTableBarrierSet`).

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

Commit messages:
 - Fix barrier set cast for aarch64

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

PR: https://git.openjdk.java.net/shenandoah/pull/33

From zgu at openjdk.java.net  Thu Apr 29 23:38:15 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 29 Apr 2021 23:38:15 GMT
Subject: RFR: Fix barrier set cast for aarch64
In-Reply-To: <vuXgNEMwrVBErj704QQE1JFyUWeSkSczvCe1XVdEaWo=.dc46e827-9f1e-4d0c-b860-303b242514c6@github.com>
References: <vuXgNEMwrVBErj704QQE1JFyUWeSkSczvCe1XVdEaWo=.dc46e827-9f1e-4d0c-b860-303b242514c6@github.com>
Message-ID: <Mm0i3cJRArVott0FAeOY0n1wlaSuCf1zwbaSiwyHCDA=.358f4a75-75e8-45f3-93ea-8d66362c54dc@github.com>

On Thu, 29 Apr 2021 22:00:03 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Simple fix for aarch64 (`ShenandoahBarrierSet` no longer extends from `CardTableBarrierSet`).

Marked as reviewed by zgu (Reviewer).

src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 630:

> 628: 
> 629:   BarrierSet* bs = BarrierSet::barrier_set();
> 630:   ShenandoahBarrierSet* ctbs = barrier_set_cast<ShenandoahBarrierSet>(bs);

Can be simplified to ShenandoahBarrierSet::barrier_set(). Otherwise, looks good.

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

PR: https://git.openjdk.java.net/shenandoah/pull/33

From wkemper at openjdk.java.net  Fri Apr 30 00:22:13 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 30 Apr 2021 00:22:13 GMT
Subject: RFR: Fix barrier set cast for aarch64
In-Reply-To: <Mm0i3cJRArVott0FAeOY0n1wlaSuCf1zwbaSiwyHCDA=.358f4a75-75e8-45f3-93ea-8d66362c54dc@github.com>
References: <vuXgNEMwrVBErj704QQE1JFyUWeSkSczvCe1XVdEaWo=.dc46e827-9f1e-4d0c-b860-303b242514c6@github.com>
 <Mm0i3cJRArVott0FAeOY0n1wlaSuCf1zwbaSiwyHCDA=.358f4a75-75e8-45f3-93ea-8d66362c54dc@github.com>
Message-ID: <zHJqUJJJL4biQfnkPMlXGo92INULI_alFNaqjzAorao=.571ee8ba-081d-48db-b949-5086b5b45a56@github.com>

On Thu, 29 Apr 2021 23:35:26 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Simple fix for aarch64 (`ShenandoahBarrierSet` no longer extends from `CardTableBarrierSet`).
>
> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 630:
> 
>> 628: 
>> 629:   BarrierSet* bs = BarrierSet::barrier_set();
>> 630:   ShenandoahBarrierSet* ctbs = barrier_set_cast<ShenandoahBarrierSet>(bs);
> 
> Can be simplified to ShenandoahBarrierSet::barrier_set(). Otherwise, looks good.

Fixed.

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

PR: https://git.openjdk.java.net/shenandoah/pull/33

From wkemper at openjdk.java.net  Fri Apr 30 00:34:36 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 30 Apr 2021 00:34:36 GMT
Subject: RFR: Fix barrier set cast for aarch64 [v2]
In-Reply-To: <vuXgNEMwrVBErj704QQE1JFyUWeSkSczvCe1XVdEaWo=.dc46e827-9f1e-4d0c-b860-303b242514c6@github.com>
References: <vuXgNEMwrVBErj704QQE1JFyUWeSkSczvCe1XVdEaWo=.dc46e827-9f1e-4d0c-b860-303b242514c6@github.com>
Message-ID: <JydfMe8XXhq00xgZl4ncnNs-zDPmqpyA5R_0Ldax8Ss=.0fb20985-c0fe-4e4f-be47-2b04d5863f56@github.com>

> Simple fix for aarch64 (`ShenandoahBarrierSet` no longer extends from `CardTableBarrierSet`).

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

  Simplify barrier casting

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/33/files
  - new: https://git.openjdk.java.net/shenandoah/pull/33/files/062c68b1..941c3ae9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=33&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=33&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/33.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/33/head:pull/33

PR: https://git.openjdk.java.net/shenandoah/pull/33

From rkennke at openjdk.java.net  Fri Apr 30 14:05:28 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Apr 2021 14:05:28 GMT
Subject: RFR: Use PLABs for old gen allocations, including promotions. [v4]
In-Reply-To: <mw5dNIYTc9XilK2Npj0g5yfeWoTpeCYOcqOKgjVNGgY=.dc7da7e9-12fb-4cf8-880b-d82070eca9eb@github.com>
References: <cUor0-NVIgdbW3DNC-1aOMxT41ldDICg_xCx-HM9Ux8=.63b5dc2b-f01b-4c50-8fe7-96285e93b168@github.com>
 <mw5dNIYTc9XilK2Npj0g5yfeWoTpeCYOcqOKgjVNGgY=.dc7da7e9-12fb-4cf8-880b-d82070eca9eb@github.com>
Message-ID: <gCSl4f5Ob7Veyc1IKFCJchAWGWxYfBvA-Cuw8C7IYvI=.2c39e7cb-31a9-4393-b215-61155a30713a@github.com>

On Thu, 29 Apr 2021 19:13:56 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

>> Introducing a 3rd kind of LAB for generational mode: "PLAB".
>> 
>> Shenandoah already has TLABs and GCLABs. The latter pertain firmly to young gen and allocations in old gen are so far always shared allocations, without LAB. With this PR, old gen allocations go through LABs as well and we separate those from the other two kinds. In other words, each generation has its separate GC-decicated LAB. 
>> 
>> When not in generational mode, GCLABs work as before and PLABs are never used.
>> 
>> The new diagnostic flag -XX:-ShenandoahUsePLAB can be used to turn off PLAB use, so that all old gen allocations are shared as before this PR. By default PLABs will be used.
>> 
>> Note that In source code, the type of both GCLABs and PLABs is "PLAB*", sonce GCLABs already had that type, but variable references and other value-level identifiers are consistently named "gclab" and "plab".
>> 
>> In ShenandoahFreeSet::allocate_single() there is a notable additional change that can easily be reverted if needed. Instead of fitting the intended allocation into any free or occupied region that can hold it, we now search for an occupied region in the same generation first, before considering free regions. The idea is to pack regions more densely as long as they have space left. This provides more opportunity for region borrowing between generations, should the need arise. For single-generational Shenandoah, it should not make a huge difference, right? Or is it crucial to find any free slot hit in that search loop ASAP?
>> 
>> Full collections need to set empty/trash regions that they compact into to non-FREE. For now, they will be made "YOUNG". (See the second commit.)
>
> Bernd Mathiske has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into plab
>  - Remove redundant trash recycling in flip_to_gc().
>  - Only register old filler objects when evacuation copy fails
>  - Register 'filler' objects with remembered set when plabs are retired
>  - Register object starts when allocating from PLAB
>  - Register filler objects for unsuccessful non-LAB evacuations.
>  - Track proper affiliation when allocating.
>  - Update region affiliation in full GC's "regular bypass".
>  - Use PLABs for object promotions to old gen and for old gen evacuations.

Looks good to me. Thank you!

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

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/shenandoah/pull/30

From rkennke at openjdk.java.net  Fri Apr 30 14:51:19 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Apr 2021 14:51:19 GMT
Subject: RFR: Fix barrier set cast for aarch64 [v2]
In-Reply-To: <JydfMe8XXhq00xgZl4ncnNs-zDPmqpyA5R_0Ldax8Ss=.0fb20985-c0fe-4e4f-be47-2b04d5863f56@github.com>
References: <vuXgNEMwrVBErj704QQE1JFyUWeSkSczvCe1XVdEaWo=.dc46e827-9f1e-4d0c-b860-303b242514c6@github.com>
 <JydfMe8XXhq00xgZl4ncnNs-zDPmqpyA5R_0Ldax8Ss=.0fb20985-c0fe-4e4f-be47-2b04d5863f56@github.com>
Message-ID: <XpTLBAhxfOZZRaoPrCNWvnMmR_ZU5u1WalwYsXw-q8g=.97fa9cb9-08bc-4ffe-ba31-bc1f578b27a1@github.com>

On Fri, 30 Apr 2021 00:34:36 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Simple fix for aarch64 (`ShenandoahBarrierSet` no longer extends from `CardTableBarrierSet`).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify barrier casting

Marked as reviewed by rkennke (Reviewer).

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

PR: https://git.openjdk.java.net/shenandoah/pull/33

From rkennke at openjdk.java.net  Fri Apr 30 16:13:18 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Apr 2021 16:13:18 GMT
Subject: RFR: Fix barrier set cast for aarch64 [v2]
In-Reply-To: <JydfMe8XXhq00xgZl4ncnNs-zDPmqpyA5R_0Ldax8Ss=.0fb20985-c0fe-4e4f-be47-2b04d5863f56@github.com>
References: <vuXgNEMwrVBErj704QQE1JFyUWeSkSczvCe1XVdEaWo=.dc46e827-9f1e-4d0c-b860-303b242514c6@github.com>
 <JydfMe8XXhq00xgZl4ncnNs-zDPmqpyA5R_0Ldax8Ss=.0fb20985-c0fe-4e4f-be47-2b04d5863f56@github.com>
Message-ID: <RRmRHiBdHX1981-mxkqyZmFyfD7Bh1sRVyk5LwWhb3w=.022ac3ad-3178-4ee2-9992-b15426aaff41@github.com>

On Fri, 30 Apr 2021 00:34:36 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Simple fix for aarch64 (`ShenandoahBarrierSet` no longer extends from `CardTableBarrierSet`).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify barrier casting

Please try /integrate :-)

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

PR: https://git.openjdk.java.net/shenandoah/pull/33

From wkemper at openjdk.java.net  Fri Apr 30 16:17:17 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 30 Apr 2021 16:17:17 GMT
Subject: RFR: Fix barrier set cast for aarch64 [v2]
In-Reply-To: <JydfMe8XXhq00xgZl4ncnNs-zDPmqpyA5R_0Ldax8Ss=.0fb20985-c0fe-4e4f-be47-2b04d5863f56@github.com>
References: <vuXgNEMwrVBErj704QQE1JFyUWeSkSczvCe1XVdEaWo=.dc46e827-9f1e-4d0c-b860-303b242514c6@github.com>
 <JydfMe8XXhq00xgZl4ncnNs-zDPmqpyA5R_0Ldax8Ss=.0fb20985-c0fe-4e4f-be47-2b04d5863f56@github.com>
Message-ID: <kWqSRcRk57pRlVakYwCzcGEiG0PrXk0ggzRe48pLhQg=.af466bde-954e-4630-97ac-e0c57ffe5a27@github.com>

On Fri, 30 Apr 2021 00:34:36 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Simple fix for aarch64 (`ShenandoahBarrierSet` no longer extends from `CardTableBarrierSet`).
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify barrier casting

I reopened my committer access ticket: https://bugs.openjdk.java.net/browse/SKARA-990?filter=-2 . I think I was meant to receive and accept an invitation to join the JDK organization, but I don't recall receiving it (and I can't find it in my inbox).

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

PR: https://git.openjdk.java.net/shenandoah/pull/33