From stefank at openjdk.java.net  Thu Oct  1 07:09:39 2020
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 1 Oct 2020 07:09:39 GMT
Subject: RFR: 8247912: Make narrowOop a scoped enum [v5]
In-Reply-To: <gt_FQyVtfiAf6vC0hiVfPpzCqbNK-7a4tgzGhthD1pM=.7a858b7b-eff3-49ad-a1b2-c38b9d0ff380@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
 <gt_FQyVtfiAf6vC0hiVfPpzCqbNK-7a4tgzGhthD1pM=.7a858b7b-eff3-49ad-a1b2-c38b9d0ff380@github.com>
Message-ID: <SGyWcAj26edTveyFjYo879SsuMDwHHNKf3BkMaQMWy4=.b2c94810-c65f-42ad-8496-663184ec56f5@github.com>

On Wed, 30 Sep 2020 18:50:46 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to the type narrowOop from a typedef for juint to a
>> scoped enum with uint32_t as the representation type.  This provides stronger
>> type checking when using this type.
>> 
>> For the most part this was fairly straightforward, and the patch size is
>> relatively small.  The implementation of some existing CompressedOops
>> "primitives" required adjustment. An explicit conversion to narrowOop was
>> added, with casts change to use it.  There were a few places that were type
>> punning and needed explicit conversions,, mostly in platform-specific assembly
>> support.
>> 
>> There are a couple of lingering problems.
>> 
>> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
>> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
>> this probably ought to be done differently.
>> 
>> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
>> whether these can be safely converted to CompressedOops::narrow_oop_cast.
>> 
>> There might still be some casts from narrowOop to an integral type.  Those are
>> hard to find in our cast-happy code base.
>> 
>> Testing:
>> tier1-6 for Oracle supported platforms.
>> Build fastdebug linux-ppc64le and linux-s390x.
>
> Kim Barrett has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since
> the last revision:
>  - Merge branch 'master' into strong_narrowoop
>  - add missing inlines for consistency
>  - stefank review
>  - improve assertion
>  - remove NarrowType
>  - 8247912: Make narrowOop a scoped enum

Marked as reviewed by stefank (Reviewer).

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

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

From sgehwolf at redhat.com  Thu Oct  1 09:47:44 2020
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Thu, 01 Oct 2020 11:47:44 +0200
Subject: [aarch64-port-dev ] [RFR] [8u] 8u272-b09 Upstream Sync
In-Reply-To: <20200929002603.GD198906@stopbrexit>
References: <20200929002603.GD198906@stopbrexit>
Message-ID: <42c47b5247ca85f16a3bdfd1528cd76fd8f691c2.camel@redhat.com>

On Tue, 2020-09-29 at 01:26 +0100, Andrew Hughes wrote:
> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/
> 
> Merge changesets:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/jaxws/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/jdk/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/hotspot/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/langtools/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/nashorn/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b09/root/merge.changeset
> 
> Changes in aarch64-shenandoah-jdk8u272-b09:
>   - JDK-8252886: [TESTBUG] sun/security/ec/TestEC.java : Compilation failed
> 
> Main issues of note:
> None, clean merge (no HotSpot changes).

This looks fine to me.

Thanks,
Severin

> 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/test/sun/security/ec/TestEC.java |    1 +
>  2 files changed, 2 insertions(+)
> 
> diffstat for hotspot
>  b/.hgtags |    1 +
>  1 file changed, 1 insertion(+)
> 
> Successfully built on x86, x86_64, s390x (Zero), ppc64le, aarch32
> (Zero) & aarch64 [0].
> 
> Ok to push?
> 
> [0] https://koji.fedoraproject.org/koji/buildinfo?buildID=1616531
> 
> Thanks,


From kbarrett at openjdk.java.net  Thu Oct  1 10:48:23 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Thu, 1 Oct 2020 10:48:23 GMT
Subject: Integrated: 8247912: Make narrowOop a scoped enum
In-Reply-To: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
References: <tZAr_bhzM3wf-4lyaGyyovPUh5aOqHNOWKmmUxWxahY=.890a249b-138a-4c18-aaa5-28d34460d5aa@github.com>
Message-ID: <Kg5FagKaMR0HuZpPGZCDigYpHepseK0Qx1ku5GTHwDw=.9ff5035a-a790-4f95-ad36-63c715e52d78@github.com>

On Mon, 21 Sep 2020 04:01:34 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to the type narrowOop from a typedef for juint to a
> scoped enum with uint32_t as the representation type.  This provides stronger
> type checking when using this type.
> 
> For the most part this was fairly straightforward, and the patch size is
> relatively small.  The implementation of some existing CompressedOops
> "primitives" required adjustment. An explicit conversion to narrowOop was
> added, with casts change to use it.  There were a few places that were type
> punning and needed explicit conversions,, mostly in platform-specific assembly
> support.
> 
> There are a couple of lingering problems.
> 
> Relocation::pd_set_data_value in relocInfo_ppc.cpp is treating a narrowKlass
> as a narrowOop.  I adjusted the code to accommodate the narrowOop change, but
> this probably ought to be done differently.
> 
> There are a couple of `(narrowOop)` casts remaining in s390.ad.  I'm not sure
> whether these can be safely converted to CompressedOops::narrow_oop_cast.
> 
> There might still be some casts from narrowOop to an integral type.  Those are
> hard to find in our cast-happy code base.
> 
> Testing:
> tier1-6 for Oracle supported platforms.
> Build fastdebug linux-ppc64le and linux-s390x.

This pull request has now been integrated.

Changeset: 2d9fa9da
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2d9fa9da
Stats:     97 lines in 22 files changed: 42 ins; 9 del; 46 mod

8247912: Make narrowOop a scoped enum

Reviewed-by: iklam, stefank

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

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

From luhenry at microsoft.com  Thu Oct  1 15:48:12 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Thu, 1 Oct 2020 15:48:12 +0000
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
Message-ID: <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>

Hi,

As we now have a whole bunch of reviews (thank you all!), we would need a sponsor to get it merged.

Thank you :) 

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

PR: https://github.com/openjdk/jdk/pull/212

From david.holmes at oracle.com  Thu Oct  1 21:50:28 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 2 Oct 2020 07:50:28 +1000
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
Message-ID: <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>

Hi,

On 2/10/2020 1:48 am, Ludovic Henry wrote:
> Hi,
> 
> As we now have a whole bunch of reviews (thank you all!), we would need a sponsor to get it merged.

The JEP is not yet targeted so we have to wait for that formality. But 
once that happens I can sponsor for you.

Also note that the PR references the wrong JEP so can you please edit 
the description to fix that.

Meanwhile I'll see if I can take this for a spin through our internal 
testing.

Cheers,
David
-----

> Thank you :)
> 
> -------------
> 
> PR: https://github.com/openjdk/jdk/pull/212
> 

From luhenry at microsoft.com  Thu Oct  1 21:56:53 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Thu, 1 Oct 2020 21:56:53 +0000
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
 <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>
Message-ID: <MWHPR21MB05112D9AB69CF5FC740B609AB0300@MWHPR21MB0511.namprd21.prod.outlook.com>

Hi David,

> The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you.

Perfect, I didn't know about the need for the JEP to be targeted before the merge.

> Also note that the PR references the wrong JEP so can you please edit the description to fix that.

I'll work with @Monica to update the PR's description to point to https://openjdk.java.net/jeps/391 instead.

Thank you!
Ludovic
 

From daniel.daugherty at oracle.com  Thu Oct  1 22:05:03 2020
From: daniel.daugherty at oracle.com (Daniel D. Daugherty)
Date: Thu, 1 Oct 2020 18:05:03 -0400
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <MWHPR21MB05112D9AB69CF5FC740B609AB0300@MWHPR21MB0511.namprd21.prod.outlook.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
 <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>
 <MWHPR21MB05112D9AB69CF5FC740B609AB0300@MWHPR21MB0511.namprd21.prod.outlook.com>
Message-ID: <b61ef9c2-8599-8432-25cf-75ce3ef24fd0@oracle.com>

So I'm confused... this PR is associated with this bug ID:

>
>       Issue
>
>   * JDK-8248238 <https://bugs.openjdk.java.net/browse/JDK-8248238>:
>     Implementation of JEP: Windows AArch64 Support
>


and JDK-8248238 is associated with this JEP:

> JDK-8248496 <https://bugs.openjdk.java.net/browse/JDK-8248496> JEP 
> 388: Windows/AArch64 Port 

Am I missing something here?

Dan


On 10/1/20 5:56 PM, Ludovic Henry wrote:
> Hi David,
>
>> The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you.
> Perfect, I didn't know about the need for the JEP to be targeted before the merge.
>
>> Also note that the PR references the wrong JEP so can you please edit the description to fix that.
> I'll work with @Monica to update the PR's description to point to https://openjdk.java.net/jeps/391 instead.
>
> Thank you!
> Ludovic
>   


From luhenry at microsoft.com  Thu Oct  1 22:14:16 2020
From: luhenry at microsoft.com (Ludovic Henry)
Date: Thu, 1 Oct 2020 22:14:16 +0000
Subject: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]
In-Reply-To: <b61ef9c2-8599-8432-25cf-75ce3ef24fd0@oracle.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <MWHPR21MB05117D496C7A5BBA833297F7B0300@MWHPR21MB0511.namprd21.prod.outlook.com>
 <1b89dc62-87fe-baa0-24c7-1f07bbdd5e48@oracle.com>
 <MWHPR21MB05112D9AB69CF5FC740B609AB0300@MWHPR21MB0511.namprd21.prod.outlook.com>
 <b61ef9c2-8599-8432-25cf-75ce3ef24fd0@oracle.com>
Message-ID: <MWHPR21MB0511FBB19387F6D9F172AF59B0300@MWHPR21MB0511.namprd21.prod.outlook.com>

It?s me who made a mistake. This PR should be associated with JEP 388 as you are rightly pointing out.

From: Daniel D. Daugherty <daniel.daugherty at oracle.com>
Sent: Thursday, October 1, 2020 3:05 PM
To: Ludovic Henry <luhenry at microsoft.com>; David Holmes <david.holmes at oracle.com>; David Holmes <dholmes at openjdk.java.net>; Andrew Haley <aph at openjdk.java.net>; Chris Plummer <cjplummer at openjdk.java.net>; Magnus Ihse Bursie <ihse at openjdk.java.net>; build-dev at openjdk.java.net; core-libs-dev at openjdk.java.net; hotspot-dev at openjdk.java.net; serviceability-dev at openjdk.java.net; shenandoah-dev at openjdk.java.net; Monica Beckwith <Monica.Beckwith at microsoft.com>
Subject: Re: RFR: 8248238: Implementation of JEP: Windows AArch64 Support [v12]

So I'm confused... this PR is associated with this bug ID:


Issue

  *   JDK-8248238<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248238&data=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436454353&sdata=FV0tr%2FktSPQDxHkI1JMr7UCgW4ygPi8d4yKsGuPVUg8%3D&reserved=0>: Implementation of JEP: Windows AArch64 Support


and JDK-8248238 is associated with this JEP:


JDK-8248496<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.openjdk.java.net%2Fbrowse%2FJDK-8248496&data=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436454353&sdata=HAjFLX%2BtIaKz%2FFULuav%2BUXn6qTZb%2BkjiS4ijsWw7RQE%3D&reserved=0> JEP 388: Windows/AArch64 Port

Am I missing something here?

Dan

On 10/1/20 5:56 PM, Ludovic Henry wrote:

Hi David,



The JEP is not yet targeted so we have to wait for that formality. But once that happens I can sponsor for you.



Perfect, I didn't know about the need for the JEP to be targeted before the merge.



Also note that the PR references the wrong JEP so can you please edit the description to fix that.



I'll work with @Monica to update the PR's description to point to https://openjdk.java.net/jeps/391<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenjdk.java.net%2Fjeps%2F391&data=02%7C01%7Cluhenry%40microsoft.com%7Ce428223ea04a45c2d40308d866562328%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637371867436464348&sdata=Pj%2FNQvzEa8mrhvY75OFVBG7k623Mgnr56Xo3On%2BoQGo%3D&reserved=0> instead.



Thank you!

Ludovic




From mbeckwit at openjdk.java.net  Fri Oct  2 17:20:45 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Fri, 2 Oct 2020 17:20:45 GMT
Subject: RFR: 8248238: Implementation: JEP 388: Windows AArch64 Support
 [v12]
In-Reply-To: <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
Message-ID: <CiPvM88WFx_o1P3zYlEFsdSrLK2sxrNQfWQVgPfOHi4=.fcf0ed66-c945-4760-b217-110b123fdc2f@github.com>

On Wed, 30 Sep 2020 00:40:29 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Monica Beckwith has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change string representation for r18 to "r18_tls" on every platform
>
> Marked as reviewed by dholmes (Reviewer).

> The JEP is not yet targeted so we have to wait for that formality. But
> once that happens I can sponsor for you.

Thanks.
>
> Also note that the PR references the wrong JEP so can you please edit
> the description to fix that.

Added JEP # (388) here and updated the JBS entry.
After looking at JEPs 386, 377, and 379, I also did the following:
- listed JDK-8248238 as a sub-task for JDK-8248496
- added this PR link in a comment for the JEP.

As soon as the JEP is targetted, I will update the "Fix version" for the 'Implementation' (JDK-8248238) and ping you
@dholmes-ora .
> 
> Meanwhile I'll see if I can take this for a spin through our internal
> testing.
Thanks so much.

Regards,
Monica

> 
> Cheers,
> David

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

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

From dholmes at openjdk.java.net  Mon Oct  5 03:24:44 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 5 Oct 2020 03:24:44 GMT
Subject: RFR: 8248238: Implementation: JEP 388: Windows AArch64 Support
 [v12]
In-Reply-To: <CiPvM88WFx_o1P3zYlEFsdSrLK2sxrNQfWQVgPfOHi4=.fcf0ed66-c945-4760-b217-110b123fdc2f@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <CiPvM88WFx_o1P3zYlEFsdSrLK2sxrNQfWQVgPfOHi4=.fcf0ed66-c945-4760-b217-110b123fdc2f@github.com>
Message-ID: <LK0WRkI3CZFruGt7SiyE8d2wdSdbU8rOnYxLacqVDK4=.6ab0c4ad-bc33-41e1-82a9-d8506eb3fb57@github.com>

On Fri, 2 Oct 2020 17:16:50 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

>> Marked as reviewed by dholmes (Reviewer).
>
>> The JEP is not yet targeted so we have to wait for that formality. But
>> once that happens I can sponsor for you.
> 
> Thanks.
>>
>> Also note that the PR references the wrong JEP so can you please edit
>> the description to fix that.
> 
> Added JEP # (388) here and updated the JBS entry.
> After looking at JEPs 386, 377, and 379, I also did the following:
> - listed JDK-8248238 as a sub-task for JDK-8248496
> - added this PR link in a comment for the JEP.
> 
> As soon as the JEP is targetted, I will update the "Fix version" for the 'Implementation' (JDK-8248238) and ping you
> @dholmes-ora .
>> 
>> Meanwhile I'll see if I can take this for a spin through our internal
>> testing.
> Thanks so much.
> 
> Regards,
> Monica
> 
>> 
>> Cheers,
>> David

@mo-beck The initial comment still has this incorrect link:

[2] https://openjdk.java.net/jeps/8251280

Please edit the comment and fix the link.

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

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

From mbeckwit at openjdk.java.net  Mon Oct  5 03:24:45 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 5 Oct 2020 03:24:45 GMT
Subject: Integrated: 8248238: Implementation: JEP 388: Windows AArch64 Support
In-Reply-To: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
Message-ID: <FqlQiJC3-0QDxFjIzvzg8a3sWpaItdwvKPMtlW5Qzk4=.cd813073-a978-4e3f-b3a7-e1909b523fd3@github.com>

On Wed, 16 Sep 2020 20:26:10 GMT, Monica Beckwith <mbeckwit at openjdk.org> wrote:

> This is a continuation of https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009566.html
>  
> Changes since then:
> * We've improved the write barrier as suggested by Andrew [1]
> * The define-guards around R18 have been changed to `R18_RESERVED`. This will be enabled for Windows only for now but
>   will be required for the upcoming macOS+Aarch64 [2] port as well.
> * We've incorporated https://github.com/openjdk/jdk/pull/154 by @AntonKozlov in our PR for now and built the
>   Windows-specific CPU feature detection on top of it.
> 
> [1] https://mail.openjdk.java.net/pipermail/aarch64-port-dev/2020-August/009597.html
> [2] https://openjdk.java.net/jeps/8251280

This pull request has now been integrated.

Changeset: 9604ee82
Author:    Monica Beckwith <mbeckwit at openjdk.org>
Committer: David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9604ee82
Stats:     2566 lines in 62 files changed: 2208 ins; 126 del; 232 mod

8248238: Implementation: JEP 388: Windows AArch64 Support

Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
Reviewed-by: dholmes, cjplummer, aph, ihse

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

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

From mbeckwit at openjdk.java.net  Mon Oct  5 04:11:47 2020
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Mon, 5 Oct 2020 04:11:47 GMT
Subject: RFR: 8248238: Implementation: JEP 388: Windows AArch64 Support
 [v12]
In-Reply-To: <LK0WRkI3CZFruGt7SiyE8d2wdSdbU8rOnYxLacqVDK4=.6ab0c4ad-bc33-41e1-82a9-d8506eb3fb57@github.com>
References: <rKAoubbLMIMVqS6En_xKWMT8jpEwBU5TF83A-AhWg2E=.908578cd-0877-431e-9447-d5a04e0dc970@github.com>
 <qv-WAepDb6KDawneV5Mw_HXjDB-xBnJkdeIAlquh6bU=.3af0c77f-fe7b-4bee-913b-6e6de513f0bd@github.com>
 <t08mgMBggFEJuzguHzW9OPI3AgtasklRfHSO95q3YA4=.98e321ac-8db2-462f-b311-7de33dcb9091@github.com>
 <CiPvM88WFx_o1P3zYlEFsdSrLK2sxrNQfWQVgPfOHi4=.fcf0ed66-c945-4760-b217-110b123fdc2f@github.com>
 <LK0WRkI3CZFruGt7SiyE8d2wdSdbU8rOnYxLacqVDK4=.6ab0c4ad-bc33-41e1-82a9-d8506eb3fb57@github.com>
Message-ID: <BsWqHVHVTtimGeQhZ2F_4qGKOn_21g1Vsoo9L1nkQLk=.867b108d-8101-48b7-b4dd-0f2f92cb8e1d@github.com>

On Mon, 5 Oct 2020 03:20:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

> @mo-beck The initial comment still has this incorrect link:
> 
> [2] https://openjdk.java.net/jeps/8251280
> 
> Please edit the comment and fix the link.

That was a link to the macOS + Arm64 port. But I have removed it as it wasn't needed in the description of this
implementation.

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

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

From mdoerr at openjdk.java.net  Mon Oct  5 15:55:40 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Mon, 5 Oct 2020 15:55:40 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
In-Reply-To: <he1sdFygQNDTv03lTN6u5wQXvtUjim_2NLcG3nnnBz4=.c9869632-e2eb-4851-8b24-47cf60cbc464@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
 <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
 <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>
 <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com>
 <he1sdFygQNDTv03lTN6u5wQXvtUjim_2NLcG3nnnBz4=.c9869632-e2eb-4851-8b24-47cf60cbc464@github.com>
Message-ID: <7fS4cztWp4ebESEXcO7lrRepZZSye1KBoQGOyYvUwfM=.df0e2d21-7867-431c-89b9-dcf0ab001640@github.com>

On Wed, 30 Sep 2020 19:16:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>>> Did you try on x86? AOT is not supported on PPC64.
>> 
>> I didn't.  No wonder.  Thank you!
>
>> Did you try on x86? AOT is not supported on PPC64.
> 
> After looking at this a bit, I find that there seems to be an assumption in the code that if there is an intrinsic
> symbol defined in aotCodeHeap.cpp using the SET_AOT_GLOBAL_SYMBOL_VALUE macro, it is required that the intrinsic is
> implemented for every arch that implements AOT.  In this case, there isn't an implementation for x86_64 (yet), so
> that's why the failure is occurring.  I was tempted to put in an arch-specific #if for ppc arch only, but I don't see
> any arch-specific code in this area, and it doesn't make sense either because AOT isn't supported on ppc at all.
> Another alternative is to remove the SET_AOT_GLOBAL_SYMBOL_VALUE for decodeBlock, since the implementation is not
> defined (yet) for any arch which supports AOT.  A third alternative would be to leave the macro call in, but comment it
> out, saying to uncomment it when it's supported on all AOT-capable arches.  Any thoughts?

Nobody replied, so I suggest to leave aotCodeHeap.cpp as it was. AOT folks can add it when they need it.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct  5 16:11:41 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 5 Oct 2020 16:11:41 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
In-Reply-To: <7fS4cztWp4ebESEXcO7lrRepZZSye1KBoQGOyYvUwfM=.df0e2d21-7867-431c-89b9-dcf0ab001640@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
 <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
 <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>
 <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com>
 <he1sdFygQNDTv03lTN6u5wQXvtUjim_2NLcG3nnnBz4=.c9869632-e2eb-4851-8b24-47cf60cbc464@github.com>
 <7fS4cztWp4ebESEXcO7lrRepZZSye1KBoQGOyYvUwfM=.df0e2d21-7867-431c-89b9-dcf0ab001640@github.com>
Message-ID: <y5IrWAdwvO19UfV70N8ntGwn4o5UYzL5bASq9xxEJgA=.06b323eb-4b72-43f3-9bc4-60c5b065a8a9@github.com>

On Mon, 5 Oct 2020 15:53:26 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Nobody replied, so I suggest to leave aotCodeHeap.cpp as it was. AOT folks can add it when they need it.

Ok, I will drop that change from that PR.  Thank you.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct  5 18:29:58 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 5 Oct 2020 18:29:58 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

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

 - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
   
   Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
   arches that implement AOT, implement the decodeBlock intrinsic.
 - Base64.java decodeBlock: Changes from PR review
   
    * Make comparison safer and consistent with the while loop
    * Update comment about the decodeBlock intrinsic so that it matches the new structure
    * Add comment about the lack of a length check on the destination buffer
    * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
 - stubGenerator_ppc.cpp: Changes from PR review
   
    * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
    * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
    * align unrolled loop on a 32-byte boundary
    * replace instruction used for checking isURL from a double word to single
      word instruction since the register is effectively 32 bits wide
    * cosmetic change to realign register comments.
 - TestBase64.java: Changes from PR review
   
    * Use Utils.toByteArrays() method instead of a locally-defined method
    * Generate the two non-Base64 tables dynamically rather than use static initialization
    * Added comments describing the two above-mentioned arrays
 - Expand the Base64 intrinsic regression test to cover decodeBlock
   
   This patch makes four significant changes:
   
   1) The Power implementation of the decodeBlock intrinsic, at least,
   requires a decode length of at least 128 bytes, but the existing test cases
   are much shorter, maxing out at 111 bytes.  So the patch adds a new input
   data file which has longer test cases in it.
   
   2) The original test cases only covers the encoding of just the printable
   subset of the 7-bit ASCII characters.  However, Base64 encoding requires
   being able to encode arbitrary binary data, i.e. it must handle all 256
   8-bit byte encodings.  To remedy this, but keep the original line-oriented
   style of the input data, I added another input file type that uses a simple
   ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
   test0 is called, a new parameter is passed that specifies the type of the
   input file, which is either the original ASCII type or the hexadecimal
   format.  So to test both longer input data and arbitrary 8-bit data, the
   newly added input test file has test cases which are both longer and
   encoded in ASCII hex so as to give full 8-bit capability.  When reading
   this type of file, test0 calls a newly-added function to translate the
   ASCII hex to binary data.  Except for the first line of input data, which
   contains all possible 8-bit values sequentially, the input data was
   generated using a random length (between 111 and 520 bytes) buffer filled
   with random 8-bit data, which should give adequate coverage.
   
   3) The original test did not test that the decoder detects illegal Base64
   bytes.  This change chooses a random location in the encoded data to
   corrupt with a randomly-chosen byte which is illegal for the specific
   Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
   the decode function to verify that the illegal byte is detected and the
   proper exception is thrown.
   
   4) The test iteration count was originally 100K, but that is far more than
   enough iterations to test the intrinsic.  It takes 20K iterations on each
   instrinsic for HotSpot C2 to begin calling it.  The test originally had
   three types of encodings to test and called the encode intrinsic four times
   for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
   encode.  Decode was called four times as well (now five because of the
   illegal byte test).  I believe this is excessive and with the extra test
   data I have added, the test was timing out after ten minutes of execution.
   It appears that it is timing out, not because the intrinsics take a long
   time to run, but because test0 generates an enormous number of discarded
   data buffers for the GC system to recover (the test runs at about 39GB of
   virtual memory on my test machine).  To remedy the timeout problem, I have
   changed the code so that a warmup function of 20K repetitions is performed
   on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
   reduced the number of iterations to 5K on each test0 call.  This should
   give adequate coverage.
 - Add JMH benchmark for Base64 variable length buffer decoding
 - Add Power9+ intrinsic implementation for Base64 decoding
 - Add HotSpot code to implement Base64 decodeBlock API
 - Add HotSpotIntrinsicCandidate and API for Base64 decoding

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

Changes: https://git.openjdk.java.net/jdk/pull/293/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=01
  Stats: 1873 lines in 23 files changed: 1846 ins; 4 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

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

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct  5 18:29:59 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 5 Oct 2020 18:29:59 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <y5IrWAdwvO19UfV70N8ntGwn4o5UYzL5bASq9xxEJgA=.06b323eb-4b72-43f3-9bc4-60c5b065a8a9@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <FXyd9RkZbpfeKA5u6TbKbVpdBb104NV3Rv82Cc6uS8Q=.24926cff-3b94-47ab-a6c9-e82afc132a0c@github.com>
 <l2ppFeoFNQ7kC32YLjHoJCFMM2-uHaLn1A6GOM2Tk_c=.a957060e-d63b-4189-b722-206fcf755950@github.com>
 <fApRZ6p-C8wjyeYrq9ppoVyVsbA8ucNtS_vMnBBCNYo=.65d29ece-36c0-4fac-a48f-f4e08feb3ba3@github.com>
 <zibkjfdlG7QrBw18sEO6h3oEjvccEYHF1TtrKjk0J0Y=.e7f40f86-b8b4-4c23-a168-50214bebb96c@github.com>
 <3zdj-jaGgS6_W7mNPSnlZr6JECPKSybWxR1-yy5bZ8Q=.90bff33b-0da1-49cf-9833-ee08caf55c6f@github.com>
 <he1sdFygQNDTv03lTN6u5wQXvtUjim_2NLcG3nnnBz4=.c9869632-e2eb-4851-8b24-47cf60cbc464@github.com>
 <7fS4cztWp4ebESEXcO7lrRepZZSye1KBoQGOyYvUwfM=.df0e2d21-7867-431c-89b9-dcf0ab001640@github.com>
 <y5IrWAdwvO19UfV70N8ntGwn4o5UYzL5bASq9xxEJgA=.06b323eb-4b72-43f3-9bc4-60c5b065a8a9@github.com>
Message-ID: <CG5i7Se1JWV9BoYKSev-u5-nl0aorK6d55_TiOmPFbo=.de790efa-3c1e-4fa8-96e4-6da70fe37d58@github.com>

On Mon, 5 Oct 2020 16:08:55 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Nobody replied, so I suggest to leave aotCodeHeap.cpp as it was. AOT folks can add it when they need it.
>
>> Nobody replied, so I suggest to leave aotCodeHeap.cpp as it was. AOT folks can add it when they need it.
> 
> Ok, I will drop that change from that PR.  Thank you.

I have rebased this PR and made the requested changes.   The force push is only because of the rebase; I have preserved
the commit history.

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

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

From rriggs at openjdk.java.net  Mon Oct  5 20:59:44 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 5 Oct 2020 20:59:44 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

Core Libs changes and the test look fine.

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

Marked as reviewed by rriggs (Reviewer).

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

From github.com+51754783+coreyashford at openjdk.java.net  Mon Oct  5 21:47:42 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Mon, 5 Oct 2020 21:47:42 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
Message-ID: <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>

On Mon, 5 Oct 2020 20:57:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> Core Libs changes and the test look fine.

8248188: Add IntrinsicCandidate and API for Base64 decoding, add Power64LE intrinsic implementation.

This patch set encompasses the following commits:

Adds a new intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the
intrinsic. The API is similar to the existing encodeBlock intrinsic.

Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
implementation.

Adds a Power64LE-specific implementation of the decodeBlock intrinsic.

Adds a JMH microbenchmark for both Base64 encoding and encoding.

Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

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

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

From rkennke at openjdk.java.net  Tue Oct  6 12:58:41 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 6 Oct 2020 12:58:41 GMT
Subject: RFR: 8253857: Shenandoah: Bugs in ShenandoahEvacOOMHandler
 related code
In-Reply-To: <6CF0xb8QBnk6It66Ov9BnSqv29SkjCWVwyFuUW8lEqQ=.77388807-557b-4bf2-b952-1675d473ddea@github.com>
References: <6CF0xb8QBnk6It66Ov9BnSqv29SkjCWVwyFuUW8lEqQ=.77388807-557b-4bf2-b952-1675d473ddea@github.com>
Message-ID: <ZjIt8O9JJ5ByUcd12BmOrSa3XlJfrCzlIHD23cNnXeM=.77bc2fd8-659f-4884-9488-0d1064c9c7bd@github.com>

On Wed, 30 Sep 2020 18:57:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There are a couple of bugs in ShenandoahEvacOOMHandler related code.
> 
> 1) ShenandoahEvacOOMHandler::register_thread()
> It does not do OOM check before blindly cmpxchg in threads_in_evac. The cmpxchg can success even OOM is in progress,
> that results the thread to continue evacuate objects.
> 2) When a nested OOM scope encounters OOM, it does not decrease threads_in_evac count before entering
> wait_for_no_evac_threads() loop, it deadlocks itself.
> Test:
> - [x] hotspot_gc_shenandoah on Linux x86_64

src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.cpp line 58:

> 56:       return;
> 57:     } else {
> 58:       // Failure:

Don't we still need this block?

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

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

From akozlov at openjdk.java.net  Tue Oct  6 13:40:22 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 6 Oct 2020 13:40:22 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS [v2]
In-Reply-To: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
Message-ID: <6CNTkYXWf4_yX13e6G4fusS8fijamDb13jtPDdHNY6g=.0459ff64-960a-4dd5-9715-07ed0ba88012@github.com>

> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html
> 
> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL,
> PROT_NONE), the function was made aware of exec permissions.
> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference
> compared with old code.
> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and
> immediately reflects this in diagnostic tools like ps.  For executable regions it would require MAP_FIXED|MAP_JIT, so
> instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently
> this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not
> shrink (if I haven't missed anything, by the implementation and in principle).  Tested:
> * local tier1
> * jdk-submit
> * codesign[2] with hardened runtime and allow-jit but without
> allow-unsigned-executable-memory entitlements[3] produce a working bundle.
> 
> (adding GC group as suggested by @dholmes-ora)
> 
> 
> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227
> [2]
>  
>   codesign \
>     --sign - \
>     --options runtime \
>     --entitlements ents.plist \
>     --timestamp \
>     $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib
> [3]
>   <?xml version="1.0" encoding="UTF-8"?>
>   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
>   <plist version="1.0">
>     <dict>
>       <key>com.apple.security.cs.allow-jit</key>
>       <true/>
>       <key>com.apple.security.cs.disable-library-validation</key>
>       <true/>
>       <key>com.apple.security.cs.allow-dyld-environment-variables</key>
>       <true/>
>     </dict>
>   </plist>

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

 - Minimal working example, no uncommit
 - Merge remote-tracking branch 'upstream/master' into 8234930
 - Revert "Use MAP_JIT for CodeCache pages"
   
   This reverts commit 114d9cffd62cab42790b65091648fe75345c4533.
 - Use MAP_JIT for CodeCache pages

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

Changes: https://git.openjdk.java.net/jdk/pull/294/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=294&range=01
  Stats: 48 lines in 6 files changed: 31 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294

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

From zgu at openjdk.java.net  Tue Oct  6 13:46:13 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 6 Oct 2020 13:46:13 GMT
Subject: RFR: 8254075: Shenandoah: Remove ShenandoahCodeRootsStyle diagnostic
 flag and related test
Message-ID: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>

Shenandoah introduced fast code roots iteration (ShenandoahCodeRootsStyle = 2), also kept 2 additional iteration
mechanism (ShenandoahCodeRootsStyle = 0 and 1), mainly for verification purpose.

Today, Shenandoah normally iterates code roots concurrently using style 2, while style 0 and 1 require safepoints, that
makes style 0 and 1 verification less useful. Besides, Shenandoah has much improved verifier, more suitable for the
purpose.

Let's remove this diagnostic flag and related test.

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

Commit messages:
 - 8254075: Shenandoah: Remove ShenandoahCodeRootsStyle diagnostic flag and related test

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

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

From shade at openjdk.java.net  Tue Oct  6 13:55:10 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Oct 2020 13:55:10 GMT
Subject: RFR: 8254075: Shenandoah: Remove ShenandoahCodeRootsStyle
 diagnostic flag and related test
In-Reply-To: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
References: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
Message-ID: <SzX7c2rj-WLeR4v5vjxmnrEIYYO_u6iRJG5hZLcFylc=.dd4bcb54-7fb2-4f7e-9e5e-bff32136002d@github.com>

On Tue, 6 Oct 2020 13:40:02 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah introduced fast code roots iteration (ShenandoahCodeRootsStyle = 2), also kept 2 additional iteration
> mechanism (ShenandoahCodeRootsStyle = 0 and 1), mainly for verification purpose.
> Today, Shenandoah normally iterates code roots concurrently using style 2, while style 0 and 1 require safepoints, that
> makes style 0 and 1 verification less useful. Besides, Shenandoah has much improved verifier, more suitable for the
> purpose.  Let's remove this diagnostic flag and related test.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah

Looks fine to me, except `ClassUnloading` handling in one place.

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

> 38:
> 39: bool ShenandoahConcurrentRoots::can_do_concurrent_class_unloading() {
> 40:   return true;

Hold on, this used to check `ClassUnloading`, should it continue to check it?

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

Changes requested by shade (Reviewer).

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

From zgu at openjdk.java.net  Tue Oct  6 14:07:09 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 6 Oct 2020 14:07:09 GMT
Subject: RFR: 8254075: Shenandoah: Remove ShenandoahCodeRootsStyle
 diagnostic flag and related test
In-Reply-To: <SzX7c2rj-WLeR4v5vjxmnrEIYYO_u6iRJG5hZLcFylc=.dd4bcb54-7fb2-4f7e-9e5e-bff32136002d@github.com>
References: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
 <SzX7c2rj-WLeR4v5vjxmnrEIYYO_u6iRJG5hZLcFylc=.dd4bcb54-7fb2-4f7e-9e5e-bff32136002d@github.com>
Message-ID: <ZHrwi555bNo4jZrSnOIAzl-6-D-dMRSR3MZayb0GDsA=.4d67620c-dc7c-4138-baa1-65b269f07817@github.com>

On Tue, 6 Oct 2020 13:52:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah introduced fast code roots iteration (ShenandoahCodeRootsStyle = 2), also kept 2 additional iteration
>> mechanism (ShenandoahCodeRootsStyle = 0 and 1), mainly for verification purpose.
>> Today, Shenandoah normally iterates code roots concurrently using style 2, while style 0 and 1 require safepoints, that
>> makes style 0 and 1 verification less useful. Besides, Shenandoah has much improved verifier, more suitable for the
>> purpose.  Let's remove this diagnostic flag and related test.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>
> src/hotspot/share/gc/shenandoah/shenandoahConcurrentRoots.cpp line 40:
> 
>> 38:
>> 39: bool ShenandoahConcurrentRoots::can_do_concurrent_class_unloading() {
>> 40:   return true;
> 
> Hold on, this used to check `ClassUnloading`, should it continue to check it?

No. I actually puzzled why checked it here, our concurrent roots scanner can handle both scenarios.
Maybe a leftover from concurrent roots to concurrent class unloading transition?

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

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

From shade at openjdk.java.net  Tue Oct  6 14:07:10 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Oct 2020 14:07:10 GMT
Subject: RFR: 8254075: Shenandoah: Remove ShenandoahCodeRootsStyle
 diagnostic flag and related test
In-Reply-To: <ZHrwi555bNo4jZrSnOIAzl-6-D-dMRSR3MZayb0GDsA=.4d67620c-dc7c-4138-baa1-65b269f07817@github.com>
References: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
 <SzX7c2rj-WLeR4v5vjxmnrEIYYO_u6iRJG5hZLcFylc=.dd4bcb54-7fb2-4f7e-9e5e-bff32136002d@github.com>
 <ZHrwi555bNo4jZrSnOIAzl-6-D-dMRSR3MZayb0GDsA=.4d67620c-dc7c-4138-baa1-65b269f07817@github.com>
Message-ID: <ImH9N7bT315Y0MFqKRuOy6b2aEB3wxnexEW2J2ZBVPg=.c61b5c0d-683a-4633-91d8-252dadea20e8@github.com>

On Tue, 6 Oct 2020 14:01:42 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentRoots.cpp line 40:
>> 
>>> 38:
>>> 39: bool ShenandoahConcurrentRoots::can_do_concurrent_class_unloading() {
>>> 40:   return true;
>> 
>> Hold on, this used to check `ClassUnloading`, should it continue to check it?
>
> No. I actually puzzled why checked it here, our concurrent roots scanner can handle both scenarios.
> Maybe a leftover from concurrent roots to concurrent class unloading transition?

It is maybe something that disables concurrent class unloading when `-ClassUnloading` is specified? Although it should
have been handled in `shenandoahArguments.cpp`. Still, I'd prefer to leave the behavior exact, and then remove the
`ClassUnloading` reference in a separate PR.

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

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

From zgu at openjdk.java.net  Tue Oct  6 14:42:25 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 6 Oct 2020 14:42:25 GMT
Subject: RFR: 8254075: Shenandoah: Remove ShenandoahCodeRootsStyle
 diagnostic flag and related test [v2]
In-Reply-To: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
References: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
Message-ID: <YSpp6FSqlp5lGf4rSL1G2OGtIh6ytAEVaggFToPtKHE=.83e842e5-6c83-47e3-8f0e-8199e1f71ab7@github.com>

> Shenandoah introduced fast code roots iteration (ShenandoahCodeRootsStyle = 2), also kept 2 additional iteration
> mechanism (ShenandoahCodeRootsStyle = 0 and 1), mainly for verification purpose.
> Today, Shenandoah normally iterates code roots concurrently using style 2, while style 0 and 1 require safepoints, that
> makes style 0 and 1 verification less useful. Besides, Shenandoah has much improved verifier, more suitable for the
> purpose.  Let's remove this diagnostic flag and related test.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah

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

  Update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/524/files
  - new: https://git.openjdk.java.net/jdk/pull/524/files/834fed17..093a63a4

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

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

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

From shade at openjdk.java.net  Tue Oct  6 14:42:25 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 6 Oct 2020 14:42:25 GMT
Subject: RFR: 8254075: Shenandoah: Remove ShenandoahCodeRootsStyle
 diagnostic flag and related test [v2]
In-Reply-To: <YSpp6FSqlp5lGf4rSL1G2OGtIh6ytAEVaggFToPtKHE=.83e842e5-6c83-47e3-8f0e-8199e1f71ab7@github.com>
References: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
 <YSpp6FSqlp5lGf4rSL1G2OGtIh6ytAEVaggFToPtKHE=.83e842e5-6c83-47e3-8f0e-8199e1f71ab7@github.com>
Message-ID: <H8HEm4ttSVxceUeGZf5RQZr6nME9zSfsypA9_Y4szSM=.6b3a1022-3dbb-496e-b66a-810cefa81fbb@github.com>

On Tue, 6 Oct 2020 14:39:32 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Shenandoah introduced fast code roots iteration (ShenandoahCodeRootsStyle = 2), also kept 2 additional iteration
>> mechanism (ShenandoahCodeRootsStyle = 0 and 1), mainly for verification purpose.
>> Today, Shenandoah normally iterates code roots concurrently using style 2, while style 0 and 1 require safepoints, that
>> makes style 0 and 1 verification less useful. Besides, Shenandoah has much improved verifier, more suitable for the
>> purpose.  Let's remove this diagnostic flag and related test.
>> 
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update

Marked as reviewed by shade (Reviewer).

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

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

From zgu at openjdk.java.net  Tue Oct  6 14:42:26 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 6 Oct 2020 14:42:26 GMT
Subject: RFR: 8254075: Shenandoah: Remove ShenandoahCodeRootsStyle
 diagnostic flag and related test [v2]
In-Reply-To: <ImH9N7bT315Y0MFqKRuOy6b2aEB3wxnexEW2J2ZBVPg=.c61b5c0d-683a-4633-91d8-252dadea20e8@github.com>
References: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
 <SzX7c2rj-WLeR4v5vjxmnrEIYYO_u6iRJG5hZLcFylc=.dd4bcb54-7fb2-4f7e-9e5e-bff32136002d@github.com>
 <ZHrwi555bNo4jZrSnOIAzl-6-D-dMRSR3MZayb0GDsA=.4d67620c-dc7c-4138-baa1-65b269f07817@github.com>
 <ImH9N7bT315Y0MFqKRuOy6b2aEB3wxnexEW2J2ZBVPg=.c61b5c0d-683a-4633-91d8-252dadea20e8@github.com>
Message-ID: <8adqImxSiVpFiahtsZ-JumbxXsTnU5YU32HrCH_FCNw=.db0a8219-db73-40d4-a22e-c98a926fe9a3@github.com>

On Tue, 6 Oct 2020 14:04:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> No. I actually puzzled why checked it here, our concurrent roots scanner can handle both scenarios.
>> Maybe a leftover from concurrent roots to concurrent class unloading transition?
>
> It is maybe something that disables concurrent class unloading when `-ClassUnloading` is specified? Although it should
> have been handled in `shenandoahArguments.cpp`. Still, I'd prefer to leave the behavior exact, and then remove the
> `ClassUnloading` reference in a separate PR.

Make sense, updated.

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

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

From rriggs at openjdk.java.net  Tue Oct  6 15:16:11 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 6 Oct 2020 15:16:11 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
 <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
Message-ID: <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>

On Mon, 5 Oct 2020 21:45:06 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Core Libs changes and the test look fine.
>
> 8248188: Add IntrinsicCandidate and API for Base64 decoding, add Power64LE intrinsic implementation.
> 
> This patch set encompasses the following commits:
> 
> Adds a new intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the
> intrinsic. The API is similar to the existing encodeBlock intrinsic.
> Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
> implementation.
> Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> 
> Adds a JMH microbenchmark for both Base64 encoding and encoding.
> 
> Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

fyi, there is no need to do a rebase.  The preferred way is to do a merge.
When the changes are integrated, all of the individual commits are squashed to create a single commit.

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

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

From akozlov at openjdk.java.net  Tue Oct  6 15:27:09 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 6 Oct 2020 15:27:09 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS [v2]
In-Reply-To: <Ex2LM49zd4hKTYl845sEPpuaMwVaWPF-5FyCqSXWwPI=.74d61f86-3233-4a3d-8366-0f79d268f0f0@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <Ex2LM49zd4hKTYl845sEPpuaMwVaWPF-5FyCqSXWwPI=.74d61f86-3233-4a3d-8366-0f79d268f0f0@github.com>
Message-ID: <i-_AwXR1i7_kNp-pYUv_PDLf_ptToMAWdkGape6MQZ8=.aab7bb15-462b-4ab8-a13a-4df9aea1d757@github.com>

On Tue, 29 Sep 2020 07:12:35 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the
>> os::reserve_memory changes in this patch.
>
>> @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the
>> os::reserve_memory changes in this patch.
> 
> FWIW, I now understand that the motivation for the changes in os::reserve_memory is *not* that *it* uses MAP_FIXED.
> Instead the change there is done so that os::commit_memory doesn't have to mix mmap + MAP_FIXED + MAP_JIT. This is also
> the reason why os::uncommit_memory needs to be changed as well. So, ignore my comment above.

Hi @tstuefe,

Recent refactors interfered with the previous version of the patch, I found it is a bit simpler to start from scratch.
https://github.com/openjdk/jdk/pull/294/commits/f8664ca7dcc1cfdfb9a1f032035f2cde77048649 is a minimal patch that allows
MAP_JIT. I cannot see any way to simplify the interface now. Please tell me if I miss something. Also, `VirtualSpace`
now choose from `reserve_memory_with_fd` and anything that is used for reserve with exec.

What I found in the AIX implementation, the commit/uncommit are for memory previously reserved
https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L2227. If we attribute reserved region with
exec, then uncommit can query bookkeeping info and get the type of memory.

>From options of internal bookkeeping info or an asking the system for the mmap flags, I prefer the first one. It is
faster and we can bookkeep only minimal info, like a list of executable regions. That should reduce the amount of data
and make a check for the type in commit/uncommit faster.

After looking around, it does look like every place where commit with exec is used, we know enough to use
reserve/uncommit with exec. Taking this to the extreme, I still think a specialized set of reserve/commit/uncommit for
executable regions would look natural. For example, commit with exec is used in less than five places. I'll do a little
research there.

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

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

From zgu at openjdk.java.net  Tue Oct  6 15:32:09 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 6 Oct 2020 15:32:09 GMT
Subject: Integrated: 8254075: Shenandoah: Remove ShenandoahCodeRootsStyle
 diagnostic flag and related test
In-Reply-To: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
References: <8i9BZyONlzms6qDxSDYHgBcCO7Eu1VoliTCi6-gLPwM=.00d3c377-b2ed-46d5-b1c6-00f8c34f260e@github.com>
Message-ID: <ml-PujYbsG__9CSSVKRoUwpWXdusCyrR7m7liSapeEc=.3a8ba87d-d8f1-4009-a947-70b5d3d767d7@github.com>

On Tue, 6 Oct 2020 13:40:02 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah introduced fast code roots iteration (ShenandoahCodeRootsStyle = 2), also kept 2 additional iteration
> mechanism (ShenandoahCodeRootsStyle = 0 and 1), mainly for verification purpose.
> Today, Shenandoah normally iterates code roots concurrently using style 2, while style 0 and 1 require safepoints, that
> makes style 0 and 1 verification less useful. Besides, Shenandoah has much improved verifier, more suitable for the
> purpose.  Let's remove this diagnostic flag and related test.
> 
> Test:
> 
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 51fdb4c0
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/51fdb4c0
Stats:     141 lines in 5 files changed: 0 ins; 129 del; 12 mod

8254075: Shenandoah: Remove ShenandoahCodeRootsStyle diagnostic flag and related test

Reviewed-by: shade

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

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

From stuefe at openjdk.java.net  Tue Oct  6 16:41:13 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 6 Oct 2020 16:41:13 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS [v2]
In-Reply-To: <i-_AwXR1i7_kNp-pYUv_PDLf_ptToMAWdkGape6MQZ8=.aab7bb15-462b-4ab8-a13a-4df9aea1d757@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <Ex2LM49zd4hKTYl845sEPpuaMwVaWPF-5FyCqSXWwPI=.74d61f86-3233-4a3d-8366-0f79d268f0f0@github.com>
 <i-_AwXR1i7_kNp-pYUv_PDLf_ptToMAWdkGape6MQZ8=.aab7bb15-462b-4ab8-a13a-4df9aea1d757@github.com>
Message-ID: <_XaA5cQEInPMn5Q5gj2y7AFCRprFQiYfI6BeUN49FhA=.9f17ae05-b37e-4f40-a83f-fd34aa812575@github.com>

On Tue, 6 Oct 2020 15:23:56 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>>> @tstuefe My patch to remove MAP_FIXED from the memory reservation path should make it possible to revert all the
>>> os::reserve_memory changes in this patch.
>> 
>> FWIW, I now understand that the motivation for the changes in os::reserve_memory is *not* that *it* uses MAP_FIXED.
>> Instead the change there is done so that os::commit_memory doesn't have to mix mmap + MAP_FIXED + MAP_JIT. This is also
>> the reason why os::uncommit_memory needs to be changed as well. So, ignore my comment above.
>
> Hi @tstuefe,
> 
> Recent refactors interfered with the previous version of the patch, I found it is a bit simpler to start from scratch.
> https://github.com/openjdk/jdk/pull/294/commits/f8664ca7dcc1cfdfb9a1f032035f2cde77048649 is a minimal patch that allows
> MAP_JIT. I cannot see any way to simplify the interface now. Please tell me if I miss something. Also, `VirtualSpace`
> now choose from `reserve_memory_with_fd` and anything that is used for reserve with exec.   What I found in the AIX
> implementation, the commit/uncommit are for memory previously reserved
> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L2227. If we attribute reserved region with
> exec, then uncommit can query bookkeeping info and get the type of memory.  From options of internal bookkeeping info
> or an asking the system for the mmap flags, I prefer the first one. It is faster and we can bookkeep only minimal info,
> like a list of executable regions. That should reduce the amount of data and make a check for the type in
> commit/uncommit faster.  After looking around, it does look like every place where commit with exec is used, we know
> enough to use reserve/uncommit with exec. Taking this to the extreme, I still think a specialized set of
> reserve/commit/uncommit for executable regions would look natural. For example, commit with exec is used in less than
> five places. I'll do a little research there.

> Hi @tstuefe,
> 
> Recent refactors interfered with the previous version of the patch, I found it is a bit simpler to start from scratch.
> [f8664ca](https://github.com/openjdk/jdk/commit/f8664ca7dcc1cfdfb9a1f032035f2cde77048649) is a minimal patch that
> allows MAP_JIT. I cannot see any way to simplify the interface now. Please tell me if I miss something. Also,
> `VirtualSpace` now choose from `reserve_memory_with_fd` and anything that is used for reserve with exec.  What I found
> in the AIX implementation, the commit/uncommit are for memory previously reserved
> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L2227. If we attribute reserved region with
> exec, then uncommit can query bookkeeping info and get the type of memory.

On AIX there is no explicit commit, committing happens on touch and uncommitting unfortunately does not really work
(there is a disclaim() but its buggy). All commit does is to check the input parameters and maybe explictly touch the
area.

> 
> From options of internal bookkeeping info or an asking the system for the mmap flags, I prefer the first one. It is
> faster and we can bookkeep only minimal info, like a list of executable regions. That should reduce the amount of data
> and make a check for the type in commit/uncommit faster.  After looking around, it does look like every place where
> commit with exec is used, we know enough to use reserve/uncommit with exec. Taking this to the extreme, I still think a
> specialized set of reserve/commit/uncommit for executable regions would look natural. For example, commit with exec is
> used in less than five places. I'll do a little research there.

I thought a lot about this.

As you said, I believe now that specifying exec (or other parameters, see below) is not necessary on a per-commit; on
per-mapping level it should be enough.

I also see at least three separate cases where we establish a mapping and later need mapping-specific information
somewhere until the next interaction - be it commit/uncommit or release:

1) On AIX, where we decide at os::reserve_memory time to use either SystemV or mmap and later need to know
2) On Linux when TPH are active the information "Use TPH" is handed down to os::commit via the weird alignment_hint
parameter and that os::realign_memory() function. Following that parameter flow, it is just basically a way to flag the
code to do one extra madvice at commit time. 3) Your case now, where we need to know if the mapping was supposed to be
executable at commit time.

I really think a generic solution would be best. One simple variant would be to return not a pointer but a handle and
let the platform store behind that handle whatever it needs to keep on a per-mapping base:

handle_t os::reserve_memory(size, input flags);
void* start_address = os::get_reserved_memory_start_address(handle_t)
bool os::commit_memory(handle_t, address, size)

and so on. The only problem with that is that it would cause a lot of call sites to change, and the callers need to
hold on to that mapping handle.

To be clear, I do not think you should do this with this patch, but I would like your opinion, since you looked at the
code closely.

I'll review the current version presently.

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

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

From stuefe at openjdk.java.net  Tue Oct  6 16:48:18 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Tue, 6 Oct 2020 16:48:18 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS [v2]
In-Reply-To: <6CNTkYXWf4_yX13e6G4fusS8fijamDb13jtPDdHNY6g=.0459ff64-960a-4dd5-9715-07ed0ba88012@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <6CNTkYXWf4_yX13e6G4fusS8fijamDb13jtPDdHNY6g=.0459ff64-960a-4dd5-9715-07ed0ba88012@github.com>
Message-ID: <tUtimoDPLFzj0F7eUGycW1kddGtp9Hdz8G3J7vm1Zb8=.5d425cec-3ca8-4ea4-a7f9-d722bc7fd56f@github.com>

On Tue, 6 Oct 2020 13:40:22 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html
>> 
>> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL,
>> PROT_NONE), the function was made aware of exec permissions.
>> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference
>> compared with old code.
>> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and
>> immediately reflects this in diagnostic tools like ps.  For executable regions it would require MAP_FIXED|MAP_JIT, so
>> instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently
>> this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not
>> shrink (if I haven't missed anything, by the implementation and in principle).  Tested:
>> * local tier1
>> * jdk-submit
>> * codesign[2] with hardened runtime and allow-jit but without
>> allow-unsigned-executable-memory entitlements[3] produce a working bundle.
>> 
>> (adding GC group as suggested by @dholmes-ora)
>> 
>> 
>> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227
>> [2]
>>  
>>   codesign \
>>     --sign - \
>>     --options runtime \
>>     --entitlements ents.plist \
>>     --timestamp \
>>     $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib
>> [3]
>>   <?xml version="1.0" encoding="UTF-8"?>
>>   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
>>   <plist version="1.0">
>>     <dict>
>>       <key>com.apple.security.cs.allow-jit</key>
>>       <true/>
>>       <key>com.apple.security.cs.disable-library-validation</key>
>>       <true/>
>>       <key>com.apple.security.cs.allow-dyld-environment-variables</key>
>>       <true/>
>>     </dict>
>>   </plist>
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains four commits:
>  - Minimal working example, no uncommit
>  - Merge remote-tracking branch 'upstream/master' into 8234930
>  - Revert "Use MAP_JIT for CodeCache pages"
>    
>    This reverts commit 114d9cffd62cab42790b65091648fe75345c4533.
>  - Use MAP_JIT for CodeCache pages

src/hotspot/os/bsd/os_bsd.cpp line 2010:

> 2008:   return ::mprotect(addr, size, PROT_NONE) == 0;
> 2009: #elif defined(__APPLE__)
> 2010:   if (false) {

I'm confused, how would this work?

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Tue Oct  6 17:45:08 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 6 Oct 2020 17:45:08 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
 <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
 <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>
Message-ID: <FV7h5HwbFiCoB7MEZnSRxCL_DmFMjCAjVXJ8aQm82O8=.d29f5506-3cbc-427d-a854-838688b154b5@github.com>

On Tue, 6 Oct 2020 15:13:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> fyi, there is no need to do a rebase. The preferred way is to do a merge.
> When the changes are integrated, all of the individual commits are squashed to create a single commit.

Good to know, thanks.

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

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

From Frederic.Poliquin at dti.ulaval.ca  Tue Oct  6 17:55:44 2020
From: Frederic.Poliquin at dti.ulaval.ca (=?iso-8859-1?Q?Fr=E9d=E9ric_Poliquin?=)
Date: Tue, 6 Oct 2020 17:55:44 +0000
Subject: Shenandoah performance
Message-ID: <QB1PR01MB36353EAF0E251AA8DC907D75BD0D0@QB1PR01MB3635.CANPRD01.PROD.OUTLOOK.COM>

Hello,

I'm not sure if I am writing at the right place but I'll give it a go.

We have this legacy web application developped with Oracle ADF which is very memory intensive. We are currently using G1. The application is stable as long as the CPU is under 40 %. If the load exceeds this limit, we can experience ? stop the world ? collections that can last above 1 minute which is unacceptable.

We recently tried Shenandoah but was disappointed by the performance. The CPU is generally 10 to 20 % higher and when the load exceeds 50 %, we experience ? stop the world ? collections that last for 5 to 7 seconds many times per minute which leads to very poor response time.

We use 20 pods deployed on OpenShift running a custom Docker image based on Fedora with the Fedora Java 8 build.

Here are the settings for G1 :
-server -XX:+UseG1GC -XX:+UseStringDeduplication -Xms2G -Xmx3G

Here are the settings for Shenandoah :
-server -XX:+UseShenandoahGC -Xms2G -Xmx3G

Is there any recommandation or best practice that we could use, any advice, is this a normal behavior for Shenandoah ?

I always tried to keep the heap as small as possible but should we increase resource allocation and reduce the number of pods ?

Any help would be appreciated.

Thank you.

Fr?d?ric Poliquin

From shade at redhat.com  Tue Oct  6 18:12:21 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Tue, 6 Oct 2020 20:12:21 +0200
Subject: Shenandoah performance
In-Reply-To: <QB1PR01MB36353EAF0E251AA8DC907D75BD0D0@QB1PR01MB3635.CANPRD01.PROD.OUTLOOK.COM>
References: <QB1PR01MB36353EAF0E251AA8DC907D75BD0D0@QB1PR01MB3635.CANPRD01.PROD.OUTLOOK.COM>
Message-ID: <43bc38db-f174-c4c4-79c6-b04ff03557b6@redhat.com>

Hi,

On 10/6/20 7:55 PM, Fr?d?ric Poliquin wrote:
> The CPU is generally 10 to 20 % higher and when the load exceeds 50 %, we experience ? stop the
> world ? collections that last for 5 to 7 seconds many times per minute which leads to very poor
> response time.
Sounds like application is routinely outpacing the GC.
The excerpt from the GC log would tell quite a bit more.

> Is there any recommandation or best practice that we could use, any advice, is this a normal
> behavior for Shenandoah
Please read:
   https://wiki.openjdk.java.net/display/Shenandoah#Main-PerformanceGuidelinesandDiagnostics

> I always tried to keep the heap as small as possible but should we increase resource allocation
> and reduce the number of pods ?
Concurrent GCs (especially non-generational yet, like Shenandoah) need more free heap to catch up 
with allocations, otherwise they would have to stall. So, giving it more heap might just be enough. 
But it is hard to tell without looking at a GC log.

-- 
Thanks,
-Aleksey


From rriggs at openjdk.java.net  Tue Oct  6 18:17:17 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 6 Oct 2020 18:17:17 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <FV7h5HwbFiCoB7MEZnSRxCL_DmFMjCAjVXJ8aQm82O8=.d29f5506-3cbc-427d-a854-838688b154b5@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
 <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
 <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>
 <FV7h5HwbFiCoB7MEZnSRxCL_DmFMjCAjVXJ8aQm82O8=.d29f5506-3cbc-427d-a854-838688b154b5@github.com>
Message-ID: <ElVpGg2aHJTZc-BVvK-lMglFshCqE1qgozUDE5JRyc0=.37d1c5d4-656b-4e46-b549-09bb7e1a26d5@github.com>

On Tue, 6 Oct 2020 17:42:36 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> fyi, there is no need to do a rebase.  The preferred way is to do a merge.
>> When the changes are integrated, all of the individual commits are squashed to create a single commit.
>
>> fyi, there is no need to do a rebase. The preferred way is to do a merge.
>> When the changes are integrated, all of the individual commits are squashed to create a single commit.
> 
> Good to know, thanks.

We'll need a HotSpot Reviewer to approve too.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Tue Oct  6 18:22:07 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 6 Oct 2020 18:22:07 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <ElVpGg2aHJTZc-BVvK-lMglFshCqE1qgozUDE5JRyc0=.37d1c5d4-656b-4e46-b549-09bb7e1a26d5@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <T48t-_XIiM_NlSZau6pj9hjSxp--n9pktxI6XCZ-W8k=.54c779af-e1af-4e62-9e4f-48ed7145bfc9@github.com>
 <jUYJaiGKl3ktWaYGsPH8p_Nd38t8I5AtdKtaVaDJcR0=.e8417e8d-91b5-41f3-af81-6e485167bd44@github.com>
 <qv0XG1izvRxgj90kajyp1XhQvt7gIuPtZdrbTVkAeLY=.6daf3496-e70e-47a7-a6d0-61127b9ec649@github.com>
 <FV7h5HwbFiCoB7MEZnSRxCL_DmFMjCAjVXJ8aQm82O8=.d29f5506-3cbc-427d-a854-838688b154b5@github.com>
 <ElVpGg2aHJTZc-BVvK-lMglFshCqE1qgozUDE5JRyc0=.37d1c5d4-656b-4e46-b549-09bb7e1a26d5@github.com>
Message-ID: <5HeCT4pIrQCiAKTemQtl9pu8IDADDLgsQZ2eoDeSbhw=.d6a76689-97ca-4a0e-9ac7-5398b3774de4@github.com>

On Tue, 6 Oct 2020 18:13:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> We'll need a HotSpot Reviewer to approve too.

I have requested help from the team here.

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

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

From akozlov at openjdk.java.net  Tue Oct  6 20:13:16 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 6 Oct 2020 20:13:16 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS [v3]
In-Reply-To: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
Message-ID: <H1xu16uXslCuDUQBQdgBUyJUD6CCZp3WuowGtrBd2To=.693beba2-bb29-4176-9369-5e77eced7e3d@github.com>

> Please review an updated RFR from https://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2020-August/041463.html
> 
> On macOS, MAP_JIT cannot be used with MAP_FIXED[1]. So pd_reserve_memory have to provide MAP_JIT for mmap(NULL,
> PROT_NONE), the function was made aware of exec permissions.
> For executable and data regions, pd_commit_memory only unlocks the memory with mprotect, this should make no difference
> compared with old code.
> For data regions, pd_uncommit_memory still uses a new overlapping anonymous mmap which returns pages to the OS and
> immediately reflects this in diagnostic tools like ps.  For executable regions it would require MAP_FIXED|MAP_JIT, so
> instead madvise(MADV_FREE)+mprotect(PROT_NONE) are used. They should also allow OS to reclaim pages, but apparently
> this does not happen immediately. In practice, it should not be a problem for executable regions, as codecache does not
> shrink (if I haven't missed anything, by the implementation and in principle).  Tested:
> * local tier1
> * jdk-submit
> * codesign[2] with hardened runtime and allow-jit but without
> allow-unsigned-executable-memory entitlements[3] produce a working bundle.
> 
> (adding GC group as suggested by @dholmes-ora)
> 
> 
> [1] https://github.com/apple/darwin-xnu/blob/master/bsd/kern/kern_mman.c#L227
> [2]
>  
>   codesign \
>     --sign - \
>     --options runtime \
>     --entitlements ents.plist \
>     --timestamp \
>     $J/bin/* $J/lib/server/*.dylib $J/lib/*.dylib
> [3]
>   <?xml version="1.0" encoding="UTF-8"?>
>   <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
>   <plist version="1.0">
>     <dict>
>       <key>com.apple.security.cs.allow-jit</key>
>       <true/>
>       <key>com.apple.security.cs.disable-library-validation</key>
>       <true/>
>       <key>com.apple.security.cs.allow-dyld-environment-variables</key>
>       <true/>
>     </dict>
>   </plist>

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

  Bookkeeping without interface changes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/294/files
  - new: https://git.openjdk.java.net/jdk/pull/294/files/f8664ca7..0016bc4a

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

  Stats: 105 lines in 6 files changed: 75 ins; 12 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/294/head:pull/294

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

From akozlov at openjdk.java.net  Tue Oct  6 21:06:10 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 6 Oct 2020 21:06:10 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS [v3]
In-Reply-To: <_XaA5cQEInPMn5Q5gj2y7AFCRprFQiYfI6BeUN49FhA=.9f17ae05-b37e-4f40-a83f-fd34aa812575@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <Ex2LM49zd4hKTYl845sEPpuaMwVaWPF-5FyCqSXWwPI=.74d61f86-3233-4a3d-8366-0f79d268f0f0@github.com>
 <i-_AwXR1i7_kNp-pYUv_PDLf_ptToMAWdkGape6MQZ8=.aab7bb15-462b-4ab8-a13a-4df9aea1d757@github.com>
 <_XaA5cQEInPMn5Q5gj2y7AFCRprFQiYfI6BeUN49FhA=.9f17ae05-b37e-4f40-a83f-fd34aa812575@github.com>
Message-ID: <PFzznwIPYp2kFR5kXp6vLivLAtm6GJEihlOm6rljZsA=.a5de51e3-d595-46c0-83b6-dbd0e423ad2d@github.com>

On Tue, 6 Oct 2020 16:38:47 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hi @tstuefe,
>> 
>> Recent refactors interfered with the previous version of the patch, I found it is a bit simpler to start from scratch.
>> https://github.com/openjdk/jdk/pull/294/commits/f8664ca7dcc1cfdfb9a1f032035f2cde77048649 is a minimal patch that allows
>> MAP_JIT. I cannot see any way to simplify the interface now. Please tell me if I miss something. Also, `VirtualSpace`
>> now choose from `reserve_memory_with_fd` and anything that is used for reserve with exec.   What I found in the AIX
>> implementation, the commit/uncommit are for memory previously reserved
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L2227. If we attribute reserved region with
>> exec, then uncommit can query bookkeeping info and get the type of memory.  From options of internal bookkeeping info
>> or an asking the system for the mmap flags, I prefer the first one. It is faster and we can bookkeep only minimal info,
>> like a list of executable regions. That should reduce the amount of data and make a check for the type in
>> commit/uncommit faster.  After looking around, it does look like every place where commit with exec is used, we know
>> enough to use reserve/uncommit with exec. Taking this to the extreme, I still think a specialized set of
>> reserve/commit/uncommit for executable regions would look natural. For example, commit with exec is used in less than
>> five places. I'll do a little research there.
>
>> Hi @tstuefe,
>> 
>> Recent refactors interfered with the previous version of the patch, I found it is a bit simpler to start from scratch.
>> [f8664ca](https://github.com/openjdk/jdk/commit/f8664ca7dcc1cfdfb9a1f032035f2cde77048649) is a minimal patch that
>> allows MAP_JIT. I cannot see any way to simplify the interface now. Please tell me if I miss something. Also,
>> `VirtualSpace` now choose from `reserve_memory_with_fd` and anything that is used for reserve with exec.  What I found
>> in the AIX implementation, the commit/uncommit are for memory previously reserved
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/aix/os_aix.cpp#L2227. If we attribute reserved region with
>> exec, then uncommit can query bookkeeping info and get the type of memory.
> 
> On AIX there is no explicit commit, committing happens on touch and uncommitting unfortunately does not really work
> (there is a disclaim() but its buggy). All commit does is to check the input parameters and maybe explictly touch the
> area.
>> 
>> From options of internal bookkeeping info or an asking the system for the mmap flags, I prefer the first one. It is
>> faster and we can bookkeep only minimal info, like a list of executable regions. That should reduce the amount of data
>> and make a check for the type in commit/uncommit faster.  After looking around, it does look like every place where
>> commit with exec is used, we know enough to use reserve/uncommit with exec. Taking this to the extreme, I still think a
>> specialized set of reserve/commit/uncommit for executable regions would look natural. For example, commit with exec is
>> used in less than five places. I'll do a little research there.
> 
> I thought a lot about this.
> 
> As you said, I believe now that specifying exec (or other parameters, see below) is not necessary on a per-commit; on
> per-mapping level it should be enough.
> I also see at least three separate cases where we establish a mapping and later need mapping-specific information
> somewhere until the next interaction - be it commit/uncommit or release:
> 1) On AIX, where we decide at os::reserve_memory time to use either SystemV or mmap and later need to know
> 2) On Linux when TPH are active the information "Use TPH" is handed down to os::commit via the weird alignment_hint
> parameter and that os::realign_memory() function. Following that parameter flow, it is just basically a way to flag the
> code to do one extra madvice at commit time. 3) Your case now, where we need to know if the mapping was supposed to be
> executable at commit time.  I really think a generic solution would be best. One simple variant would be to return not
> a pointer but a handle and let the platform store behind that handle whatever it needs to keep on a per-mapping base:
> handle_t os::reserve_memory(size, input flags);
> void* start_address = os::get_reserved_memory_start_address(handle_t)
> bool os::commit_memory(handle_t, address, size)
> 
> and so on. The only problem with that is that it would cause a lot of call sites to change, and the callers need to
> hold on to that mapping handle.
> To be clear, I do not think you should do this with this patch, but I would like your opinion, since you looked at the
> code closely.
> I'll review the current version presently.

Sorry, I had not highlighted that was a proof-of-concept patch to show API changes. I've pushed another PoC with
bookkeeping and no API changes at all. But I don't like the new one either. In the new patch, there is a list of
(potentially) executable regions that is updated on commit, when the actual desired (non)exec mode become known. If we
support mixed exec/non-exec commits in a mapping, then after non-exec commit a part of the mapping cannot be reversed
to a potentially executable one (as we've lost MAP_JIT). Then it can produce some unexpected results under _some_
conditions in runtime, while API users can be unconscious about potential issues. Good API should not allow that.

>  specifying exec ... on per-mapping level it should be enough.

With this, it is possible to simplify the implementation without API changes. But it will still be 1) reserve and be
prepare for the first exec or non-exec commit 2) on commit, finish reserve and turn the mapping to the exec or
non-exec. All this instead of taking direct parameter "this is a executable mapping" on reserve.

The current "commit only knows about exec" is just a leak of implementation details, as before it was only required to
know executable mode. Providing exec parameter to reserve will just bring consistency to the interface. Or, a separate
interface for exec (code) mappings will serve the same and will be better, as it will simplify the general non-code
reserve/commit interface.

> I also see at least three separate cases where we establish a mapping and later need mapping-specific information
> somewhere until the next interaction - be it commit/uncommit or release: [ AIX SystemV or mmap, Linux THP, macOS
> MAP_JIT for code ]

Could you explain how the choice between SysV and mmap is made on AIX? It looks like
  
develop(uintx, Use64KPagesThreshold, 0,                                           \
          "4K/64K page allocation threshold.")                                      \
...
  if (os::vm_page_size() == 4*K) {
    return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
  } else {
    if (bytes >= Use64KPagesThreshold) {
      return reserve_shmated_memory(bytes, NULL /* requested_addr */);
    } else {
      return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
    }
  }
(there only two calls to reserve_shmated_memory and both of them are like above. Is SysV SHM used in product builds?)
For now, the AIX case looks a bit different. The choice is made by the platform and the shared code cannot control
this. So yes, I cannot see how to avoid handle_t or similar.

In contrast, THP and MAP_JIT are the way to implement a request from the shared code. Even for THP, shared code seems
to know why it should "realign" (not sure why commit has an alignment_hint parameter, while it is possible to realign
after a regular commit). I assume there is enough context in the shared code that can be provided for platform
functions, without a handle_t. And the same context should anyway be provided to reserve function, so handle_t can be
filled with all necessary information.

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

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

From zgu at openjdk.java.net  Wed Oct  7 12:35:25 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 7 Oct 2020 12:35:25 GMT
Subject: RFR: 8254103: Shenandoah: Move updating thread roots to concurrent
 phase
Message-ID: <cJ807ZYdMJrdvA1uZfiaysdcm0HB63EBzlyL3PRZhtk=.24ab7e33-488a-40bb-ac2f-b47264e363c2@github.com>

Due to non-atomic LRB, there can be from-space oops in thread roots after evacuation.
To enforce to-space invariant, Shenandoah updates thread roots during final reference updating pause, but it can be
done outside pause via thread handshake.

Test:

- [x] hotspot_gc_shenandoah

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

Commit messages:
 - Fix indentations
 - Merge branch 'master' into JDK-8254103-conc-threads-update
 - Update
 - Init update

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

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

From rriggs at openjdk.java.net  Wed Oct  7 13:38:21 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 7 Oct 2020 13:38:21 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <HOu6omKjwLS5JBVS4sq0mjt1ZZwxvbH597cmwwG7QQs=.6d5549e6-5459-43b2-9bc4-e108cd852f25@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/java.base/share/classes/java/util/Base64.java line 776:

> 774:          * @param  sl
> 775:          *         the total length of source array
> 776:          * @param  dst

Please update the comment for `sl`.  sl is the offset (exclusive) past the last byte to be converted.

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 14:06:20 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 14:06:20 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <r5FtoUonRPCmhZ7ueswqkgh9pTwoA4rYrrpfVIO1zBE=.2917dc6c-d288-4ea4-b958-e6021025b9e5@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/java.base/share/classes/java/util/Base64.java line 812:

> 810:
> 811:             while (sp < sl) {
> 812:                 if (shiftto == 18 && sp + 4 < sl) {       // fast path

Please change to sp < s1 - 4. Current version is sensitive to integer overflow. That's not a real problem in the
current code, because the next check catches that, but we should better avoid this with the new intrinsics.

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 14:31:18 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 14:31:18 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <M1zvEmLqLC0oKqzSfjyEag5zxGLyml-YUHq1T1EjwYM=.21d8f1bc-da68-4a46-9ca9-6c36ab79cf81@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3818:

> 3816:     __ cmpd(CCR0, end, in);
> 3817:     __ blt_predict_not_taken(CCR0, unrolled_loop_exit);
> 3818:     __ align(32);

align should be before bind(unrolled_loop_start)

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3:

> 1: /*
> 2:  * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
> 3:  * Copyright (c) 2012, 2020, SAP SE. All rights reserved.

No comma before SAP SE, please! (See https://bugs.openjdk.java.net/browse/JDK-8252837)

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 14:47:20 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 14:47:20 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <EBJOWz3mKQcINbANH02rbc8XpGSBron9k6ifJ6dWt8E=.6578bcd3-6fed-4b6b-92ab-b6d590ce3fa0@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3812:

> 3810:     // Address of the last byte of the source is (in + sl - 1)
> 3811:     __ add(end, in, sl);
> 3812:     __ subi(end, end, 1);

Looks a bit complicated, but ok. I'd have loaded the number of iterations into ctr and used bdnz instruction for the
loop.

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3671:

> 3669:     // an advantage to keeping loop_unrolls small (to be able to process
> 3670:     // smaller buffers), 2 is clearly the best choice.
> 3671:     const unsigned loop_unrolls = 2;

Unrolling should be re-evaluated after alignment is fixed. align(32) is currently at the wrong place (see my comment
below).

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:18:30 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:18:30 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <rnI7hCJFNObraJ1fywhxrbQ8jqPbAtPtyxMN85xTD4I=.b9ec9107-b1e2-4d4e-bf0e-aa07bfd3ee64@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/cpu/ppc/vm_version_ppc.cpp line 160:

> 158:     if (UseBASE64Intrinsics) {
> 159:       warning("UseBASE64Intrinsics specified, but needs at least Power9.");
> 160:       FLAG_SET_DEFAULT(UseCharacterCompareIntrinsics, false);

Copy & paste bug.

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:21:11 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:21:11 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <hgCh4kI6MtKoOIrxQny7QnEv2qwS6KuLrezICPMviHw=.53ec3cf5-92ce-4a01-b9ae-5536a7944128@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/share/classfile/vmIntrinsics.cpp line 491:

> 489:     if (!UseGHASHIntrinsics) return true;
> 490:     break;
> 491:   case vmIntrinsics::_base64_decodeBlock:

I'd prefer to use consistent order. You have inserted decode after encode at other places.

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:27:09 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:27:09 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <W3jA3X5aarlR1-7K9M4Xj99SJYshONXNMrP0p8hp9gU=.16257956-a74f-41f6-81ae-47a0ea65ad14@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/share/opto/library_call.cpp line 310:

> 308:   bool inline_base64_decodeBlock();
> 309:   bool inline_digestBase_implCompress(vmIntrinsics::ID id);
> 310:   bool inline_sha_implCompress(vmIntrinsics::ID id);

Why is that in this change?

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:40:15 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:40:15 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <sfzgalP37HPAIbzdPSKpTRRmIBcz2NGIgiSKT3fB2BQ=.f1bd5064-b5bd-4684-b4ab-c1131fe96793@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

src/hotspot/share/opto/runtime.cpp line 1211:

> 1209:   // result type needed
> 1210:   fields = TypeTuple::fields(1);
> 1211:   fields[TypeFunc::Parms + 0] = TypeInt::INT; // dst ofs, or -1

Why "- or -1" in the comment?

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 15:52:11 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 15:52:11 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <kTmpe-MW1ZakMcKsESnDEQoImN7wNvbMne6Z9MuIbGE=.e0546e01-0951-477f-a67c-8443fcf2997d@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 89:

> 87:         ran.nextBytes(srcBuf);
> 88:
> 89:         // This should be enough to get both the decoder and encoder intrinsic loaded up and running.

Better: ... get encode() and decode() compiled on highest tier.

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

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

From mdoerr at openjdk.java.net  Wed Oct  7 16:29:13 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 7 Oct 2020 16:29:13 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
Message-ID: <ZqqaFPCInDiTFVub5iozxR4NOckf5yej6k7-sR3MP_s=.b1c9690b-5226-41a6-8f95-f1fa5232f757@github.com>

On Mon, 5 Oct 2020 18:29:58 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
> contains ten commits:
>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>    
>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>    arches that implement AOT, implement the decodeBlock intrinsic.
>  - Base64.java decodeBlock: Changes from PR review
>    
>     * Make comparison safer and consistent with the while loop
>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>     * Add comment about the lack of a length check on the destination buffer
>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>  - stubGenerator_ppc.cpp: Changes from PR review
>    
>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>     * align unrolled loop on a 32-byte boundary
>     * replace instruction used for checking isURL from a double word to single
>       word instruction since the register is effectively 32 bits wide
>     * cosmetic change to realign register comments.
>  - TestBase64.java: Changes from PR review
>    
>     * Use Utils.toByteArrays() method instead of a locally-defined method
>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>     * Added comments describing the two above-mentioned arrays
>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>    
>    This patch makes four significant changes:
>    
>    1) The Power implementation of the decodeBlock intrinsic, at least,
>    requires a decode length of at least 128 bytes, but the existing test cases
>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>    data file which has longer test cases in it.
>    
>    2) The original test cases only covers the encoding of just the printable
>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>    being able to encode arbitrary binary data, i.e. it must handle all 256
>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>    style of the input data, I added another input file type that uses a simple
>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>    test0 is called, a new parameter is passed that specifies the type of the
>    input file, which is either the original ASCII type or the hexadecimal
>    format.  So to test both longer input data and arbitrary 8-bit data, the
>    newly added input test file has test cases which are both longer and
>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>    this type of file, test0 calls a newly-added function to translate the
>    ASCII hex to binary data.  Except for the first line of input data, which
>    contains all possible 8-bit values sequentially, the input data was
>    generated using a random length (between 111 and 520 bytes) buffer filled
>    with random 8-bit data, which should give adequate coverage.
>    
>    3) The original test did not test that the decoder detects illegal Base64
>    bytes.  This change chooses a random location in the encoded data to
>    corrupt with a randomly-chosen byte which is illegal for the specific
>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>    the decode function to verify that the illegal byte is detected and the
>    proper exception is thrown.
>    
>    4) The test iteration count was originally 100K, but that is far more than
>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>    three types of encodings to test and called the encode intrinsic four times
>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>    encode.  Decode was called four times as well (now five because of the
>    illegal byte test).  I believe this is excessive and with the extra test
>    data I have added, the test was timing out after ten minutes of execution.
>    It appears that it is timing out, not because the intrinsics take a long
>    time to run, but because test0 generates an enormous number of discarded
>    data buffers for the GC system to recover (the test runs at about 39GB of
>    virtual memory on my test machine).  To remedy the timeout problem, I have
>    changed the code so that a warmup function of 20K repetitions is performed
>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>    reduced the number of iterations to 5K on each test0 call.  This should
>    give adequate coverage.
>  - Add JMH benchmark for Base64 variable length buffer decoding
>  - Add Power9+ intrinsic implementation for Base64 decoding
>  - Add HotSpot code to implement Base64 decodeBlock API
>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding

Hi Corey,
thanks for contributing this change. Looks basically good. Please address the inline comments from Roger and me.
Core libs part is reviewed by Roger and the whole change by me. The shared hotspot part is straight forward because
it's very similar to the encode intrinsic. So I think we only need a 2nd review for the PPC64 algorithm implementation.
I can sponsor the change when this is completed.

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

Changes requested by mdoerr (Reviewer).

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

From zgu at openjdk.java.net  Wed Oct  7 16:57:23 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 7 Oct 2020 16:57:23 GMT
Subject: RFR: 8254103: Shenandoah: Move updating thread roots to
 concurrent phase [v2]
In-Reply-To: <cJ807ZYdMJrdvA1uZfiaysdcm0HB63EBzlyL3PRZhtk=.24ab7e33-488a-40bb-ac2f-b47264e363c2@github.com>
References: <cJ807ZYdMJrdvA1uZfiaysdcm0HB63EBzlyL3PRZhtk=.24ab7e33-488a-40bb-ac2f-b47264e363c2@github.com>
Message-ID: <u0qvQKyM8kqMrk6Kpa_73kIJpb63SsZG3sjkk4QS2sM=.c58d436e-d4f2-4d02-bfbf-7d95b044cb29@github.com>

> Due to non-atomic LRB, there can be from-space oops in thread roots after evacuation.
> To enforce to-space invariant, Shenandoah updates thread roots during final reference updating pause, but it can be
> done outside pause via thread handshake.
> Test:
> 
> - [x] hotspot_gc_shenandoah

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

  Update

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/541/files
  - new: https://git.openjdk.java.net/jdk/pull/541/files/18bfac35..5dd16f59

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

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct  7 17:24:12 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 7 Oct 2020 17:24:12 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <HOu6omKjwLS5JBVS4sq0mjt1ZZwxvbH597cmwwG7QQs=.6d5549e6-5459-43b2-9bc4-e108cd852f25@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <HOu6omKjwLS5JBVS4sq0mjt1ZZwxvbH597cmwwG7QQs=.6d5549e6-5459-43b2-9bc4-e108cd852f25@github.com>
Message-ID: <czcCaNp0j7Mu6RpBxWdaImL8cokJLll8xKm3LwU4UDA=.8f454c10-dd30-4032-8bcd-dab80dc48595@github.com>

On Wed, 7 Oct 2020 13:35:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> src/java.base/share/classes/java/util/Base64.java line 776:
> 
>> 774:          * @param  sl
>> 775:          *         the total length of source array
>> 776:          * @param  dst
> 
> Please update the comment for `sl`.  sl is the offset (exclusive) past the last byte to be converted.

Ok, will change.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct  7 17:24:17 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 7 Oct 2020 17:24:17 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <r5FtoUonRPCmhZ7ueswqkgh9pTwoA4rYrrpfVIO1zBE=.2917dc6c-d288-4ea4-b958-e6021025b9e5@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <r5FtoUonRPCmhZ7ueswqkgh9pTwoA4rYrrpfVIO1zBE=.2917dc6c-d288-4ea4-b958-e6021025b9e5@github.com>
Message-ID: <eeX_BLBKC1ubNxaDyzQ34EubuaIklTcEZ08nThdLkT8=.0c07596d-982a-4bec-bf8d-c776ecd34e93@github.com>

On Wed, 7 Oct 2020 14:03:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> src/java.base/share/classes/java/util/Base64.java line 812:
> 
>> 810:
>> 811:             while (sp < sl) {
>> 812:                 if (shiftto == 18 && sp + 4 < sl) {       // fast path
> 
> Please change to sp < s1 - 4. Current version is sensitive to integer overflow. That's not a real problem in the
> current code, because the next check catches that, but we should better avoid this with the new intrinsics.

Good catch. Will fix.

> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3818:
> 
>> 3816:     __ cmpd(CCR0, end, in);
>> 3817:     __ blt_predict_not_taken(CCR0, unrolled_loop_exit);
>> 3818:     __ align(32);
> 
> align should be before bind(unrolled_loop_start)

oops, yes, that was dumb.  Good catch!   Will fix and re-benchmark.

> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 1997, 2020, Oracle and/or its affiliates. All rights reserved.
>> 3:  * Copyright (c) 2012, 2020, SAP SE. All rights reserved.
> 
> No comma before SAP SE, please! (See https://bugs.openjdk.java.net/browse/JDK-8252837)

Interesting.  I was trying to make it consistent with the Oracle copyright.  Ok, will fix.

> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3671:
> 
>> 3669:     // an advantage to keeping loop_unrolls small (to be able to process
>> 3670:     // smaller buffers), 2 is clearly the best choice.
>> 3671:     const unsigned loop_unrolls = 2;
> 
> Unrolling should be re-evaluated after alignment is fixed. align(32) is currently at the wrong place (see my comment
> below).

Agreed.

> src/hotspot/cpu/ppc/vm_version_ppc.cpp line 160:
> 
>> 158:     if (UseBASE64Intrinsics) {
>> 159:       warning("UseBASE64Intrinsics specified, but needs at least Power9.");
>> 160:       FLAG_SET_DEFAULT(UseCharacterCompareIntrinsics, false);
> 
> Copy & paste bug.

Oops, yes, will fix.

> src/hotspot/share/classfile/vmIntrinsics.cpp line 491:
> 
>> 489:     if (!UseGHASHIntrinsics) return true;
>> 490:     break;
>> 491:   case vmIntrinsics::_base64_decodeBlock:
> 
> I'd prefer to use consistent order. You have inserted decode after encode at other places.

I agree.  Will fix.

> src/hotspot/share/opto/library_call.cpp line 310:
> 
>> 308:   bool inline_base64_decodeBlock();
>> 309:   bool inline_digestBase_implCompress(vmIntrinsics::ID id);
>> 310:   bool inline_sha_implCompress(vmIntrinsics::ID id);
> 
> Why is that in this change?

Good catch!  I'm not sure what happened there.  Will investigate.

> src/hotspot/share/opto/runtime.cpp line 1211:
> 
>> 1209:   // result type needed
>> 1210:   fields = TypeTuple::fields(1);
>> 1211:   fields[TypeFunc::Parms + 0] = TypeInt::INT; // dst ofs, or -1
> 
> Why ", or -1" in the comment?

At one point the intrinsic would return -1 in the event of encountering a non-base64 byte.  I will update the comment
to be correct for the revised semantics.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct  7 17:52:16 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 7 Oct 2020 17:52:16 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <kTmpe-MW1ZakMcKsESnDEQoImN7wNvbMne6Z9MuIbGE=.e0546e01-0951-477f-a67c-8443fcf2997d@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <kTmpe-MW1ZakMcKsESnDEQoImN7wNvbMne6Z9MuIbGE=.e0546e01-0951-477f-a67c-8443fcf2997d@github.com>
Message-ID: <G3ANouwFzck1xuZZcT56qxH9fgXrJkhoGP0mr6MHNVI=.39ae1148-e607-467c-92d1-f8c96be73fdb@github.com>

On Wed, 7 Oct 2020 15:48:37 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 89:
> 
>> 87:         ran.nextBytes(srcBuf);
>> 88:
>> 89:         // This should be enough to get both the decoder and encoder intrinsic loaded up and running.
> 
> Better: ... get encode() and decode() compiled on highest tier.

Thanks.  I'm still learning the lingo :)  Will fix.

> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3812:
> 
>> 3810:     // Address of the last byte of the source is (in + sl - 1)
>> 3811:     __ add(end, in, sl);
>> 3812:     __ subi(end, end, 1);
> 
> Looks a bit complicated, but ok. I'd have loaded the number of iterations into ctr and used bdnz instruction for the
> loop. (bdz / bdnz may also be slighly faster depending on the CPU implementation.)

I agree that a count would be preferable, because it's easier to read.  Will fix.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Oct  7 17:52:16 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 7 Oct 2020 17:52:16 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <eeX_BLBKC1ubNxaDyzQ34EubuaIklTcEZ08nThdLkT8=.0c07596d-982a-4bec-bf8d-c776ecd34e93@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <r5FtoUonRPCmhZ7ueswqkgh9pTwoA4rYrrpfVIO1zBE=.2917dc6c-d288-4ea4-b958-e6021025b9e5@github.com>
 <eeX_BLBKC1ubNxaDyzQ34EubuaIklTcEZ08nThdLkT8=.0c07596d-982a-4bec-bf8d-c776ecd34e93@github.com>
Message-ID: <ZTaNq9Hg1Mqrz2DjqY7mD33YycROZDE-LOatAYClqTM=.034ba6ee-eb96-4938-a82e-500e974bcf5a@github.com>

On Wed, 7 Oct 2020 17:19:50 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 310:
>> 
>>> 308:   bool inline_base64_decodeBlock();
>>> 309:   bool inline_digestBase_implCompress(vmIntrinsics::ID id);
>>> 310:   bool inline_sha_implCompress(vmIntrinsics::ID id);
>> 
>> Why is that in this change?
>
> Good catch!  I'm not sure what happened there.  Will investigate.

This seems to be a mistake I made during a rebase with a conflict. Will fix.

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

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

From stuefe at openjdk.java.net  Wed Oct  7 18:45:06 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 7 Oct 2020 18:45:06 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS [v3]
In-Reply-To: <PFzznwIPYp2kFR5kXp6vLivLAtm6GJEihlOm6rljZsA=.a5de51e3-d595-46c0-83b6-dbd0e423ad2d@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <Ex2LM49zd4hKTYl845sEPpuaMwVaWPF-5FyCqSXWwPI=.74d61f86-3233-4a3d-8366-0f79d268f0f0@github.com>
 <i-_AwXR1i7_kNp-pYUv_PDLf_ptToMAWdkGape6MQZ8=.aab7bb15-462b-4ab8-a13a-4df9aea1d757@github.com>
 <_XaA5cQEInPMn5Q5gj2y7AFCRprFQiYfI6BeUN49FhA=.9f17ae05-b37e-4f40-a83f-fd34aa812575@github.com>
 <PFzznwIPYp2kFR5kXp6vLivLAtm6GJEihlOm6rljZsA=.a5de51e3-d595-46c0-83b6-dbd0e423ad2d@github.com>
Message-ID: <VGBa5FHWmNaLG-br9EHoNhrmIF3OOcGUap0gT-zkInw=.10084e0a-f039-4971-8eaa-7a3ca7483191@github.com>

On Tue, 6 Oct 2020 21:03:34 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> 
> Could you explain how the choice between SysV and mmap is made on AIX? It looks like
> 
> ```
> develop(uintx, Use64KPagesThreshold, 0,                                           \
>           "4K/64K page allocation threshold.")                                      \
> ...
>   if (os::vm_page_size() == 4*K) {
>     return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
>   } else {
>     if (bytes >= Use64KPagesThreshold) {
>       return reserve_shmated_memory(bytes, NULL /* requested_addr */);
>     } else {
>       return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
>     }
>   }
> ```
> 
> (there only two calls to reserve_shmated_memory and both of them are like above. Is SysV SHM used in product builds?)
> For now, the AIX case looks a bit different. The choice is made by the platform and the shared code cannot control
> this. So yes, I cannot see how to avoid handle_t or similar.

On AIX we have 4K and 64K pages (actually more but those are interesting). 64K pages are desireable for larger areas
like heap. 64K pages can only be allocated with SystemV shared memory. mmap'ed memory is always 4K paged. But SystemV
shared mem has a number of disadvantages, like inability to protect the memory, and a large attach alignment (256M). So
it is cumbersome.

os::vm_page_size() on AIX is a fake. The hotspot code assumes that the underlying Operating System has some sort of
"base page size" (usually what is returned by sysconf(_SC_PAGESIZE)), and then optionally some sort of huge page size
which follows different rules (e.g. pinned). On Aix things are more fluid.

When investigating 64K page support on AIX I decided eventually to fool hotspot into thinking that the base page size
is 64k. Long story, this was way before the OpenJDK existed and this was a propietary code base with no possibilty of
changing things upstream. Therefore os::vm_page_size returns 64K ("64K fake mode"). This can be disabled.

So above code fragment uses mmaped memory if 64K fake mode is disabled, and if it is enabeld, it uses mmap for smaller
regions and shmget for larger ones.

> 
> In contrast, THP and MAP_JIT are the way to implement a request from the shared code. Even for THP, shared code seems
> to know why it should "realign" (not sure why commit has an alignment_hint parameter, while it is possible to realign
> after a regular commit). I assume there is enough context in the shared code that can be provided for platform
> functions, without a handle_t. And the same context should anyway be provided to reserve function, so handle_t can be
> filled with all necessary information.

I believe the alignment hint and the TPH code had their roots in Solaris code. So its current form (I guess) is heavily
warped by history. A new implementation would maybe just have a "os::set_tph(start, size)" function and leave it at
that. And yes, I do not think it is necessary for os::commit to do this.

In fact, Linux could probably set TPH unconditionally always when UseTransparentHugePages is active. That would
alleviate the need for the alignment_hint parameter and the realign function.

I opened https://bugs.openjdk.java.net/browse/JDK-8253890 to follow up on this.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct  8 06:53:42 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 8 Oct 2020 06:53:42 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v2]
In-Reply-To: <ZqqaFPCInDiTFVub5iozxR4NOckf5yej6k7-sR3MP_s=.b1c9690b-5226-41a6-8f95-f1fa5232f757@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <6P-wrlA7c9wlXEhcoAYW5J9W2jwTmTTj3PkDObPh0LA=.c11aa048-8853-4e1c-a689-c34b89c15f12@github.com>
 <ZqqaFPCInDiTFVub5iozxR4NOckf5yej6k7-sR3MP_s=.b1c9690b-5226-41a6-8f95-f1fa5232f757@github.com>
Message-ID: <R06iFTJu66Y6z7eGVBuBZ71nnLxBIsMWSd8Us9veW2Q=.cbb68f9b-1a12-478f-b5dc-fb730d1c658e@github.com>

On Wed, 7 Oct 2020 16:26:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request with a new target base due to a merge or a rebase. The pull request now
>> contains ten commits:
>>  - AOT: Revert change to aotCodeHeap.cpp for decodeBlock
>>    
>>    Don't add the SET_AOT_GLOBAL_SYMBOL_VALUE macro for decode block until all
>>    arches that implement AOT, implement the decodeBlock intrinsic.
>>  - Base64.java decodeBlock: Changes from PR review
>>    
>>     * Make comparison safer and consistent with the while loop
>>     * Update comment about the decodeBlock intrinsic so that it matches the new structure
>>     * Add comment about the lack of a length check on the destination buffer
>>     * As per issue 8138732, change HotSpotIntrinsicCandidate to IntrinsicCandidate
>>  - stubGenerator_ppc.cpp: Changes from PR review
>>    
>>     * Fix clearing of upper bits to clear 32 bits instead of 31 (due to misreading of clrldi instruction)
>>     * change and document loop_unrolls setting from 8 to 2 after re-running the benchmark
>>     * align unrolled loop on a 32-byte boundary
>>     * replace instruction used for checking isURL from a double word to single
>>       word instruction since the register is effectively 32 bits wide
>>     * cosmetic change to realign register comments.
>>  - TestBase64.java: Changes from PR review
>>    
>>     * Use Utils.toByteArrays() method instead of a locally-defined method
>>     * Generate the two non-Base64 tables dynamically rather than use static initialization
>>     * Added comments describing the two above-mentioned arrays
>>  - Expand the Base64 intrinsic regression test to cover decodeBlock
>>    
>>    This patch makes four significant changes:
>>    
>>    1) The Power implementation of the decodeBlock intrinsic, at least,
>>    requires a decode length of at least 128 bytes, but the existing test cases
>>    are much shorter, maxing out at 111 bytes.  So the patch adds a new input
>>    data file which has longer test cases in it.
>>    
>>    2) The original test cases only covers the encoding of just the printable
>>    subset of the 7-bit ASCII characters.  However, Base64 encoding requires
>>    being able to encode arbitrary binary data, i.e. it must handle all 256
>>    8-bit byte encodings.  To remedy this, but keep the original line-oriented
>>    style of the input data, I added another input file type that uses a simple
>>    ASCII hexadecimal encoding - two ASCII hex characters per 8-bit byte.  When
>>    test0 is called, a new parameter is passed that specifies the type of the
>>    input file, which is either the original ASCII type or the hexadecimal
>>    format.  So to test both longer input data and arbitrary 8-bit data, the
>>    newly added input test file has test cases which are both longer and
>>    encoded in ASCII hex so as to give full 8-bit capability.  When reading
>>    this type of file, test0 calls a newly-added function to translate the
>>    ASCII hex to binary data.  Except for the first line of input data, which
>>    contains all possible 8-bit values sequentially, the input data was
>>    generated using a random length (between 111 and 520 bytes) buffer filled
>>    with random 8-bit data, which should give adequate coverage.
>>    
>>    3) The original test did not test that the decoder detects illegal Base64
>>    bytes.  This change chooses a random location in the encoded data to
>>    corrupt with a randomly-chosen byte which is illegal for the specific
>>    Base64 encoding that is chosen (i.e. standard or URLsafe).  It then calls
>>    the decode function to verify that the illegal byte is detected and the
>>    proper exception is thrown.
>>    
>>    4) The test iteration count was originally 100K, but that is far more than
>>    enough iterations to test the intrinsic.  It takes 20K iterations on each
>>    instrinsic for HotSpot C2 to begin calling it.  The test originally had
>>    three types of encodings to test and called the encode intrinsic four times
>>    for each iteration, which works out to 100K * 3 * 4 = 1.2M calls just to
>>    encode.  Decode was called four times as well (now five because of the
>>    illegal byte test).  I believe this is excessive and with the extra test
>>    data I have added, the test was timing out after ten minutes of execution.
>>    It appears that it is timing out, not because the intrinsics take a long
>>    time to run, but because test0 generates an enormous number of discarded
>>    data buffers for the GC system to recover (the test runs at about 39GB of
>>    virtual memory on my test machine).  To remedy the timeout problem, I have
>>    changed the code so that a warmup function of 20K repetitions is performed
>>    on a fixed buffer, to activate the instrinsic(s).  After the warmup, I have
>>    reduced the number of iterations to 5K on each test0 call.  This should
>>    give adequate coverage.
>>  - Add JMH benchmark for Base64 variable length buffer decoding
>>  - Add Power9+ intrinsic implementation for Base64 decoding
>>  - Add HotSpot code to implement Base64 decodeBlock API
>>  - Add HotSpotIntrinsicCandidate and API for Base64 decoding
>
> Hi Corey,
> thanks for contributing this change. Looks basically good. Please address the inline comments from Roger and me.
> Core libs part is reviewed by Roger and the whole change by me. The shared hotspot part is straight forward because
> it's very similar to the encode intrinsic. So I think we only need a 2nd review for the PPC64 algorithm implementation.
> I can sponsor the change when this is completed.

Ready for another review.  I hope I addressed all of the issues raised.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct  8 06:53:26 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 8 Oct 2020 06:53:26 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v3]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <BPUaQTDmxtonENpeoEp5xhJBjS7LB4vESLH7A8sH1-k=.755d7497-1fa1-4ca2-9d95-4477460f7626@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

CoreyAshford has updated the pull request incrementally with seven additional commits since the last revision:

 - stubGenerator_ppc.cpp: Fix multiple issues as per Martin Doerr's v2 review
   
    * Remove extraneous comma from SAP copyright notice
    * Move align(32) to the head of the loop rather than the beginning of the unwound code
    * Simplified looping condition to use a loop counter instead of a final
      address.  This eliminated the need for the "end" variable, and
      essentially replaced it with CTR, which is computed using a simple
      bitwise shift of the size.
    * Re-ran benchmarks against loop_unrolls values: 1, 2, 4, 8, 16 to find
      optimal value, now 4.
    * Corrected a typo in the word "elements"
 - vm_version_ppc.cpp: per Martin Doerr's review of v2: fix copy/paste error
 - vmIntrinsics.cpp: Per Martin Doerr's v2 review: rearrange order of case statement to be consistent with others.
 - runtime.cpp: per Martin Doerr's review of v2, correct comment as per current semantics of decodeBlock()
   
     * The reference to "ofs" seems to be a copy/paste error.
     * -1 is no longer returned from decodeBlock() in the event of a
       non-base64 character being encountered; only a count of bytes written
       to dst.
 - TestBase64.java: Change comment as per Martin Doerr's v2 review
 - Base64.java: Make changes as per Roger Riggs and Martin Doerr's v2 Review
   
     * Make comment about the sl parameter more precise
     * Fix comparison to avoid possible integer overflow of sp
 - library_call.cpp: Fix rebase merge error

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/e42ac7db..8932c233

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

  Stats: 42 lines in 7 files changed: 9 ins; 11 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

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

From mdoerr at openjdk.java.net  Thu Oct  8 10:46:51 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 8 Oct 2020 10:46:51 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v3]
In-Reply-To: <BPUaQTDmxtonENpeoEp5xhJBjS7LB4vESLH7A8sH1-k=.755d7497-1fa1-4ca2-9d95-4477460f7626@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <BPUaQTDmxtonENpeoEp5xhJBjS7LB4vESLH7A8sH1-k=.755d7497-1fa1-4ca2-9d95-4477460f7626@github.com>
Message-ID: <BEknTe_U8l2MO30Mb5nt6Z6w87fHu4aLRZg8Xs8vbIY=.09f48a18-833a-478d-8946-fd238910e340@github.com>

On Thu, 8 Oct 2020 06:53:26 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - stubGenerator_ppc.cpp: Fix multiple issues as per Martin Doerr's v2 review
>    
>     * Remove extraneous comma from SAP copyright notice
>     * Move align(32) to the head of the loop rather than the beginning of the unwound code
>     * Simplified looping condition to use a loop counter instead of a final
>       address.  This eliminated the need for the "end" variable, and
>       essentially replaced it with CTR, which is computed using a simple
>       bitwise shift of the size.
>     * Re-ran benchmarks against loop_unrolls values: 1, 2, 4, 8, 16 to find
>       optimal value, now 4.
>     * Corrected a typo in the word "elements"
>  - vm_version_ppc.cpp: per Martin Doerr's review of v2: fix copy/paste error
>  - vmIntrinsics.cpp: Per Martin Doerr's v2 review: rearrange order of case statement to be consistent with others.
>  - runtime.cpp: per Martin Doerr's review of v2, correct comment as per current semantics of decodeBlock()
>    
>      * The reference to "ofs" seems to be a copy/paste error.
>      * -1 is no longer returned from decodeBlock() in the event of a
>        non-base64 character being encountered; only a count of bytes written
>        to dst.
>  - TestBase64.java: Change comment as per Martin Doerr's v2 review
>  - Base64.java: Make changes as per Roger Riggs and Martin Doerr's v2 Review
>    
>      * Make comment about the sl parameter more precise
>      * Fix comparison to avoid possible integer overflow of sp
>  - library_call.cpp: Fix rebase merge error

Changes requested by mdoerr (Reviewer).

src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3806:

> 3804:     // Load CTR with the number of passes through the unrolled loop
> 3805:     // = sl >> block_size_shift
> 3806:     __ srawi(sl, sl, block_size_shift);

Thanks, this is more simple. Unfortunately, sl can become 0. So I think we should move these 2 lines down before the
align and use: srawi_
beq(CCR0, unrolled_loop_exit)
mtctr

test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 90:

> 88:
> 89:         // This should be enough to get both encodeBlock() and
> 90:         // decodeBlock() compiled on the highest tier.

It's actually encode() and decode() which should get compiled. You should see them when testing
with -XX:+PrintCompilation. And you should see usage of the intrinsics by -XX:+PrintInlining.

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

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

From zgu at openjdk.java.net  Thu Oct  8 13:53:45 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 8 Oct 2020 13:53:45 GMT
Subject: Integrated: 8254103: Shenandoah: Move updating thread roots to
 concurrent phase
In-Reply-To: <cJ807ZYdMJrdvA1uZfiaysdcm0HB63EBzlyL3PRZhtk=.24ab7e33-488a-40bb-ac2f-b47264e363c2@github.com>
References: <cJ807ZYdMJrdvA1uZfiaysdcm0HB63EBzlyL3PRZhtk=.24ab7e33-488a-40bb-ac2f-b47264e363c2@github.com>
Message-ID: <ApTlacQSIHMS0ZWtDjmQskZ_jkBWvxdshF3g9Mygn_8=.b3dbe781-ff94-4ff3-8f24-aece1081a9d9@github.com>

On Wed, 7 Oct 2020 12:19:51 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Due to non-atomic LRB, there can be from-space oops in thread roots after evacuation.
> To enforce to-space invariant, Shenandoah updates thread roots during final reference updating pause, but it can be
> done outside pause via thread handshake.
> Test:
> 
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

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

8254103: Shenandoah: Move updating thread roots to concurrent phase

Reviewed-by: rkennke

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct  8 17:19:28 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 8 Oct 2020 17:19:28 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v3]
In-Reply-To: <BEknTe_U8l2MO30Mb5nt6Z6w87fHu4aLRZg8Xs8vbIY=.09f48a18-833a-478d-8946-fd238910e340@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <BPUaQTDmxtonENpeoEp5xhJBjS7LB4vESLH7A8sH1-k=.755d7497-1fa1-4ca2-9d95-4477460f7626@github.com>
 <BEknTe_U8l2MO30Mb5nt6Z6w87fHu4aLRZg8Xs8vbIY=.09f48a18-833a-478d-8946-fd238910e340@github.com>
Message-ID: <L78lIh07xw0hwfDOsbZEs7XUuzAnuygd_Zfe9izs_H4=.2eea888a-91de-49dc-8c51-e2025559e6dd@github.com>

On Thu, 8 Oct 2020 10:41:32 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> CoreyAshford has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - stubGenerator_ppc.cpp: Fix multiple issues as per Martin Doerr's v2 review
>>    
>>     * Remove extraneous comma from SAP copyright notice
>>     * Move align(32) to the head of the loop rather than the beginning of the unwound code
>>     * Simplified looping condition to use a loop counter instead of a final
>>       address.  This eliminated the need for the "end" variable, and
>>       essentially replaced it with CTR, which is computed using a simple
>>       bitwise shift of the size.
>>     * Re-ran benchmarks against loop_unrolls values: 1, 2, 4, 8, 16 to find
>>       optimal value, now 4.
>>     * Corrected a typo in the word "elements"
>>  - vm_version_ppc.cpp: per Martin Doerr's review of v2: fix copy/paste error
>>  - vmIntrinsics.cpp: Per Martin Doerr's v2 review: rearrange order of case statement to be consistent with others.
>>  - runtime.cpp: per Martin Doerr's review of v2, correct comment as per current semantics of decodeBlock()
>>    
>>      * The reference to "ofs" seems to be a copy/paste error.
>>      * -1 is no longer returned from decodeBlock() in the event of a
>>        non-base64 character being encountered; only a count of bytes written
>>        to dst.
>>  - TestBase64.java: Change comment as per Martin Doerr's v2 review
>>  - Base64.java: Make changes as per Roger Riggs and Martin Doerr's v2 Review
>>    
>>      * Make comment about the sl parameter more precise
>>      * Fix comparison to avoid possible integer overflow of sp
>>  - library_call.cpp: Fix rebase merge error
>
> test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java line 90:
> 
>> 88:
>> 89:         // This should be enough to get both encodeBlock() and
>> 90:         // decodeBlock() compiled on the highest tier.
> 
> It's actually encode() and decode() which should get compiled. You should see them when testing
> with -XX:+PrintCompilation. And you should see usage of the intrinsics by -XX:+PrintInlining.

Ah, useful tips!  Thanks!

I will make this comment change.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Thu Oct  8 20:31:47 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 8 Oct 2020 20:31:47 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>   implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

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

 - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
   
   The intrinsic names that are visible with -XX:+PrintCompilation are encode
   and decode, rather than encodeBlock and decodeBlock.
 - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
   
   My original fix didn't account for the case where sl < block_size.  In the
   event sl < block_size, the shifted sl will become zero, so it should
   jump to the code that computes how much data was processed - 0 - and return.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/8932c233..164fa2a9

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

  Stats: 13 lines in 2 files changed: 7 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

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

From mdoerr at openjdk.java.net  Thu Oct  8 20:47:23 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 8 Oct 2020 20:47:23 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v4]
In-Reply-To: <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <45FtTQB1m6HyZSASY42STMkQffIWlVPibWn9_r00xYs=.daad2653-2571-491f-8dd7-5954fe4ece00@github.com>
Message-ID: <b31lt6WjaR_4A-SpZgj24X3q4qjH7jnhPUtKcEjOyOk=.25704362-ae1c-4f54-9c65-b03f78008905@github.com>

On Thu, 8 Oct 2020 20:31:47 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for
>>   the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic
>>   implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - TestBase64.java: fix comment to correctly reflect actual intrinsic names.
>    
>    The intrinsic names that are visible with -XX:+PrintCompilation are encode
>    and decode, rather than encodeBlock and decodeBlock.
>  - stubGenerator_ppc.cpp: fix regression caused by change to using loop counter
>    
>    My original fix didn't account for the case where sl < block_size.  In the
>    event sl < block_size, the shifted sl will become zero, so it should
>    jump to the code that computes how much data was processed - 0 - and return.

Marked as reviewed by mdoerr (Reviewer).

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

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

From stuefe at openjdk.java.net  Fri Oct  9 06:08:20 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 9 Oct 2020 06:08:20 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS [v3]
In-Reply-To: <VGBa5FHWmNaLG-br9EHoNhrmIF3OOcGUap0gT-zkInw=.10084e0a-f039-4971-8eaa-7a3ca7483191@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <Ex2LM49zd4hKTYl845sEPpuaMwVaWPF-5FyCqSXWwPI=.74d61f86-3233-4a3d-8366-0f79d268f0f0@github.com>
 <i-_AwXR1i7_kNp-pYUv_PDLf_ptToMAWdkGape6MQZ8=.aab7bb15-462b-4ab8-a13a-4df9aea1d757@github.com>
 <_XaA5cQEInPMn5Q5gj2y7AFCRprFQiYfI6BeUN49FhA=.9f17ae05-b37e-4f40-a83f-fd34aa812575@github.com>
 <PFzznwIPYp2kFR5kXp6vLivLAtm6GJEihlOm6rljZsA=.a5de51e3-d595-46c0-83b6-dbd0e423ad2d@github.com>
 <VGBa5FHWmNaLG-br9EHoNhrmIF3OOcGUap0gT-zkInw=.10084e0a-f039-4971-8eaa-7a3ca7483191@github.com>
Message-ID: <O2esolxx74O36BQBaFpkYmP75lWzuw102DznqHyPVBU=.b3a8fa4b-5bd3-479b-a2db-18760a879964@github.com>

On Wed, 7 Oct 2020 18:42:34 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Sorry, I had not highlighted that was a proof-of-concept patch to show API changes. I've pushed another PoC with
>> bookkeeping and no API changes at all. But I don't like the new one either. In the new patch, there is a list of
>> (potentially) executable regions that is updated on commit, when the actual desired (non)exec mode become known. If we
>> support mixed exec/non-exec commits in a mapping, then after non-exec commit a part of the mapping cannot be reversed
>> to a potentially executable one (as we've lost MAP_JIT). Then it can produce some unexpected results under _some_
>> conditions in runtime, while API users can be unconscious about potential issues. Good API should not allow that.
>>>  specifying exec ... on per-mapping level it should be enough.
>> 
>> With this, it is possible to simplify the implementation without API changes. But it will still be 1) reserve and be
>> prepare for the first exec or non-exec commit 2) on commit, finish reserve and turn the mapping to the exec or
>> non-exec. All this instead of taking direct parameter "this is a executable mapping" on reserve.  The current "commit
>> only knows about exec" is just a leak of implementation details, as before it was only required to know executable
>> mode. Providing exec parameter to reserve will just bring consistency to the interface. Or, a separate interface for
>> exec (code) mappings will serve the same and will be better, as it will simplify the general non-code reserve/commit
>> interface.
>>> I also see at least three separate cases where we establish a mapping and later need mapping-specific information
>>> somewhere until the next interaction - be it commit/uncommit or release: [ AIX SystemV or mmap, Linux THP, macOS
>>> MAP_JIT for code ]
>> 
>> Could you explain how the choice between SysV and mmap is made on AIX? It looks like
>>   
>> develop(uintx, Use64KPagesThreshold, 0,                                           \
>>           "4K/64K page allocation threshold.")                                      \
>> ...
>>   if (os::vm_page_size() == 4*K) {
>>     return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
>>   } else {
>>     if (bytes >= Use64KPagesThreshold) {
>>       return reserve_shmated_memory(bytes, NULL /* requested_addr */);
>>     } else {
>>       return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
>>     }
>>   }
>> (there only two calls to reserve_shmated_memory and both of them are like above. Is SysV SHM used in product builds?)
>> For now, the AIX case looks a bit different. The choice is made by the platform and the shared code cannot control
>> this. So yes, I cannot see how to avoid handle_t or similar.  In contrast, THP and MAP_JIT are the way to implement a
>> request from the shared code. Even for THP, shared code seems to know why it should "realign" (not sure why commit has
>> an alignment_hint parameter, while it is possible to realign after a regular commit). I assume there is enough context
>> in the shared code that can be provided for platform functions, without a handle_t. And the same context should anyway
>> be provided to reserve function, so handle_t can be filled with all necessary information.
>
>> 
>> Could you explain how the choice between SysV and mmap is made on AIX? It looks like
>> 
>> ```
>> develop(uintx, Use64KPagesThreshold, 0,                                           \
>>           "4K/64K page allocation threshold.")                                      \
>> ...
>>   if (os::vm_page_size() == 4*K) {
>>     return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
>>   } else {
>>     if (bytes >= Use64KPagesThreshold) {
>>       return reserve_shmated_memory(bytes, NULL /* requested_addr */);
>>     } else {
>>       return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
>>     }
>>   }
>> ```
>> 
>> (there only two calls to reserve_shmated_memory and both of them are like above. Is SysV SHM used in product builds?)
>> For now, the AIX case looks a bit different. The choice is made by the platform and the shared code cannot control
>> this. So yes, I cannot see how to avoid handle_t or similar.
> 
> On AIX we have 4K and 64K pages (actually more but those are interesting). 64K pages are desireable for larger areas
> like heap. 64K pages can only be allocated with SystemV shared memory. mmap'ed memory is always 4K paged. But SystemV
> shared mem has a number of disadvantages, like inability to protect the memory, and a large attach alignment (256M). So
> it is cumbersome.  os::vm_page_size() on AIX is a fake. The hotspot code assumes that the underlying Operating System
> has some sort of "base page size" (usually what is returned by sysconf(_SC_PAGESIZE)), and then optionally some sort of
> huge page size which follows different rules (e.g. pinned). On Aix things are more fluid.   When investigating 64K page
> support on AIX I decided eventually to fool hotspot into thinking that the base page size is 64k. Long story, this was
> way before the OpenJDK existed and this was a propietary code base with no possibilty of changing things upstream.
> Therefore os::vm_page_size returns 64K ("64K fake mode"). This can be disabled.  So above code fragment uses mmaped
> memory if 64K fake mode is disabled, and if it is enabeld, it uses mmap for smaller regions and shmget for larger ones.
>> 
>> In contrast, THP and MAP_JIT are the way to implement a request from the shared code. Even for THP, shared code seems
>> to know why it should "realign" (not sure why commit has an alignment_hint parameter, while it is possible to realign
>> after a regular commit). I assume there is enough context in the shared code that can be provided for platform
>> functions, without a handle_t. And the same context should anyway be provided to reserve function, so handle_t can be
>> filled with all necessary information.
> 
> I believe the alignment hint and the TPH code had their roots in Solaris code. So its current form (I guess) is heavily
> warped by history. A new implementation would maybe just have a "os::set_tph(start, size)" function and leave it at
> that. And yes, I do not think it is necessary for os::commit to do this.  In fact, Linux could probably set TPH
> unconditionally always when UseTransparentHugePages is active. That would alleviate the need for the alignment_hint
> parameter and the realign function.  I opened https://bugs.openjdk.java.net/browse/JDK-8253890 to follow up on this.

(more comments)

> Sorry, I had not highlighted that was a proof-of-concept patch to show API changes. I've pushed another PoC with
> bookkeeping and no API changes at all. But I don't like the new one either.

Interesting idea, but IMHO too heavvy weight for a platform only change. Also GrowableArray maybe not the best choice
here since e.g. it requires you to search twice on add. A better solution may be a specialized BST. If there are other
uses for such a solution (managing memory regions, melting them together, splitting them maybe on remove) this would be
worth a generic class. I believe NMT does something similar when managing virtual memory regions, see
VirtualMemoryTracker and friends.

> In the new patch, there is a list of (potentially) executable regions that is updated on commit, when the actual
> desired (non)exec mode become known. If we support mixed exec/non-exec commits in a mapping, then after non-exec commit
> a part of the mapping cannot be reversed to a potentially executable one (as we've lost MAP_JIT).

So once you cleared MAP_JIT from a region you cannot re-apply it? Then this is another reason we should not support
setting and clearing exec on commit but only on a per-mapping base.

> Then it can produce some unexpected results under _some_ conditions in runtime, while API users can be unconscious
> about potential issues. Good API should not allow that.

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

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

From stuefe at openjdk.java.net  Fri Oct  9 06:19:22 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 9 Oct 2020 06:19:22 GMT
Subject: RFR: 8234930: Use MAP_JIT when allocating pages for code cache on
 macOS [v3]
In-Reply-To: <O2esolxx74O36BQBaFpkYmP75lWzuw102DznqHyPVBU=.b3a8fa4b-5bd3-479b-a2db-18760a879964@github.com>
References: <f0P7ljTefK623rhbrkXx4SzvII8wy8wldw8k6Ndw8cA=.16560fd0-88eb-480f-9552-bb894713ccde@github.com>
 <YzatK-1N43NaRdC_eFVBubbdiEcyM8mSNmMQDA1ijaE=.5e050e6f-e2b6-42b2-8989-e600c2155b69@github.com>
 <6iVRP-20baz0_46SouR-dj9SyspR5QvaL9iJMdeipDE=.92688b4e-ebd3-4681-8e63-a4aee752c407@github.com>
 <JC0_ubSzxbFzy4T-z8R7yYRWEe1fp-e4NgkziP44_s4=.b3344b27-cfce-4d28-9bcd-ca2c60db615b@github.com>
 <Ex2LM49zd4hKTYl845sEPpuaMwVaWPF-5FyCqSXWwPI=.74d61f86-3233-4a3d-8366-0f79d268f0f0@github.com>
 <i-_AwXR1i7_kNp-pYUv_PDLf_ptToMAWdkGape6MQZ8=.aab7bb15-462b-4ab8-a13a-4df9aea1d757@github.com>
 <_XaA5cQEInPMn5Q5gj2y7AFCRprFQiYfI6BeUN49FhA=.9f17ae05-b37e-4f40-a83f-fd34aa812575@github.com>
 <PFzznwIPYp2kFR5kXp6vLivLAtm6GJEihlOm6rljZsA=.a5de51e3-d595-46c0-83b6-dbd0e423ad2d@github.com>
 <VGBa5FHWmNaLG-br9EHoNhrmIF3OOcGUap0gT-zkInw=.10084e0a-f039-4971-8eaa-7a3ca7483191@github.com>
 <O2esolxx74O36BQBaFpkYmP75lWzuw102DznqHyPVBU=.b3a8fa4b-5bd3-479b-a2db-18760a879964@github.com>
Message-ID: <ttUZJU3UUQaKzaw1ne5Ivk_C4X32Cvs_g32GflopXas=.740c6192-bbf2-4734-84bc-380c0d5406ef@github.com>

On Fri, 9 Oct 2020 06:05:56 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> 
>>> Could you explain how the choice between SysV and mmap is made on AIX? It looks like
>>> 
>>> ```
>>> develop(uintx, Use64KPagesThreshold, 0,                                           \
>>>           "4K/64K page allocation threshold.")                                      \
>>> ...
>>>   if (os::vm_page_size() == 4*K) {
>>>     return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
>>>   } else {
>>>     if (bytes >= Use64KPagesThreshold) {
>>>       return reserve_shmated_memory(bytes, NULL /* requested_addr */);
>>>     } else {
>>>       return reserve_mmaped_memory(bytes, NULL /* requested_addr */);
>>>     }
>>>   }
>>> ```
>>> 
>>> (there only two calls to reserve_shmated_memory and both of them are like above. Is SysV SHM used in product builds?)
>>> For now, the AIX case looks a bit different. The choice is made by the platform and the shared code cannot control
>>> this. So yes, I cannot see how to avoid handle_t or similar.
>> 
>> On AIX we have 4K and 64K pages (actually more but those are interesting). 64K pages are desireable for larger areas
>> like heap. 64K pages can only be allocated with SystemV shared memory. mmap'ed memory is always 4K paged. But SystemV
>> shared mem has a number of disadvantages, like inability to protect the memory, and a large attach alignment (256M). So
>> it is cumbersome.  os::vm_page_size() on AIX is a fake. The hotspot code assumes that the underlying Operating System
>> has some sort of "base page size" (usually what is returned by sysconf(_SC_PAGESIZE)), and then optionally some sort of
>> huge page size which follows different rules (e.g. pinned). On Aix things are more fluid.   When investigating 64K page
>> support on AIX I decided eventually to fool hotspot into thinking that the base page size is 64k. Long story, this was
>> way before the OpenJDK existed and this was a propietary code base with no possibilty of changing things upstream.
>> Therefore os::vm_page_size returns 64K ("64K fake mode"). This can be disabled.  So above code fragment uses mmaped
>> memory if 64K fake mode is disabled, and if it is enabeld, it uses mmap for smaller regions and shmget for larger ones.
>>> 
>>> In contrast, THP and MAP_JIT are the way to implement a request from the shared code. Even for THP, shared code seems
>>> to know why it should "realign" (not sure why commit has an alignment_hint parameter, while it is possible to realign
>>> after a regular commit). I assume there is enough context in the shared code that can be provided for platform
>>> functions, without a handle_t. And the same context should anyway be provided to reserve function, so handle_t can be
>>> filled with all necessary information.
>> 
>> I believe the alignment hint and the TPH code had their roots in Solaris code. So its current form (I guess) is heavily
>> warped by history. A new implementation would maybe just have a "os::set_tph(start, size)" function and leave it at
>> that. And yes, I do not think it is necessary for os::commit to do this.  In fact, Linux could probably set TPH
>> unconditionally always when UseTransparentHugePages is active. That would alleviate the need for the alignment_hint
>> parameter and the realign function.  I opened https://bugs.openjdk.java.net/browse/JDK-8253890 to follow up on this.
>
> (more comments)
> 
>> Sorry, I had not highlighted that was a proof-of-concept patch to show API changes. I've pushed another PoC with
>> bookkeeping and no API changes at all. But I don't like the new one either.
> 
> Interesting idea, but IMHO too heavvy weight for a platform only change. Also GrowableArray maybe not the best choice
> here since e.g. it requires you to search twice on add. A better solution may be a specialized BST. If there are other
> uses for such a solution (managing memory regions, melting them together, splitting them maybe on remove) this would be
> worth a generic class. I believe NMT does something similar when managing virtual memory regions, see
> VirtualMemoryTracker and friends.
>> In the new patch, there is a list of (potentially) executable regions that is updated on commit, when the actual
>> desired (non)exec mode become known. If we support mixed exec/non-exec commits in a mapping, then after non-exec commit
>> a part of the mapping cannot be reversed to a potentially executable one (as we've lost MAP_JIT).
> 
> So once you cleared MAP_JIT from a region you cannot re-apply it? Then this is another reason we should not support
> setting and clearing exec on commit but only on a per-mapping base.
>> Then it can produce some unexpected results under _some_ conditions in runtime, while API users can be unconscious
>> about potential issues. Good API should not allow that.

Interestingly, if you look at https://github.com/openjdk/jdk/pull/49 (The new Alpine Linux port) it introduces a
function called check_pax().

Pax seems to be a switchable restriction of the Linux kernel which disallows setting a memory section executable after
it had been established. Another reason for making "exec" a property of the mapping itself and establish it at creation
time, and then never touch it again.

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

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

From zgu at openjdk.java.net  Fri Oct  9 13:35:15 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 9 Oct 2020 13:35:15 GMT
Subject: RFR: 8253857: Shenandoah: Bugs in ShenandoahEvacOOMHandler
 related code
In-Reply-To: <ZjIt8O9JJ5ByUcd12BmOrSa3XlJfrCzlIHD23cNnXeM=.77bc2fd8-659f-4884-9488-0d1064c9c7bd@github.com>
References: <6CF0xb8QBnk6It66Ov9BnSqv29SkjCWVwyFuUW8lEqQ=.77388807-557b-4bf2-b952-1675d473ddea@github.com>
 <ZjIt8O9JJ5ByUcd12BmOrSa3XlJfrCzlIHD23cNnXeM=.77bc2fd8-659f-4884-9488-0d1064c9c7bd@github.com>
Message-ID: <HHir37EgpZ6SnlYm0h0bwSICsXBVbOONxjHjl0OagDg=.9cd84d48-faee-4980-9e97-c90eb108cb66@github.com>

On Tue, 6 Oct 2020 12:55:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> There are a couple of bugs in ShenandoahEvacOOMHandler related code.
>> 
>> 1) ShenandoahEvacOOMHandler::register_thread()
>> It does not do OOM check before blindly cmpxchg in threads_in_evac. The cmpxchg can success even OOM is in progress,
>> that results the thread to continue evacuate objects.
>> 2) When a nested OOM scope encounters OOM, it does not decrease threads_in_evac count before entering
>> wait_for_no_evac_threads() loop, it deadlocks itself.
>> Test:
>> - [x] hotspot_gc_shenandoah on Linux x86_64
>
> src/hotspot/share/gc/shenandoah/shenandoahEvacOOMHandler.cpp line 58:
> 
>> 56:       return;
>> 57:     } else {
>> 58:       // Failure:
> 
> Don't we still need this block?

Yes, we do need to update threads_in_evac value for retry.

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

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

From rkennke at openjdk.java.net  Fri Oct  9 13:39:16 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 13:39:16 GMT
Subject: RFR: 8253857: Shenandoah: Bugs in ShenandoahEvacOOMHandler
 related code
In-Reply-To: <6CF0xb8QBnk6It66Ov9BnSqv29SkjCWVwyFuUW8lEqQ=.77388807-557b-4bf2-b952-1675d473ddea@github.com>
References: <6CF0xb8QBnk6It66Ov9BnSqv29SkjCWVwyFuUW8lEqQ=.77388807-557b-4bf2-b952-1675d473ddea@github.com>
Message-ID: <6STSokmLN_IjRRdNGe8TtmkVuvB9PsU38-6_ZpYJbpY=.11bb94c2-4e58-4863-a995-4c2d5819bc02@github.com>

On Wed, 30 Sep 2020 18:57:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There are a couple of bugs in ShenandoahEvacOOMHandler related code.
> 
> 1) ShenandoahEvacOOMHandler::register_thread()
> It does not do OOM check before blindly cmpxchg in threads_in_evac. The cmpxchg can success even OOM is in progress,
> that results the thread to continue evacuate objects.
> 2) When a nested OOM scope encounters OOM, it does not decrease threads_in_evac count before entering
> wait_for_no_evac_threads() loop, it deadlocks itself.
> Test:
> - [x] hotspot_gc_shenandoah on Linux x86_64

Looks good! Thanks!

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

Marked as reviewed by rkennke (Reviewer).

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

From zgu at openjdk.java.net  Fri Oct  9 13:47:13 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 9 Oct 2020 13:47:13 GMT
Subject: Integrated: 8253857: Shenandoah: Bugs in ShenandoahEvacOOMHandler
 related code
In-Reply-To: <6CF0xb8QBnk6It66Ov9BnSqv29SkjCWVwyFuUW8lEqQ=.77388807-557b-4bf2-b952-1675d473ddea@github.com>
References: <6CF0xb8QBnk6It66Ov9BnSqv29SkjCWVwyFuUW8lEqQ=.77388807-557b-4bf2-b952-1675d473ddea@github.com>
Message-ID: <L_MhQ6C7yBPRR9qplLxzgOEHw5I5vBAnkzabF-1ZBmc=.bb39a7df-1329-423e-b383-9633a91c3988@github.com>

On Wed, 30 Sep 2020 18:57:43 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> There are a couple of bugs in ShenandoahEvacOOMHandler related code.
> 
> 1) ShenandoahEvacOOMHandler::register_thread()
> It does not do OOM check before blindly cmpxchg in threads_in_evac. The cmpxchg can success even OOM is in progress,
> that results the thread to continue evacuate objects.
> 2) When a nested OOM scope encounters OOM, it does not decrease threads_in_evac count before entering
> wait_for_no_evac_threads() loop, it deadlocks itself.
> Test:
> - [x] hotspot_gc_shenandoah on Linux x86_64

This pull request has now been integrated.

Changeset: d4b5dfd1
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d4b5dfd1
Stats:     26 lines in 2 files changed: 8 ins; 7 del; 11 mod

8253857: Shenandoah: Bugs in ShenandoahEvacOOMHandler related code

Reviewed-by: rkennke

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

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

From pliden at openjdk.java.net  Fri Oct  9 14:10:19 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Fri, 9 Oct 2020 14:10:19 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <5SHfZCqDGmlAe76fFCuH_lgi3_vKh2Sp7_x3w7XLRDw=.75108d48-0443-4e7d-8e02-d165a852c55a@github.com>

On Mon, 5 Oct 2020 13:42:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> 8254315: Shenandoah: Concurrent weak reference processing

Hi @rkennke!

It looks like `shenandoahReferenceProcess.[ch]pp` is heavily based on `zReferenceProcessor.[ch]hpp`. When copying
non-trivial amounts of code from ZGC (or any other part of HotSpot), please retain the copyright notice of the original
work. Thanks!

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

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

From rkennke at openjdk.java.net  Fri Oct  9 14:10:19 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 14:10:19 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
Message-ID: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>

8254315: Shenandoah: Concurrent weak reference processing

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

Commit messages:
 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Add Oracle copyright header to shenandoahReferenceProcessor.[hc]pp due to its structural origins from its ZGC couterparts
 - Relax assert in reference processor to account no LRB in passive mode
 - Aarch64 support for concurrent weak references/extended native barriers
 - Perform reference-processing during full-GC and degenerated-GC
 - Relax during-evacuation verification to account for Reference referents that have not yet been cleared
 - Apply LRB when draining ref-proc discovered lists
 - Install softref policy at init-mark pause, not at conc-mark
 - Use native-LRBs for Reference.get() intrinsics
 - Implement correct strong and final marking; Fix liveness counting
 - ... and 18 more: https://git.openjdk.java.net/jdk/compare/c9d0407e...610cd75a

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254315
  Stats: 2278 lines in 52 files changed: 1534 ins; 565 del; 179 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Fri Oct  9 14:10:20 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 14:10:20 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
In-Reply-To: <5SHfZCqDGmlAe76fFCuH_lgi3_vKh2Sp7_x3w7XLRDw=.75108d48-0443-4e7d-8e02-d165a852c55a@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <5SHfZCqDGmlAe76fFCuH_lgi3_vKh2Sp7_x3w7XLRDw=.75108d48-0443-4e7d-8e02-d165a852c55a@github.com>
Message-ID: <paMFmeS8-dfuo5jwR01ae04IN1ehZYJxGjuIE_zhBOQ=.972216c4-ae1e-49d6-8a42-8786890d6552@github.com>

On Mon, 5 Oct 2020 19:01:04 GMT, Per Liden <pliden at openjdk.org> wrote:

> Hi @rkennke!
> 
> It looks like `shenandoahReferenceProcess.[ch]pp` is heavily based on `zReferenceProcessor.[ch]hpp`. When copying
> non-trivial amounts of code from ZGC (or any other part of HotSpot), please retain the copyright notice of the original
> work. Thanks!

Ok thanks for the notice. I will change it.

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

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

From rkennke at openjdk.java.net  Fri Oct  9 14:16:17 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 14:16:17 GMT
Subject: RFR: 8254314: Shenandoah: null checks in c2 should not skip over
 native load barrier
In-Reply-To: <BvrgX0rEtd-EDmZZMGpsaKsPtOz2OyMYR4t454HId_4=.b822f479-9a4e-4a88-9a4e-45e326e66a59@github.com>
References: <BvrgX0rEtd-EDmZZMGpsaKsPtOz2OyMYR4t454HId_4=.b822f479-9a4e-4a88-9a4e-45e326e66a59@github.com>
Message-ID: <Ibf8zOyNWDzLImGFaLo5zR5gfEt9RmVD0LH_80WBV6g=.25e829e3-948c-458f-9471-a337ebaade4a@github.com>

On Fri, 9 Oct 2020 14:03:21 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> C2 optimizes (CmpP (LoadBarrier o) NULL) as (CmpP o NULL). The ative
> load barrier is not guaranteed to return a non null oop when passed a
> non null oop so this optimization could lead to a crash.

It looks good to me! While this doesn't seem to reproduce with normal native-barriers yet, it's been a major headache
in the ongoing work on concurrent weak reference processing, and I don't see why normal native-barriers wouldn't be
affected by it. We've probably been lucky so far.

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

Marked as reviewed by rkennke (Reviewer).

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

From roland at openjdk.java.net  Fri Oct  9 14:16:17 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 9 Oct 2020 14:16:17 GMT
Subject: RFR: 8254314: Shenandoah: null checks in c2 should not skip over
 native load barrier
Message-ID: <BvrgX0rEtd-EDmZZMGpsaKsPtOz2OyMYR4t454HId_4=.b822f479-9a4e-4a88-9a4e-45e326e66a59@github.com>

C2 optimizes (CmpP (LoadBarrier o) NULL) as (CmpP o NULL). The ative
load barrier is not guaranteed to return a non null oop when passed a
non null oop so this optimization could lead to a crash.

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

Commit messages:
 - Shenandoah: null checks in c2 should not skip over native load barrier

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

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

From rkennke at openjdk.java.net  Fri Oct  9 14:29:23 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 14:29:23 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v2]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <2KYMyFiOAaqO6xL8GgIph5Sj6h-BBRni4-bHHcfSP7s=.9ec669f1-08e0-4043-a2f7-1e7f88fa3cff@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
> items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>   theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
> in Reference.get() intrinsics that return NULL when the referent is not reachable.

Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:

 - Add precompiled header to shenandoahMarkBitMap.cpp
 - Fix null-check after C2 native-LRB
 - Reinstate check for ShenandoahSelfFixing that got lost during the merge

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/610cd75a..ccdc9633

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

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

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

From rkennke at openjdk.java.net  Fri Oct  9 14:51:16 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 14:51:16 GMT
Subject: RFR: 8254319: Shenandoah: Interpreter native-LRB needs to activate
 during HAS_FORWARDED
Message-ID: <DlUd-FQAUM6H_bXD9WS-xwJK26NVG13a3NvdA8sqFQg=.1a985bd2-ec2e-4112-b915-6707bc2f937f@github.com>

We currently only activate native-LRB when EVACUATING, however we need it to activate during all of HAS_FORWARDED
because it may have to resolve the target.

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

Commit messages:
 - 8254319: Shenandoah: Interpreter native-LRB needs to activate during HAS_FORWARDED

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

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

From shade at openjdk.java.net  Fri Oct  9 14:56:20 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 9 Oct 2020 14:56:20 GMT
Subject: RFR: 8254319: Shenandoah: Interpreter native-LRB needs to
 activate during HAS_FORWARDED
In-Reply-To: <DlUd-FQAUM6H_bXD9WS-xwJK26NVG13a3NvdA8sqFQg=.1a985bd2-ec2e-4112-b915-6707bc2f937f@github.com>
References: <DlUd-FQAUM6H_bXD9WS-xwJK26NVG13a3NvdA8sqFQg=.1a985bd2-ec2e-4112-b915-6707bc2f937f@github.com>
Message-ID: <Z9v_PR_ruanQNg4BwHOpIqb_sxAlAUD2QLTcg6w8Fvo=.8011a562-5f6d-4900-a5a0-974215c4d1f2@github.com>

On Fri, 9 Oct 2020 14:44:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We currently only activate native-LRB when EVACUATING, however we need it to activate during all of HAS_FORWARDED
> because it may have to resolve the target.

Agreed. Looks good.

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

Marked as reviewed by shade (Reviewer).

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

From rkennke at openjdk.java.net  Fri Oct  9 15:24:22 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 15:24:22 GMT
Subject: RFR: 8254320: Shenandoah: C2 native LRB should activate for non-cset
 objects
Message-ID: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>

In C2 native-LRB, we don't call the slow-path when the reference is not in cset. However, it may need to return NULL
for non-cset objects too, in order to prevent accidental ressurrection of referenced object.

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

Commit messages:
 - 8254320: Shenandoah: C2 native LRB should activate for non-cset objects

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

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

From rkennke at openjdk.java.net  Fri Oct  9 17:03:24 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 17:03:24 GMT
Subject: RFR: 8254319: Shenandoah: Interpreter native-LRB needs to
 activate during HAS_FORWARDED [v2]
In-Reply-To: <DlUd-FQAUM6H_bXD9WS-xwJK26NVG13a3NvdA8sqFQg=.1a985bd2-ec2e-4112-b915-6707bc2f937f@github.com>
References: <DlUd-FQAUM6H_bXD9WS-xwJK26NVG13a3NvdA8sqFQg=.1a985bd2-ec2e-4112-b915-6707bc2f937f@github.com>
Message-ID: <0VDBIsRpXLo0bbd3mTbpZOFyXOmgT53kM1wXQjmkDLg=.0ba83815-28a4-4258-8ba8-2c867b14dac9@github.com>

> We currently only activate native-LRB when EVACUATING, however we need it to activate during all of HAS_FORWARDED
> because it may have to resolve the target.

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

 - Merge remote-tracking branch 'upstream/master' into 8254319
 - 8254319: Shenandoah: Interpreter native-LRB needs to activate during HAS_FORWARDED

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/579/files
  - new: https://git.openjdk.java.net/jdk/pull/579/files/f597a4fe..677ea4b8

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

  Stats: 1323 lines in 15 files changed: 1278 ins; 4 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/579.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/579/head:pull/579

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

From rkennke at openjdk.java.net  Fri Oct  9 17:04:26 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 17:04:26 GMT
Subject: RFR: 8254320: Shenandoah: C2 native LRB should activate for
 non-cset objects [v2]
In-Reply-To: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
References: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
Message-ID: <Qbgcpu3EBUPi5S-ldJagpCI8tUsVewNOfgn7bN0vHYs=.71fa3e06-41c8-451b-ab9e-60cf32462e4b@github.com>

> In C2 native-LRB, we don't call the slow-path when the reference is not in cset. However, it may need to return NULL
> for non-cset objects too, in order to prevent accidental ressurrection of referenced object.

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

 - Merge remote-tracking branch 'upstream/master' into 8254320
 - 8254320: Shenandoah: C2 native LRB should activate for non-cset objects

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/580/files
  - new: https://git.openjdk.java.net/jdk/pull/580/files/bd11f8b1..05b2bee3

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

  Stats: 1323 lines in 15 files changed: 1278 ins; 4 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/580.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/580/head:pull/580

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

From kbarrett at openjdk.java.net  Fri Oct  9 17:13:10 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Fri, 9 Oct 2020 17:13:10 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v2]
In-Reply-To: <2KYMyFiOAaqO6xL8GgIph5Sj6h-BBRni4-bHHcfSP7s=.9ec669f1-08e0-4043-a2f7-1e7f88fa3cff@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <2KYMyFiOAaqO6xL8GgIph5Sj6h-BBRni4-bHHcfSP7s=.9ec669f1-08e0-4043-a2f7-1e7f88fa3cff@github.com>
Message-ID: <Rv_Z06RiR_a1E3EYDqMGe3-5ot3ay6QDDay0OhIbcdk=.258b3c3c-04b1-4737-9aad-7fba84b3e1aa@github.com>

On Fri, 9 Oct 2020 14:29:23 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
>> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
>> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
>> items that contribute to pause time linear to number of references, or worse:
>> - We need to scan and consider each reference on the various 'discovered' lists.
>> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>>   theoretically only bounded by the live data set size.
>> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
>> 
>> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
>> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
>> The solution to this is two-fold:
>> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
>> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
>> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
>> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
>> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
>> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
>> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
>> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
>> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
>> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
>> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
>> in Reference.get() intrinsics that return NULL when the referent is not reachable.
>
> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Add precompiled header to shenandoahMarkBitMap.cpp
>  - Fix null-check after C2 native-LRB
>  - Reinstate check for ShenandoahSelfFixing that got lost during the merge

I only looked at the non-shenandoah changes.

src/hotspot/share/oops/instanceRefKlass.hpp line 61:

> 59:   InstanceRefKlass() { assert(DumpSharedSpaces || UseSharedSpaces, "only for CDS"); }
> 60:
> 61:   virtual bool is_instance_ref_klass()        const { return true; }

Don't make this change.  There already exists an idiom for testing for reference klasses.

k->is_instance_klass() && (InstanceKlass::cast(k)->reference_type() != REF_NONE)

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

Changes requested by kbarrett (Reviewer).

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

From rkennke at openjdk.java.net  Fri Oct  9 17:13:11 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 17:13:11 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v2]
In-Reply-To: <Rv_Z06RiR_a1E3EYDqMGe3-5ot3ay6QDDay0OhIbcdk=.258b3c3c-04b1-4737-9aad-7fba84b3e1aa@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <2KYMyFiOAaqO6xL8GgIph5Sj6h-BBRni4-bHHcfSP7s=.9ec669f1-08e0-4043-a2f7-1e7f88fa3cff@github.com>
 <Rv_Z06RiR_a1E3EYDqMGe3-5ot3ay6QDDay0OhIbcdk=.258b3c3c-04b1-4737-9aad-7fba84b3e1aa@github.com>
Message-ID: <pey5jd8gSbcNW2SX64ZfEFOunQKrOUpszTIGQ4Eu0r8=.8ba87ad8-a277-44ff-8d87-dd58ed1b4eef@github.com>

On Fri, 9 Oct 2020 17:07:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Add precompiled header to shenandoahMarkBitMap.cpp
>>  - Fix null-check after C2 native-LRB
>>  - Reinstate check for ShenandoahSelfFixing that got lost during the merge
>
> src/hotspot/share/oops/instanceRefKlass.hpp line 61:
> 
>> 59:   InstanceRefKlass() { assert(DumpSharedSpaces || UseSharedSpaces, "only for CDS"); }
>> 60:
>> 61:   virtual bool is_instance_ref_klass()        const { return true; }
> 
> Don't make this change.  There already exists an idiom for testing for reference klasses.
> 
> k->is_instance_klass() && (InstanceKlass::cast(k)->reference_type() != REF_NONE)

Thanks, Kim! I didn't actually intend to open this up for review, and have reverted it back to 'draft' status. Thank
you anyway for the suggestion: it is one of the things that I wanted to ask you guys about. I will make that change,
thank you!

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

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

From rkennke at openjdk.java.net  Fri Oct  9 17:33:19 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 17:33:19 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v3]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <q2CZj9t0jKxJWhZSNHxleVXpFtEfvARJoX5F6KlNsSo=.a356244f-53f7-4423-a2c4-47090757fe02@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
> items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>   theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
> in Reference.get() intrinsics that return NULL when the referent is not reachable.

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 33 commits:

 - Merge remote-tracking branch 'upstream/master' into shenandoah-concurrent-weakrefs
 - Use existing idiom for checking for intanceRefKlass, instead of introducing new code
 - Add precompiled header to shenandoahMarkBitMap.cpp
 - Fix null-check after C2 native-LRB
 - Reinstate check for ShenandoahSelfFixing that got lost during the merge
 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Add Oracle copyright header to shenandoahReferenceProcessor.[hc]pp due to its structural origins from its ZGC
   couterparts
 - Relax assert in reference processor to account no LRB in passive mode
 - Aarch64 support for concurrent weak references/extended native barriers
 - Perform reference-processing during full-GC and degenerated-GC
 - ... and 23 more: https://git.openjdk.java.net/jdk/compare/52e45a36...aaf8717f

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

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=02
  Stats: 2285 lines in 50 files changed: 1539 ins; 565 del; 181 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From zgu at openjdk.java.net  Fri Oct  9 17:45:13 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 9 Oct 2020 17:45:13 GMT
Subject: RFR: 8254319: Shenandoah: Interpreter native-LRB needs to
 activate during HAS_FORWARDED [v2]
In-Reply-To: <0VDBIsRpXLo0bbd3mTbpZOFyXOmgT53kM1wXQjmkDLg=.0ba83815-28a4-4258-8ba8-2c867b14dac9@github.com>
References: <DlUd-FQAUM6H_bXD9WS-xwJK26NVG13a3NvdA8sqFQg=.1a985bd2-ec2e-4112-b915-6707bc2f937f@github.com>
 <0VDBIsRpXLo0bbd3mTbpZOFyXOmgT53kM1wXQjmkDLg=.0ba83815-28a4-4258-8ba8-2c867b14dac9@github.com>
Message-ID: <K8gcazrPJNZiMls6PZOvoW3f0MOnKv91GqhL8Id3hxw=.c4cd76aa-6e96-4e44-8c1e-d2c94654adcf@github.com>

On Fri, 9 Oct 2020 17:03:24 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> We currently only activate native-LRB when EVACUATING, however we need it to activate during all of HAS_FORWARDED
>> because it may have to resolve the target.
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since
> the last revision:
>  - Merge remote-tracking branch 'upstream/master' into 8254319
>  - 8254319: Shenandoah: Interpreter native-LRB needs to activate during HAS_FORWARDED

Marked as reviewed by zgu (Reviewer).

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

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

From rkennke at openjdk.java.net  Fri Oct  9 19:10:10 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 19:10:10 GMT
Subject: Integrated: 8254319: Shenandoah: Interpreter native-LRB needs to
 activate during HAS_FORWARDED
In-Reply-To: <DlUd-FQAUM6H_bXD9WS-xwJK26NVG13a3NvdA8sqFQg=.1a985bd2-ec2e-4112-b915-6707bc2f937f@github.com>
References: <DlUd-FQAUM6H_bXD9WS-xwJK26NVG13a3NvdA8sqFQg=.1a985bd2-ec2e-4112-b915-6707bc2f937f@github.com>
Message-ID: <cQES4uUKRbrH6YPpH9gmEPp2wkfBmPsm4a92YutMqhs=.29a3537b-df2b-4cf8-a9fc-3ab0419414e4@github.com>

On Fri, 9 Oct 2020 14:44:40 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We currently only activate native-LRB when EVACUATING, however we need it to activate during all of HAS_FORWARDED
> because it may have to resolve the target.

This pull request has now been integrated.

Changeset: 536b35b5
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/536b35b5
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8254319: Shenandoah: Interpreter native-LRB needs to activate during HAS_FORWARDED

Reviewed-by: shade, zgu

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

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

From rkennke at openjdk.java.net  Fri Oct  9 21:32:24 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 9 Oct 2020 21:32:24 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v4]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <nYdNE_JasYG5WCzumOjF16rz9k-eCVTQS5GymSpb9yE=.425b78dd-53b5-4aa5-a696-21c09491bdca@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
> items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>   theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
> in Reference.get() intrinsics that return NULL when the referent is not reachable.

Roman Kennke has updated the pull request incrementally with five additional commits since the last revision:

 - Implement reference-processing statistics
 - Implement abandoning partial discovery. Remove unused methods.
 - Remove leftovers of precleaning
 - Remove unused is_access_on_jlr_reference() helper method
 - Invert weak/native condition in interpreter native-LRB for clarity

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/aaf8717f..179002db

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

  Stats: 159 lines in 17 files changed: 86 ins; 52 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Sat Oct 10 21:27:19 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Sat, 10 Oct 2020 21:27:19 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v5]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <ZZFEby8O0STMuw581CFkjHqIC4PYwH0-eyZzBNMWqJc=.8ff4ed9b-0424-4267-a7ed-9f306df1ca8e@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
> items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>   theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
> in Reference.get() intrinsics that return NULL when the referent is not reachable.

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 41 commits:

 - Merge remote-tracking branch 'upstream/master' into shenandoah-concurrent-weakrefs
 - Prevent double-discovery of references
 - Also abandon pending list when abandoning discovered lists
 - Implement reference-processing statistics
 - Implement abandoning partial discovery. Remove unused methods.
 - Remove leftovers of precleaning
 - Remove unused is_access_on_jlr_reference() helper method
 - Invert weak/native condition in interpreter native-LRB for clarity
 - Merge remote-tracking branch 'upstream/master' into shenandoah-concurrent-weakrefs
 - Use existing idiom for checking for intanceRefKlass, instead of introducing new code
 - ... and 31 more: https://git.openjdk.java.net/jdk/compare/cc52358c...da242318

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

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=04
  Stats: 2429 lines in 54 files changed: 1654 ins; 602 del; 173 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From shade at openjdk.java.net  Mon Oct 12 07:15:15 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Oct 2020 07:15:15 GMT
Subject: RFR: 8254560: Shenandoah: Concurrent Strong Roots logging is incorrect
Message-ID: <KkO_l39x_KHlAfL9CUBbVHjTLxZ0E7qwvWl88i_UN90=.162417e2-1b9c-4a03-a470-0798ba07ee6f@github.com>

Look:

[1382.171s][info][gc,stats] Concurrent Strong Roots            1059 us, parallelism: 2.12x
[1382.171s][info][gc,stats] Rendezvous                         2246 us
[1382.171s][info][gc,stats]   CSR: Code Cache Roots              84 us, workers (us):  14,  17,  13,  14,  10,   6,
4,   5,  [1382.171s][info][gc,stats]   CSR: VM Weak Roots               2162 us, workers (us): ---, ---, 905, ---, ---,
388, 383, 486,

There should be `CSR: <total>`, but `Rendezvous` is in its place.

Testing:
  - [x] Eyeballing `-Xlog:gc+stats` on Linux x86_64

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

Commit messages:
 - 8254560: Shenandoah: Concurrent Strong Roots logging is incorrect

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

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

From roland at openjdk.java.net  Mon Oct 12 07:25:10 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 12 Oct 2020 07:25:10 GMT
Subject: Integrated: 8254314: Shenandoah: null checks in c2 should not skip
 over native load barrier
In-Reply-To: <BvrgX0rEtd-EDmZZMGpsaKsPtOz2OyMYR4t454HId_4=.b822f479-9a4e-4a88-9a4e-45e326e66a59@github.com>
References: <BvrgX0rEtd-EDmZZMGpsaKsPtOz2OyMYR4t454HId_4=.b822f479-9a4e-4a88-9a4e-45e326e66a59@github.com>
Message-ID: <LKsPzXOuMmCq3P8iZGRmH9LP_xTRyf-9z1vzCYguMME=.d103d29c-92d4-4da3-97ab-29e943843a6c@github.com>

On Fri, 9 Oct 2020 14:03:21 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> C2 optimizes (CmpP (LoadBarrier o) NULL) as (CmpP o NULL). The ative
> load barrier is not guaranteed to return a non null oop when passed a
> non null oop so this optimization could lead to a crash.

This pull request has now been integrated.

Changeset: a2bb4c60
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a2bb4c60
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8254314: Shenandoah: null checks in c2 should not skip over native load barrier

Reviewed-by: rkennke

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

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

From roland at openjdk.java.net  Mon Oct 12 10:09:17 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 12 Oct 2020 10:09:17 GMT
Subject: RFR: 8254320: Shenandoah: C2 native LRB should activate for
 non-cset objects [v2]
In-Reply-To: <Qbgcpu3EBUPi5S-ldJagpCI8tUsVewNOfgn7bN0vHYs=.71fa3e06-41c8-451b-ab9e-60cf32462e4b@github.com>
References: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
 <Qbgcpu3EBUPi5S-ldJagpCI8tUsVewNOfgn7bN0vHYs=.71fa3e06-41c8-451b-ab9e-60cf32462e4b@github.com>
Message-ID: <k_Sv4lyE_PHWzBv5qVTTd6DnaijJkkFoown3DzGRUUM=.ed84952f-fbe8-44d1-bde6-86e5e574ada7@github.com>

On Fri, 9 Oct 2020 17:04:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In C2 native-LRB, we don't call the slow-path when the reference is not in cset. However, it may need to return NULL
>> for non-cset objects too, in order to prevent accidental ressurrection of referenced object.
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since
> the last revision:
>  - Merge remote-tracking branch 'upstream/master' into 8254320
>  - 8254320: Shenandoah: C2 native LRB should activate for non-cset objects

Looks good to me.

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

Marked as reviewed by roland (Reviewer).

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

From shade at openjdk.java.net  Mon Oct 12 10:36:12 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Oct 2020 10:36:12 GMT
Subject: Integrated: 8254560: Shenandoah: Concurrent Strong Roots logging is
 incorrect
In-Reply-To: <KkO_l39x_KHlAfL9CUBbVHjTLxZ0E7qwvWl88i_UN90=.162417e2-1b9c-4a03-a470-0798ba07ee6f@github.com>
References: <KkO_l39x_KHlAfL9CUBbVHjTLxZ0E7qwvWl88i_UN90=.162417e2-1b9c-4a03-a470-0798ba07ee6f@github.com>
Message-ID: <a3xF1-CzLJYUwA820ZW2f9qE2S6DenZaZ1c4UCTDOTs=.a6bf9904-9aa8-4a3f-89a6-bdff3ddf3904@github.com>

On Mon, 12 Oct 2020 07:10:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Look:
> 
> [1382.171s][info][gc,stats] Concurrent Strong Roots            1059 us, parallelism: 2.12x
> [1382.171s][info][gc,stats] Rendezvous                         2246 us
> [1382.171s][info][gc,stats]   CSR: Code Cache Roots              84 us, workers (us):  14,  17,  13,  14,  10,   6,
> 4,   5,  [1382.171s][info][gc,stats]   CSR: VM Weak Roots               2162 us, workers (us): ---, ---, 905, ---, ---,
> 388, 383, 486,
> There should be `CSR: <total>`, but `Rendezvous` is in its place.
> 
> Testing:
>   - [x] Eyeballing `-Xlog:gc+stats` on Linux x86_64

This pull request has now been integrated.

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

8254560: Shenandoah: Concurrent Strong Roots logging is incorrect

Reviewed-by: rkennke

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

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

From rkennke at openjdk.java.net  Mon Oct 12 10:36:11 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Oct 2020 10:36:11 GMT
Subject: RFR: 8254560: Shenandoah: Concurrent Strong Roots logging is
 incorrect
In-Reply-To: <KkO_l39x_KHlAfL9CUBbVHjTLxZ0E7qwvWl88i_UN90=.162417e2-1b9c-4a03-a470-0798ba07ee6f@github.com>
References: <KkO_l39x_KHlAfL9CUBbVHjTLxZ0E7qwvWl88i_UN90=.162417e2-1b9c-4a03-a470-0798ba07ee6f@github.com>
Message-ID: <W7pYOMn20S3olOogb15gZzvfxLWR3uiQGRp_6P8iUYo=.feba6185-b7b9-4d3a-bca4-4b46720ef743@github.com>

On Mon, 12 Oct 2020 07:10:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Look:
> 
> [1382.171s][info][gc,stats] Concurrent Strong Roots            1059 us, parallelism: 2.12x
> [1382.171s][info][gc,stats] Rendezvous                         2246 us
> [1382.171s][info][gc,stats]   CSR: Code Cache Roots              84 us, workers (us):  14,  17,  13,  14,  10,   6,
> 4,   5,  [1382.171s][info][gc,stats]   CSR: VM Weak Roots               2162 us, workers (us): ---, ---, 905, ---, ---,
> 388, 383, 486,
> There should be `CSR: <total>`, but `Rendezvous` is in its place.
> 
> Testing:
>   - [x] Eyeballing `-Xlog:gc+stats` on Linux x86_64

Looks good to me! Thanks!

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

Marked as reviewed by rkennke (Reviewer).

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

From shade at openjdk.java.net  Mon Oct 12 10:43:12 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Oct 2020 10:43:12 GMT
Subject: RFR: 8254320: Shenandoah: C2 native LRB should activate for
 non-cset objects [v2]
In-Reply-To: <Qbgcpu3EBUPi5S-ldJagpCI8tUsVewNOfgn7bN0vHYs=.71fa3e06-41c8-451b-ab9e-60cf32462e4b@github.com>
References: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
 <Qbgcpu3EBUPi5S-ldJagpCI8tUsVewNOfgn7bN0vHYs=.71fa3e06-41c8-451b-ab9e-60cf32462e4b@github.com>
Message-ID: <1hBwu7bcZZZgLTsDbsBEhQxjR_JuWeTr8Xxu-3LNjWI=.867dc88a-61b1-4945-a8c3-5a91223801f0@github.com>

On Fri, 9 Oct 2020 17:04:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In C2 native-LRB, we don't call the slow-path when the reference is not in cset. However, it may need to return NULL
>> for non-cset objects too, in order to prevent accidental ressurrection of referenced object.
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
> excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since
> the last revision:
>  - Merge remote-tracking branch 'upstream/master' into 8254320
>  - 8254320: Shenandoah: C2 native LRB should activate for non-cset objects

A minor documentation nit. Otherwise is fine.

src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 1345:

> 1343:     // Wires !in_cset(obj) to slot 2 of region and phis
> 1344:     Node* not_cset_ctrl = NULL;
> 1345:     if (!lrb->is_native()) {

I think it deserves a comment why LRB-native is special.

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

Marked as reviewed by shade (Reviewer).

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

From rkennke at openjdk.java.net  Mon Oct 12 10:51:16 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Oct 2020 10:51:16 GMT
Subject: RFR: 8254573: Shenandoah: Streamline/inline native-LRB entry point
Message-ID: <XxNcWR8b6WrCraR6qMUlTT9WCfAb0QfHFKFEIW0UuRE=.8f512919-9aed-44a8-86a2-041c910f4563@github.com>

We currently do several calls between the native-LRB entry point and the actual implementation, presumably to resolve
the templated versions. This can be simplified.

Testing: hotspot_gc_shenandoah

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

Commit messages:
 - 8254573: Shenandoah: Streamline/inline native-LRB entry point

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

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

From rkennke at openjdk.java.net  Mon Oct 12 10:57:25 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Oct 2020 10:57:25 GMT
Subject: RFR: 8254320: Shenandoah: C2 native LRB should activate for
 non-cset objects [v3]
In-Reply-To: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
References: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
Message-ID: <pU55eh0U4N49SQI2SlMVVW8OL2ByxJVM20tiMj-VYN0=.52aad640-f1ba-42af-b168-087f1dc854c7@github.com>

> In C2 native-LRB, we don't call the slow-path when the reference is not in cset. However, it may need to return NULL
> for non-cset objects too, in order to prevent accidental ressurrection of referenced object.

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Add comment why native-LRB doesn't need the cset-check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/580/files
  - new: https://git.openjdk.java.net/jdk/pull/580/files/05b2bee3..e5b1e89e

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

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

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

From shade at openjdk.java.net  Mon Oct 12 10:57:26 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Oct 2020 10:57:26 GMT
Subject: RFR: 8254320: Shenandoah: C2 native LRB should activate for
 non-cset objects [v3]
In-Reply-To: <pU55eh0U4N49SQI2SlMVVW8OL2ByxJVM20tiMj-VYN0=.52aad640-f1ba-42af-b168-087f1dc854c7@github.com>
References: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
 <pU55eh0U4N49SQI2SlMVVW8OL2ByxJVM20tiMj-VYN0=.52aad640-f1ba-42af-b168-087f1dc854c7@github.com>
Message-ID: <N8wDUxEEdg13GGGRLwn5o_Go6X42we6jnTVaUNF5QzI=.7bab650a-ae19-4164-93b4-1f127cf8d0b4@github.com>

On Mon, 12 Oct 2020 10:54:46 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In C2 native-LRB, we don't call the slow-path when the reference is not in cset. However, it may need to return NULL
>> for non-cset objects too, in order to prevent accidental ressurrection of referenced object.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment why native-LRB doesn't need the cset-check

Marked as reviewed by shade (Reviewer).

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

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

From rkennke at openjdk.java.net  Mon Oct 12 10:57:29 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Oct 2020 10:57:29 GMT
Subject: Integrated: 8254320: Shenandoah: C2 native LRB should activate for
 non-cset objects
In-Reply-To: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
References: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
Message-ID: <P3e9ouVfGReiS8U-wJl_snY0cv4Zbp7TPbE4BvB3k4o=.a1d9cc6c-a48e-442a-bf58-6740e598851e@github.com>

On Fri, 9 Oct 2020 15:19:18 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> In C2 native-LRB, we don't call the slow-path when the reference is not in cset. However, it may need to return NULL
> for non-cset objects too, in order to prevent accidental ressurrection of referenced object.

This pull request has now been integrated.

Changeset: dfe8ba60
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dfe8ba60
Stats:     10 lines in 1 file changed: 7 ins; 0 del; 3 mod

8254320: Shenandoah: C2 native LRB should activate for non-cset objects

Reviewed-by: roland, shade

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

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

From rkennke at openjdk.java.net  Mon Oct 12 10:57:28 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Oct 2020 10:57:28 GMT
Subject: RFR: 8254320: Shenandoah: C2 native LRB should activate for
 non-cset objects [v2]
In-Reply-To: <1hBwu7bcZZZgLTsDbsBEhQxjR_JuWeTr8Xxu-3LNjWI=.867dc88a-61b1-4945-a8c3-5a91223801f0@github.com>
References: <f7U4F-6NCIhyIZRB3GC6gOdTocQ5SwYAwod4LPT6HSI=.b910dfd0-0cf4-4376-8943-a980ee5e8987@github.com>
 <Qbgcpu3EBUPi5S-ldJagpCI8tUsVewNOfgn7bN0vHYs=.71fa3e06-41c8-451b-ab9e-60cf32462e4b@github.com>
 <1hBwu7bcZZZgLTsDbsBEhQxjR_JuWeTr8Xxu-3LNjWI=.867dc88a-61b1-4945-a8c3-5a91223801f0@github.com>
Message-ID: <A3Pk4mIinjY-Nhf2cav3bUEQC4mrbscWV36oT36Jvj8=.57f6d477-d555-4835-8fd2-a0eceb9b99a9@github.com>

On Mon, 12 Oct 2020 10:38:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev
>> excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since
>> the last revision:
>>  - Merge remote-tracking branch 'upstream/master' into 8254320
>>  - 8254320: Shenandoah: C2 native LRB should activate for non-cset objects
>
> src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 1345:
> 
>> 1343:     // Wires !in_cset(obj) to slot 2 of region and phis
>> 1344:     Node* not_cset_ctrl = NULL;
>> 1345:     if (!lrb->is_native()) {
> 
> I think it deserves a comment why LRB-native is special.

Yup, I added a comment there. Thanks!

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

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

From shade at openjdk.java.net  Mon Oct 12 11:10:15 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 12 Oct 2020 11:10:15 GMT
Subject: RFR: 8254573: Shenandoah: Streamline/inline native-LRB entry point
In-Reply-To: <XxNcWR8b6WrCraR6qMUlTT9WCfAb0QfHFKFEIW0UuRE=.8f512919-9aed-44a8-86a2-041c910f4563@github.com>
References: <XxNcWR8b6WrCraR6qMUlTT9WCfAb0QfHFKFEIW0UuRE=.8f512919-9aed-44a8-86a2-041c910f4563@github.com>
Message-ID: <8m20dRQSO3wPiFwYI9DsK7mRBDbuWppC-4tWVlNqNgI=.032a7c30-7f96-42b3-ac2b-3efa65472e4d@github.com>

On Mon, 12 Oct 2020 10:45:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We currently do several calls between the native-LRB entry point and the actual implementation, presumably to resolve
> the templated versions. This can be simplified.
> Testing: hotspot_gc_shenandoah

This looks fine. I think it was this way because JRT_LEAF had opinions about templated methods. But I see there is the
same thing happens for `SBS::load_reference_barrier_mutator`, so it should be fine.

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

Marked as reviewed by shade (Reviewer).

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

From rkennke at openjdk.java.net  Mon Oct 12 11:32:12 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Oct 2020 11:32:12 GMT
Subject: Integrated: 8254573: Shenandoah: Streamline/inline native-LRB entry
 point
In-Reply-To: <XxNcWR8b6WrCraR6qMUlTT9WCfAb0QfHFKFEIW0UuRE=.8f512919-9aed-44a8-86a2-041c910f4563@github.com>
References: <XxNcWR8b6WrCraR6qMUlTT9WCfAb0QfHFKFEIW0UuRE=.8f512919-9aed-44a8-86a2-041c910f4563@github.com>
Message-ID: <Z4ss3dgCwGRVQ-oF-p7x00lLeV-40W9E8xrhA-76cww=.dc160bfc-a552-42ba-8dd0-9555ccbfc40e@github.com>

On Mon, 12 Oct 2020 10:45:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> We currently do several calls between the native-LRB entry point and the actual implementation, presumably to resolve
> the templated versions. This can be simplified.
> Testing: hotspot_gc_shenandoah

This pull request has now been integrated.

Changeset: 6620b617
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6620b617
Stats:     63 lines in 3 files changed: 25 ins; 36 del; 2 mod

8254573: Shenandoah: Streamline/inline native-LRB entry point

Reviewed-by: shade

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

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

From rkennke at openjdk.java.net  Mon Oct 12 12:21:21 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Oct 2020 12:21:21 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v6]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <ggFDbF75DL0zyrOi1yGYC_fdC0HsXUELCzOH1SvvFhQ=.e17befee-029f-4312-ae83-6deef0eda7f4@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
> items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>   theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
> in Reference.get() intrinsics that return NULL when the referent is not reachable.  Testing: hotspot_gc_shenadoah
> (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now
contains 44 commits:

 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Add documentation to ShenandoahReferenceProcessor
 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Merge remote-tracking branch 'upstream/master' into shenandoah-concurrent-weakrefs
 - Prevent double-discovery of references
 - Also abandon pending list when abandoning discovered lists
 - Implement reference-processing statistics
 - Implement abandoning partial discovery. Remove unused methods.
 - Remove leftovers of precleaning
 - Remove unused is_access_on_jlr_reference() helper method
 - ... and 34 more: https://git.openjdk.java.net/jdk/compare/05459df0...070fd836

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

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=05
  Stats: 2400 lines in 54 files changed: 1661 ins; 567 del; 172 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Mon Oct 12 12:34:25 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Oct 2020 12:34:25 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v7]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <oVtIWKQ2oeywIk0kL05epgYHC-BCcMvm6BcWSZQdHiw=.77396fad-2db7-4cd0-adf4-5d51c2b89cbf@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
> items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>   theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
> in Reference.get() intrinsics that return NULL when the referent is not reachable.  Testing: hotspot_gc_shenadoah
> (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Don't mark through a Reference that's already been discovered

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/070fd836..34ca4991

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=05-06

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

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

From rkennke at openjdk.java.net  Mon Oct 12 23:01:24 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 12 Oct 2020 23:01:24 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v8]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <JFtu4YXeNj7iDHpni1g-xVfXY_-XEFfEKmC0nwVxdD4=.756f8fb9-7d0b-49c3-b9e7-8dc7d6521b45@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
> items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>   theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
> in Reference.get() intrinsics that return NULL when the referent is not reachable.  Testing: hotspot_gc_shenadoah
> (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions

Roman Kennke has updated the pull request incrementally with four additional commits since the last revision:

 - Remove unnecessary par_is_marked* methods
 - Carry precise liveness and reachability information in ObjArrayChunkTask
 - Don't allow safepoints when acquiring the Heap_lock for reference enqueuing
 - Don't LRB when fetching the referent: we must avoid accidentally making finalizably reachable objects strongly reachable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/34ca4991..ee7412e2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=06-07

  Stats: 146 lines in 9 files changed: 21 ins; 96 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Tue Oct 13 14:30:30 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 13 Oct 2020 14:30:30 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v9]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <eZRBphqhYyVEILQudcK1YN87L6ppr4mpVKT6iHRvjj8=.da8011ff-c4cb-4169-abef-f1a80b9020d1@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
> items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>   theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
> in Reference.get() intrinsics that return NULL when the referent is not reachable.  Testing: hotspot_gc_shenadoah
> (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions

Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:

 - Explicitely use concurrent vs stw reference processing, don't rely on is_at_shenandoah_safepoint()
 - Exclude Shenandoah from TestSoftReferencesBehaviorOnOOME.java, it doesn't play with concurrent reference processing
 - Remove wrong assert from ShenandoahReferenceProcessor

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/ee7412e2..2c4b1cbd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=07-08

  Stats: 17 lines in 5 files changed: 6 ins; 2 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Wed Oct 14 14:32:28 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 14 Oct 2020 14:32:28 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v10]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <5LY7Ty5Q2S8j9S30uXyeX0EE8AQWQ4BFFd02NYMzVio=.2e423faa-895a-42c9-ad9f-6c85844e1ff8@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference
> and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads
> that make heavvy use of such weak references will therefore potentially cause significant GC pauses.  There are 3 main
> items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is
>   theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly
> reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking
> bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever
> marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all
> objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it
> will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter
> of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for
> FinalReference, marking stops there, and does not mark through the referent. 2. Concurrent processing is performed
> after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and
> depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list
> (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no
> referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers
> in Reference.get() intrinsics that return NULL when the referent is not reachable.  Testing: hotspot_gc_shenadoah
> (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2 with -XX:+UseShenandoahGC without
> regressions

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Add fallback support for new properties in ObjArrayChunkedTask
 - Fix 32bit interpreter LRB-native call

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/2c4b1cbd..46dc1b75

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=08-09

  Stats: 20 lines in 3 files changed: 6 ins; 2 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From vlivanov at openjdk.java.net  Mon Oct 19 20:40:23 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Mon, 19 Oct 2020 20:40:23 GMT
Subject: RFR: 8255000: C2: Unify IGVN processing when loop opts are over
Message-ID: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>

There is a number of use cases when ideal nodes (either individual or even the whole classes) delay some
transformations until loop optimizations are over.

Unfortunately, there are multiple solutions in the code base with their pros and cons: either a custom per-node class
logic (e.g., for range check dependent `CastII` or `Opaque4` nodes) or `Compile::major_progress() == 0` as a signal
that loop opts are over.

I propose to introduce a unified approach to reliably process nodes that require (or may benefit from) IGVN pass once
loop opts are finally over and migrate existing use cases to it.

After some experimentation, I decided not to rely on `Compile::major_progress()` because:
  * it's hard to reason about its properties (there are many places where it is adjusted);
  * attempts to verify its monotonicity using asserts triggered too many sporadic failures.

So, I wasn't persuaded that `Compile::major_progress() == 0` is reliable enough and introduced a dedicated flag
(`Compile::post_loop_opts_phase()`) which signals that loop opts are over.

(The patch - 69a93d4 commit - is on top of 8255026 cleanup which is reviewed separately.)

Testing: tier1-tier5

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

Commit messages:
 - Unify post loop opts IGVN
 - 8255026: C2: Miscellaneous cleanups in Compile and PhaseIdealLoop code

Changes: https://git.openjdk.java.net/jdk/pull/751/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=751&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255000
  Stats: 451 lines in 15 files changed: 111 ins; 156 del; 184 mod
  Patch: https://git.openjdk.java.net/jdk/pull/751.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/751/head:pull/751

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

From psadhukhan at openjdk.java.net  Tue Oct 20 12:00:25 2020
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 20 Oct 2020 12:00:25 GMT
Subject: git: openjdk/shenandoah: master: 105 new changesets
Message-ID: <a21d5cec-0e82-4beb-a794-3d1292d750af@openjdk.org>

Changeset: 6fe209b5
Author:    Per Liden <pliden at openjdk.org>
Date:      2020-10-13 13:40:50 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/6fe209b5

8254671: ZGC: Remove unused roots iterator types

Reviewed-by: stefank

! src/hotspot/share/gc/z/zRootsIterator.cpp
! src/hotspot/share/gc/z/zRootsIterator.hpp

Changeset: 65393a09
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2020-10-13 14:22:11 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/65393a09

8229867: Re-examine synchronization usages in http and https protocol handlers

Reviewed-by: chegar, alanb, michaelm

! src/java.base/share/classes/sun/net/www/MessageHeader.java
! src/java.base/share/classes/sun/net/www/MeteredStream.java
! src/java.base/share/classes/sun/net/www/http/ChunkedInputStream.java
! src/java.base/share/classes/sun/net/www/http/ChunkedOutputStream.java
! src/java.base/share/classes/sun/net/www/http/HttpCapture.java
! src/java.base/share/classes/sun/net/www/http/HttpClient.java
! src/java.base/share/classes/sun/net/www/http/KeepAliveCache.java
! src/java.base/share/classes/sun/net/www/http/KeepAliveStream.java
! src/java.base/share/classes/sun/net/www/http/KeepAliveStreamCleaner.java
! src/java.base/share/classes/sun/net/www/protocol/http/AuthCacheImpl.java
! src/java.base/share/classes/sun/net/www/protocol/http/AuthenticationInfo.java
! src/java.base/share/classes/sun/net/www/protocol/http/BasicAuthentication.java
! src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
! src/java.base/share/classes/sun/net/www/protocol/http/HttpURLConnection.java
! src/java.base/share/classes/sun/net/www/protocol/http/NegotiateAuthentication.java
! src/java.base/share/classes/sun/net/www/protocol/https/HttpsClient.java
! src/java.base/unix/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java
! src/java.base/windows/classes/sun/net/www/protocol/http/ntlm/NTLMAuthentication.java

Changeset: 02d9c291
Author:    Per Liden <pliden at openjdk.org>
Date:      2020-10-13 15:36:23 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/02d9c291

8254672: ZGC: ZParallelOopsDo/ZSerialWeakOopsDo should use atomic load/store

Reviewed-by: stefank

! src/hotspot/share/gc/z/zRootsIterator.cpp

Changeset: 3fb2e822
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2020-10-13 16:22:52 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/3fb2e822

8254627: Cleanup {Abstract,Single,Split}IndexWriter classes

Reviewed-by: hannesw

- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
+ src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SingleIndexWriter.java
- src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SplitIndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/TagletWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlStyle.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DocPaths.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java
! test/langtools/jdk/javadoc/doclet/testSearch/TestSearch.java
! test/langtools/jdk/javadoc/tool/CheckResourceKeys.java

Changeset: 6ed4c89d
Author:    Daniel Fuchs <dfuchs at openjdk.org>
Date:      2020-10-13 16:53:40 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/6ed4c89d

8254704: Add missing @since tag to BodyPublishers::concat

Reviewed-by: chegar

! src/java.net.http/share/classes/java/net/http/HttpRequest.java

Changeset: ba24f963
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
Date:      2020-10-13 17:08:47 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/ba24f963

8251861: Remove unused jdk.internal.ref.SoftCleanable and WeakCleanable

Reviewed-by: mchung, rriggs

! src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java
- src/java.base/share/classes/jdk/internal/ref/SoftCleanable.java
- src/java.base/share/classes/jdk/internal/ref/WeakCleanable.java
! test/jdk/java/lang/ref/CleanerTest.java

Changeset: 715e24af
Author:    Ludovic Henry <luhenry at openjdk.org>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2020-10-13 17:28:41 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/715e24af

8254311: Incorrect statements in createWindowsDevkit2017.sh

Reviewed-by: erikj, thartmann

! make/devkit/createWindowsDevkit2017.sh

Changeset: ba5dc67a
Author:    Coleen Phillimore <coleenp at openjdk.org>
Date:      2020-10-13 20:42:34 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/ba5dc67a

8254158: Consolidate per-platform stack overflow handling code

Reviewed-by: fparain, hseigel

! src/hotspot/os/linux/os_linux.hpp
! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os/posix/os_posix.hpp
! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp
! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp
! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp
! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp
! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp
! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp
! src/hotspot/share/runtime/os.hpp

Changeset: d50e0de8
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2020-10-14 03:09:01 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/d50e0de8

8254722: bsd_zero builds broken after JDK-8253717

Reviewed-by: dholmes

! src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp

Changeset: a0980373
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2020-10-14 04:59:52 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/a0980373

8254365: ciMethod.hpp should not include methodHandles.hpp

Reviewed-by: dholmes, coleenp

! src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp
! src/hotspot/cpu/arm/sharedRuntime_arm.cpp
! src/hotspot/cpu/ppc/sharedRuntime_ppc.cpp
! src/hotspot/cpu/s390/sharedRuntime_s390.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_32.cpp
! src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp
! src/hotspot/share/ci/ciEnv.cpp
! src/hotspot/share/ci/ciEnv.hpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/ci/ciSymbol.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/code/nmethod.cpp
! src/hotspot/share/interpreter/interpreterRuntime.cpp
! src/hotspot/share/jvmci/jvmciCodeInstaller.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/opto/doCall.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/java.cpp
! src/hotspot/share/runtime/vframeArray.cpp

Changeset: 31d9b7fe
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2020-10-14 07:26:13 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/31d9b7fe

8254252: Generic arraycopy stub overwrites callee-save rdi register on 64-bit Windows

Reviewed-by: kvn, chagedorn

! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp

Changeset: 9fe9b24b
Author:    Roberto Casta?eda Lozano <roberto.castaneda.lozano at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2020-10-14 08:06:59 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/9fe9b24b

8254575: C2: Clean up unused TRACK_PHI_INPUTS assertion code

Remove assertion code that was disabled in all build configurations.

Co-authored-by: Vladimir Ivanov <vlivanov at openjdk.org>
Reviewed-by: vlivanov, kvn

! src/hotspot/share/opto/gcm.cpp

Changeset: b509e31e
Author:    Roberto Casta?eda Lozano <roberto.castaneda.lozano at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2020-10-14 08:07:59 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/b509e31e

8254602: compiler/debug/TestStressCM.java failed with "RuntimeException: got the same optimization stats for different seeds: expected 45"

Remove test assertion checking that different random seeds lead to different
code motion decisions. This was the case for the specific pair of random seeds,
IR fed to code motion, and target platforms tested originally; but does not need
to hold in general. Remove similar test assertion in IGVN randomization test
case. Re-enable the test case.

Reviewed-by: shade, kvn

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/compiler/debug/TestStressCM.java
! test/hotspot/jtreg/compiler/debug/TestStressIGVN.java

Changeset: 9eeeb8a2
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2020-10-14 08:17:13 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/9eeeb8a2

8254696: safepointMechanism_aix needs adaptation for JDK-8253180

Reviewed-by: dholmes, clanger

! src/hotspot/os/aix/safepointMechanism_aix.cpp

Changeset: dc262dfc
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2020-10-14 09:37:54 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/dc262dfc

8212218: [TESTBUG] runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryErrorInMetaspace.java timed out

Reviewed-by: iklam, lmesnik

! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java

Changeset: db9dcdf1
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2020-10-14 10:29:15 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/db9dcdf1

8254668: JVMTI process frames on thread without started processing

Reviewed-by: eosterlund, rrich

! src/hotspot/share/prims/jvmtiEnv.cpp
! src/hotspot/share/prims/jvmtiEnvBase.cpp
! src/hotspot/share/prims/jvmtiEnvBase.hpp

Changeset: ba140b0f
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2020-10-14 11:21:38 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/ba140b0f

8254748: Bad Copyright header format after JDK-8212218

Reviewed-by: shade, dholmes

! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java

Changeset: 95e68c63
Author:    Harold Seigel <hseigel at openjdk.org>
Date:      2020-10-14 12:23:09 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/95e68c63

8254586: Replace fthrow() calls with simpler method calls in classFileParser.cpp

Reviewed-by: lfoltan, dholmes, coleenp

! src/hotspot/share/classfile/classFileError.cpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/classFileParser.hpp

Changeset: f71e8a61
Author:    Jason Tatton (AWS) <jptatton at amazon.com>
Committer: Paul Hohensee <phh at openjdk.org>
Date:      2020-10-14 12:58:21 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/f71e8a61

8173585: Intrinsify StringLatin1.indexOf(char)

Reviewed-by: neliasso

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp
! src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/intrinsicnode.hpp
! src/hotspot/share/opto/library_call.cpp
! src/java.base/share/classes/java/lang/StringLatin1.java
+ test/hotspot/jtreg/compiler/intrinsics/string/TestStringLatin1IndexOfChar.java
+ test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java

Changeset: 738effad
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2020-10-14 13:21:07 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/738effad

8254744: Clean-up CodeBlob::align_code_offset

Reviewed-by: mdoerr, eosterlund

! src/hotspot/share/code/codeBlob.cpp
! src/hotspot/share/memory/heap.cpp
! src/hotspot/share/memory/heap.hpp

Changeset: a6a38135
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2020-10-14 14:11:16 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/a6a38135

8254761: Wrong intrinsic annotation used for StringLatin1.indexOfChar

Reviewed-by: alanb

! src/java.base/share/classes/java/lang/StringLatin1.java

Changeset: 96a1f08e
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2020-10-14 15:25:43 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/96a1f08e

8254775: Microbenchmark StringIndexOfChar doesn't compile

Reviewed-by: rriggs

! test/micro/org/openjdk/bench/java/lang/StringIndexOfChar.java

Changeset: fde02e23
Author:    Yumin Qi <minqi at openjdk.org>
Date:      2020-10-14 17:13:27 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/fde02e23

8254012: NMT: MetaspaceSnapshot::snapshot uses wrong enum

Reviewed-by: stuefe, rrich

! src/hotspot/share/services/virtualMemoryTracker.cpp

Changeset: b7daf842
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2020-10-14 17:46:36 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/b7daf842

8254345: com/sun/jdi/JdwpAttachTest.java reports error incorrectly

Reviewed-by: cjplummer, sspitsyn

! test/jdk/com/sun/jdi/JdwpAttachTest.java

Changeset: cd33abb1
Author:    Alex Menkov <amenkov at openjdk.org>
Date:      2020-10-14 17:49:42 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/cd33abb1

8249623: test @ignore-d due to 7013634 should be returned back to execution

Reviewed-by: cjplummer, sspitsyn

! test/hotspot/jtreg/ProblemList.txt
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/ResourceExhausted/resexhausted002.java

Changeset: 386e7e8b
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2020-10-14 19:07:53 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/386e7e8b

8254789: ProblemList compiler/graalunit/HotspotTest.java

Reviewed-by: rriggs, iignatyev, kvn

! test/hotspot/jtreg/ProblemList-graal.txt

Changeset: 0c99b192
Author:    Paul Sandoz <psandoz at openjdk.org>
Date:      2020-10-14 20:02:46 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/0c99b192

8223347: Integration of Vector API (Incubator)

Co-authored-by: Vivek Deshpande <vdeshpande at openjdk.org>
Co-authored-by: Qi Feng <qfeng at openjdk.org>
Co-authored-by: Ian Graves <igraves at openjdk.org>
Co-authored-by: Jean-Philippe Halimi <jphalimi at openjdk.org>
Co-authored-by: Vladimir Ivanov <vlivanov at openjdk.org>
Co-authored-by: Ningsheng Jian <njian at openjdk.org>
Co-authored-by: Razvan Lupusoru <rlupusoru at openjdk.org>
Co-authored-by: Smita Kamath <svkamath at openjdk.org>
Co-authored-by: Rahul Kandu <rkandu at openjdk.org>
Co-authored-by: Kishor Kharbas <kkharbas at openjdk.org>
Co-authored-by: Eric Liu <Eric.Liu2 at arm.com>
Co-authored-by: Aaloan Miftah <someusername3 at gmail.com>
Co-authored-by: John R Rose <jrose at openjdk.org>
Co-authored-by: Shravya Rukmannagari <srukmannagar at openjdk.org>
Co-authored-by: Paul Sandoz <psandoz at openjdk.org>
Co-authored-by: Sandhya Viswanathan <sviswanathan at openjdk.org>
Co-authored-by: Lauren Walkowski <lauren.walkowski at arm.com>
Co-authored-by: Yang Zang <Yang.Zhang at arm.com>
Co-authored-by: Joshua Zhu <jzhu at openjdk.org>
Co-authored-by: Wang Zhuo <wzhuo at openjdk.org>
Co-authored-by: Jatin Bhateja <jbhateja at openjdk.org>
Reviewed-by: erikj, chegar, kvn, darcy, forax, briangoetz, aph, epavlova, coleenp

! make/common/Modules.gmk
! make/hotspot/gensrc/GensrcAdlc.gmk
! make/jdk/src/classes/build/tools/spp/Spp.java
! src/hotspot/cpu/aarch64/aarch64-asmtest.py
! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/aarch64/aarch64_ad.m4
+ src/hotspot/cpu/aarch64/aarch64_neon.ad
+ src/hotspot/cpu/aarch64/aarch64_neon_ad.m4
! src/hotspot/cpu/aarch64/assembler_aarch64.cpp
! src/hotspot/cpu/aarch64/assembler_aarch64.hpp
! src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp
! src/hotspot/cpu/aarch64/stubRoutines_aarch64.cpp
! src/hotspot/cpu/aarch64/stubRoutines_aarch64.hpp
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/x86/assembler_x86.cpp
! src/hotspot/cpu/x86/assembler_x86.hpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp
! src/hotspot/cpu/x86/c2_MacroAssembler_x86.hpp
! src/hotspot/cpu/x86/macroAssembler_x86.cpp
! src/hotspot/cpu/x86/macroAssembler_x86.hpp
! src/hotspot/cpu/x86/stubGenerator_x86_32.cpp
! src/hotspot/cpu/x86/stubGenerator_x86_64.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.cpp
! src/hotspot/cpu/x86/stubRoutines_x86.hpp
! src/hotspot/cpu/x86/x86.ad
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/forms.cpp
! src/hotspot/share/adlc/formssel.cpp
! src/hotspot/share/ci/ciField.cpp
! src/hotspot/share/ci/ciMethod.cpp
! src/hotspot/share/ci/ciMethod.hpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/modules.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/code/debugInfo.hpp
! src/hotspot/share/code/location.hpp
! src/hotspot/share/opto/addnode.hpp
! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/c2compiler.cpp
! src/hotspot/share/opto/callGenerator.cpp
! src/hotspot/share/opto/callGenerator.hpp
! src/hotspot/share/opto/castnode.cpp
! src/hotspot/share/opto/cfgnode.cpp
! src/hotspot/share/opto/classes.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/compile.hpp
! src/hotspot/share/opto/doCall.cpp
! src/hotspot/share/opto/lcm.cpp
! src/hotspot/share/opto/library_call.cpp
+ src/hotspot/share/opto/library_call.hpp
! src/hotspot/share/opto/matcher.cpp
! src/hotspot/share/opto/matcher.hpp
! src/hotspot/share/opto/memnode.cpp
! src/hotspot/share/opto/movenode.cpp
! src/hotspot/share/opto/movenode.hpp
! src/hotspot/share/opto/mulnode.hpp
! src/hotspot/share/opto/node.hpp
! src/hotspot/share/opto/output.cpp
! src/hotspot/share/opto/phase.cpp
! src/hotspot/share/opto/phase.hpp
! src/hotspot/share/opto/phasetype.hpp
! src/hotspot/share/opto/subnode.hpp
! src/hotspot/share/opto/superword.cpp
! src/hotspot/share/opto/type.cpp
! src/hotspot/share/opto/type.hpp
+ src/hotspot/share/opto/vector.cpp
+ src/hotspot/share/opto/vector.hpp
+ src/hotspot/share/opto/vectorIntrinsics.cpp
! src/hotspot/share/opto/vectornode.cpp
! src/hotspot/share/opto/vectornode.hpp
! src/hotspot/share/prims/nativeLookup.cpp
+ src/hotspot/share/prims/vectorSupport.cpp
+ src/hotspot/share/prims/vectorSupport.hpp
! src/hotspot/share/runtime/arguments.cpp
! src/hotspot/share/runtime/deoptimization.cpp
! src/hotspot/share/runtime/stackValue.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/utilities/globalDefinitions.hpp
+ src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java
! src/java.base/share/classes/module-info.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractShuffle.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte256Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte512Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte64Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteMaxVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double128Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double256Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double512Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Double64Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleMaxVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float128Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float256Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float512Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float64Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatMaxVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int128Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int256Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int512Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Int64Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntMaxVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/IntVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long128Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long256Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long512Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Long64Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongMaxVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LongVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short128Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short256Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short512Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Short64Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortMaxVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorIntrinsics.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMask.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShuffle.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorSpecies.java
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-Vector.java.template
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/X-VectorBits.java.template
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/gen-src.sh
+ src/jdk.incubator.vector/share/classes/jdk/incubator/vector/package-info.java
+ src/jdk.incubator.vector/share/classes/module-info.java
! src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot.test/src/org/graalvm/compiler/hotspot/test/CheckGraalIntrinsics.java
! test/jdk/TEST.groups
+ test/jdk/jdk/incubator/vector/AbstractVectorConversionTest.java
+ test/jdk/jdk/incubator/vector/AbstractVectorTest.java
+ test/jdk/jdk/incubator/vector/AddTest.java
+ test/jdk/jdk/incubator/vector/Byte128VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Byte128VectorTests.java
+ test/jdk/jdk/incubator/vector/Byte256VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Byte256VectorTests.java
+ test/jdk/jdk/incubator/vector/Byte512VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Byte512VectorTests.java
+ test/jdk/jdk/incubator/vector/Byte64VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Byte64VectorTests.java
+ test/jdk/jdk/incubator/vector/ByteMaxVectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/ByteMaxVectorTests.java
+ test/jdk/jdk/incubator/vector/CovarOverrideTest.java
+ test/jdk/jdk/incubator/vector/Double128VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Double128VectorTests.java
+ test/jdk/jdk/incubator/vector/Double256VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Double256VectorTests.java
+ test/jdk/jdk/incubator/vector/Double512VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Double512VectorTests.java
+ test/jdk/jdk/incubator/vector/Double64VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Double64VectorTests.java
+ test/jdk/jdk/incubator/vector/DoubleMaxVectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/DoubleMaxVectorTests.java
+ test/jdk/jdk/incubator/vector/Float128VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Float128VectorTests.java
+ test/jdk/jdk/incubator/vector/Float256VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Float256VectorTests.java
+ test/jdk/jdk/incubator/vector/Float512VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Float512VectorTests.java
+ test/jdk/jdk/incubator/vector/Float64VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Float64VectorTests.java
+ test/jdk/jdk/incubator/vector/FloatMaxVectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/FloatMaxVectorTests.java
+ test/jdk/jdk/incubator/vector/Int128VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Int128VectorTests.java
+ test/jdk/jdk/incubator/vector/Int256VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Int256VectorTests.java
+ test/jdk/jdk/incubator/vector/Int512VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Int512VectorTests.java
+ test/jdk/jdk/incubator/vector/Int64VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Int64VectorTests.java
+ test/jdk/jdk/incubator/vector/IntMaxVectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/IntMaxVectorTests.java
+ test/jdk/jdk/incubator/vector/Long128VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Long128VectorTests.java
+ test/jdk/jdk/incubator/vector/Long256VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Long256VectorTests.java
+ test/jdk/jdk/incubator/vector/Long512VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Long512VectorTests.java
+ test/jdk/jdk/incubator/vector/Long64VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Long64VectorTests.java
+ test/jdk/jdk/incubator/vector/LongMaxVectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/LongMaxVectorTests.java
+ test/jdk/jdk/incubator/vector/MethodOverideTest.java
+ test/jdk/jdk/incubator/vector/MismatchTest.java
+ test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java
+ test/jdk/jdk/incubator/vector/README.md
+ test/jdk/jdk/incubator/vector/Short128VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Short128VectorTests.java
+ test/jdk/jdk/incubator/vector/Short256VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Short256VectorTests.java
+ test/jdk/jdk/incubator/vector/Short512VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Short512VectorTests.java
+ test/jdk/jdk/incubator/vector/Short64VectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/Short64VectorTests.java
+ test/jdk/jdk/incubator/vector/ShortMaxVectorLoadStoreTests.java
+ test/jdk/jdk/incubator/vector/ShortMaxVectorTests.java
+ test/jdk/jdk/incubator/vector/Vector128ConversionTests.java
+ test/jdk/jdk/incubator/vector/Vector256ConversionTests.java
+ test/jdk/jdk/incubator/vector/Vector512ConversionTests.java
+ test/jdk/jdk/incubator/vector/Vector64ConversionTests.java
+ test/jdk/jdk/incubator/vector/VectorArrays.java
+ test/jdk/jdk/incubator/vector/VectorHash.java
+ test/jdk/jdk/incubator/vector/VectorMaxConversionTests.java
+ test/jdk/jdk/incubator/vector/VectorReshapeTests.java
+ test/jdk/jdk/incubator/vector/VectorRuns.java
+ test/jdk/jdk/incubator/vector/build-tests.sh
+ test/jdk/jdk/incubator/vector/clean.sh
+ test/jdk/jdk/incubator/vector/config.sh
+ test/jdk/jdk/incubator/vector/gen-template.sh
+ test/jdk/jdk/incubator/vector/gen-tests.sh
+ test/jdk/jdk/incubator/vector/run-tests.sh
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Broadcast-Long-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Broadcast-Masked-Long-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Broadcast-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Broadcast-Masked-op_bitwise-div.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Broadcast-op-math.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Broadcast-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Broadcast-op_bitwise-div.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Masked-op-smoke.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-Masked-op_bitwise-div.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-op-math.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-op-smoke.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Binary-op_bitwise-div.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Blend-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-BoolReduction-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Broadcast.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Gather-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Gather-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Get-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Rearrange.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-Max-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-Min-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Max-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Min-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Scatter-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Scatter-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Shift-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Shift-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Single-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Slice-Masked-bop.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Slice-bop.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Slice-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Ternary-Double-Broadcast-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Ternary-Double-Broadcast-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Ternary-Masked-op-smoke.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Ternary-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Ternary-op-smoke.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Ternary-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Unary-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Unary-op-math.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Unary-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Unslice-Masked-bop.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Unslice-bop.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Unslice-op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-With-Op.template
+ test/jdk/jdk/incubator/vector/templates/Kernel-Zero.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Long-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-Long-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op-math.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Binary-Broadcast-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Binary-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Binary-Scalar-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Binary-op-math.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Binary-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Blend-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-BoolReduction-Scalar-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-BoolReduction-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Broadcast.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Compare-Broadcast.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Compare-Masked.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Compare.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Gather-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Gather-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Get-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Miscellaneous.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Rearrange.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Max-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-Min-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Max-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Min-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Max-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-Min-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Max-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-Min-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-Scalar-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Scatter-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Scatter-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Shift-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Shift-Scalar-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Shift-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Single-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Slice-Masked-bop.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Slice-bop.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Slice-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Broadcast-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Double-Broadcast-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Ternary-Scalar-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Ternary-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Test.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Unary-Masked-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Unary-Scalar-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Unary-op-math.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Unary-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Unslice-Masked-bop.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Unslice-bop.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Unslice-op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-With-Op.template
+ test/jdk/jdk/incubator/vector/templates/Unit-Zero.template
+ test/jdk/jdk/incubator/vector/templates/Unit-footer.template
+ test/jdk/jdk/incubator/vector/templates/Unit-header.template
+ test/jdk/jdk/incubator/vector/templates/X-LoadStoreTest.java.template

Changeset: da2f5ab5
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-14 20:56:58 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/da2f5ab5

8254780: EnterInterpOnlyModeClosure::completed() always returns true

Reviewed-by: sspitsyn, rehn

! src/hotspot/share/prims/jvmtiEventController.cpp

Changeset: 8fb294a2
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-14 20:57:41 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/8fb294a2

8254781: Remove unimplemented ClassFieldMap::compute_field_count

Reviewed-by: phh, sspitsyn

! src/hotspot/share/prims/jvmtiTagMap.cpp

Changeset: 03fa733e
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-14 20:58:18 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/03fa733e

8254777: Remove unimplemented Management::get_loaded_classes

Reviewed-by: sspitsyn

! src/hotspot/share/services/management.hpp

Changeset: 55d760d4
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
Date:      2020-10-14 22:15:57 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/55d760d4

8254263: Remove special_runtime_exit_condition() check from ~ThreadInVMForHandshake()

Reviewed-by: rrich, dholmes, dcubed, rehn

! src/hotspot/share/runtime/handshake.cpp
! src/hotspot/share/runtime/interfaceSupport.inline.hpp
! src/hotspot/share/runtime/safepoint.cpp
! src/hotspot/share/runtime/safepointMechanism.cpp

Changeset: 5194f11b
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2020-10-15 00:05:40 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/5194f11b

8254792: Disable intrinsic StringLatin1.indexOf until 8254790 is fixed

Reviewed-by: dcubed

! src/hotspot/share/opto/c2compiler.cpp

Changeset: 038f58d4
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
Date:      2020-10-15 00:21:42 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/038f58d4

8226236: [TESTBUG] win32: gc/metaspace/TestCapacityUntilGCWrapAround.java fails

Reviewed-by: stuefe

! src/hotspot/share/memory/metaspace.cpp

Changeset: 7e5eb493
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2020-10-15 05:52:54 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/7e5eb493

8253402: Convert vmSymbols::SID to enum class

Reviewed-by: kvn, coleenp, kbarrett, iveresov

! src/hotspot/share/ci/ciObjectFactory.cpp
! src/hotspot/share/ci/ciObjectFactory.hpp
! src/hotspot/share/ci/ciSymbol.cpp
! src/hotspot/share/ci/ciSymbol.hpp
! src/hotspot/share/classfile/classFileParser.cpp
! src/hotspot/share/classfile/javaClasses.cpp
! src/hotspot/share/classfile/javaClasses.hpp
! src/hotspot/share/classfile/moduleEntry.hpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionary.hpp
! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp
! src/hotspot/share/classfile/vmSymbols.cpp
! src/hotspot/share/classfile/vmSymbols.hpp
! src/hotspot/share/jvmci/jvmciCompilerToVMInit.cpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/oops/fieldInfo.hpp
! src/hotspot/share/oops/method.cpp
! src/hotspot/share/oops/method.hpp
! src/hotspot/share/oops/symbol.cpp
! src/hotspot/share/oops/symbol.hpp
! src/hotspot/share/prims/methodHandles.cpp
! src/hotspot/share/runtime/flags/jvmFlag.hpp
! src/hotspot/share/runtime/flags/jvmFlagAccess.hpp
! src/hotspot/share/runtime/vmStructs.cpp
+ src/hotspot/share/utilities/enumIterator.hpp
+ src/hotspot/share/utilities/vmEnums.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/vmSymbols.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java

Changeset: 81a8ff1d
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-15 06:30:19 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/81a8ff1d

8254769: Remove unimplemented BCEscapeAnalyzer::{add_dependence, propagate_dependencies}

Reviewed-by: thartmann, kvn

! src/hotspot/share/ci/bcEscapeAnalyzer.hpp

Changeset: 167c1924
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-15 06:31:19 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/167c1924

8254771: Remove unimplemented ciSignature::get_all_klasses

Reviewed-by: thartmann, kvn

! src/hotspot/share/ci/ciSignature.hpp

Changeset: 7f73474f
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-15 06:32:16 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/7f73474f

8254773: Remove unimplemented ciReplay::is_loaded(Klass* klass)

Reviewed-by: thartmann, kvn

! src/hotspot/share/ci/ciReplay.hpp

Changeset: f44fc6de
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2020-10-15 06:53:03 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/f44fc6de

8254734: "dead loop detected" assert failure with patch from 8223051

Reviewed-by: chagedorn, kvn

! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp

Changeset: 9359ff03
Author:    Amit Pawar <amith.pawar at gmail.com>
Committer: Thomas Schatzl <tschatzl at openjdk.org>
Date:      2020-10-15 07:22:38 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/9359ff03

8252221: Use multiple workers for Parallel GC pre-touching

Reviewed-by: kbarrett, tschatzl

! src/hotspot/share/gc/g1/g1PageBasedVirtualSpace.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.cpp
! src/hotspot/share/gc/parallel/mutableNUMASpace.hpp
! src/hotspot/share/gc/parallel/mutableSpace.cpp
! src/hotspot/share/gc/parallel/mutableSpace.hpp
! src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp
! src/hotspot/share/gc/parallel/psOldGen.cpp
! src/hotspot/share/gc/parallel/psYoungGen.cpp
+ src/hotspot/share/gc/shared/pretouchTask.cpp
+ src/hotspot/share/gc/shared/pretouchTask.hpp

Changeset: 60159cff
Author:    Volker Simonis <simonis at openjdk.org>
Date:      2020-10-15 09:18:26 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/60159cff

8253952: Refine ZipOutputStream.putNextEntry() to recalculate ZipEntry's compressed size

Reviewed-by: lancea, alanb

! src/java.base/share/classes/java/util/jar/JarOutputStream.java
! src/java.base/share/classes/java/util/zip/ZipEntry.java
! src/java.base/share/classes/java/util/zip/ZipOutputStream.java
+ test/jdk/java/util/zip/CopyZipFile.java

Changeset: abe51377
Author:    Per Liden <pliden at openjdk.org>
Date:      2020-10-15 09:23:00 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/abe51377

8254719: ZGC: Clean up includes

Reviewed-by: stefank

! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/gc/z/zDirector.cpp
! src/hotspot/share/gc/z/zForwarding.cpp
! src/hotspot/share/gc/z/zForwarding.inline.hpp
! src/hotspot/share/gc/z/zHeap.cpp
! src/hotspot/share/gc/z/zHeap.hpp
! src/hotspot/share/gc/z/zHeap.inline.hpp
! src/hotspot/share/gc/z/zHeapIterator.cpp
! src/hotspot/share/gc/z/zMark.cpp
! src/hotspot/share/gc/z/zMark.hpp
! src/hotspot/share/gc/z/zMemory.cpp
! src/hotspot/share/gc/z/zMessagePort.hpp
! src/hotspot/share/gc/z/zNMethod.cpp
! src/hotspot/share/gc/z/zObjectAllocator.cpp
! src/hotspot/share/gc/z/zObjectAllocator.hpp
! src/hotspot/share/gc/z/zPage.inline.hpp
! src/hotspot/share/gc/z/zPageAllocator.cpp
! src/hotspot/share/gc/z/zPageCache.cpp
! src/hotspot/share/gc/z/zReferenceProcessor.cpp
! src/hotspot/share/gc/z/zRelocate.cpp
! src/hotspot/share/gc/z/zRelocate.hpp
! src/hotspot/share/gc/z/zRootsIterator.cpp
! src/hotspot/share/gc/z/zRootsIterator.hpp
! src/hotspot/share/gc/z/zRuntimeWorkers.cpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zTracer.inline.hpp
! src/hotspot/share/gc/z/zUncommitter.hpp
! src/hotspot/share/gc/z/zUnmapper.hpp
! src/hotspot/share/gc/z/zVerify.cpp
! src/hotspot/share/gc/z/zWeakRootsProcessor.cpp
! src/hotspot/share/gc/z/zWorkers.cpp
! src/hotspot/share/gc/z/zWorkers.hpp
! src/hotspot/share/runtime/stackWatermark.hpp
! src/hotspot/share/runtime/threadSMR.hpp

Changeset: 3c2f5e08
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2020-10-15 10:39:11 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/3c2f5e08

8254674: G1: Improve root location reference to dead obj verification message

Reviewed-by: sjohanss, lkorinth

! src/hotspot/share/gc/g1/g1HeapVerifier.cpp

Changeset: 8ef88e59
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2020-10-15 14:07:52 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/8ef88e59

8249878: jfr_emergency_dump has secondary crashes

Reviewed-by: egahlin

! src/hotspot/share/jfr/recorder/repository/jfrEmergencyDump.cpp

Changeset: cda22e36
Author:    Martin Doerr <mdoerr at openjdk.org>
Date:      2020-10-15 14:16:20 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/cda22e36

8254811: JDK-8254158 broke ppc64, s390 builds

Reviewed-by: stuefe, goetz

! src/hotspot/os/posix/os_posix.cpp
! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp

Changeset: f3ce45f2
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2020-10-15 14:46:04 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/f3ce45f2

8254799: runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java fails with release VMs

Reviewed-by: dholmes, dcubed, stuefe

! test/hotspot/jtreg/runtime/ErrorHandling/TestHeapDumpOnOutOfMemoryError.java

Changeset: 546620bb
Author:    Yumin Qi <minqi at openjdk.org>
Date:      2020-10-15 16:47:06 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/546620bb

8254192: ExtraSharedClassListFile contains extra white space at end of line

Reviewed-by: iklam, ccheung, mchung

! src/hotspot/share/classfile/classListParser.cpp
! src/java.base/share/classes/jdk/internal/misc/CDS.java

Changeset: 96bb6e76
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2020-10-15 20:05:28 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/96bb6e76

8251325: Miss 'L' for long value in if statement

Reviewed-by: iklam

! src/jdk.jfr/share/classes/jdk/jfr/internal/dcmd/DCmdStart.java

Changeset: bdda2058
Author:    Xin Liu <xliu at openjdk.org>
Committer: Vladimir Kozlov <kvn at openjdk.org>
Date:      2020-10-16 01:59:07 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/bdda2058

8254369: Node::disconnect_inputs may skip precedences

disconnect_inputs() needs to iterate precedences edges in reverse order because rm_prec(i) may backfill _in[i] with a value afterward.
also remove the predicate if (n != NULL) in set_prec because it's always true.

Reviewed-by: kvn, redestad

! src/hotspot/share/opto/node.cpp
! src/hotspot/share/opto/node.hpp

Changeset: 5145bed0
Author:    Ioi Lam <iklam at openjdk.org>
Date:      2020-10-16 05:14:46 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/5145bed0

8254125: Assertion in cppVtables.cpp during builds on 32bit Windows

Reviewed-by: shade, ccheung

! src/hotspot/share/classfile/compactHashtable.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/memory/archiveBuilder.cpp
! src/hotspot/share/memory/archiveBuilder.hpp
! src/hotspot/share/memory/archiveUtils.cpp
! src/hotspot/share/memory/cppVtables.cpp
! src/hotspot/share/memory/cppVtables.hpp
! src/hotspot/share/memory/dynamicArchive.cpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/memory/metaspaceShared.hpp
! src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java

Changeset: 7c0d4170
Author:    Tobias Hartmann <thartmann at openjdk.org>
Date:      2020-10-16 06:25:33 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/7c0d4170

8251535: Partial peeling at unsigned test adds incorrect loop exit check

Reviewed-by: chagedorn, neliasso, kvn

! src/hotspot/share/opto/loopopts.cpp
+ test/hotspot/jtreg/compiler/loopopts/TestPartialPeelAtUnsignedTests.java

Changeset: 3d23bd8e
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2020-10-16 06:57:36 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/3d23bd8e

8254814: [Vector API] Fix an AVX512 crash after JDK-8223347

Reviewed-by: vlivanov, thartmann, psandoz

! src/hotspot/cpu/x86/x86.ad

Changeset: 34583ebd
Author:    Chris Hegarty <chegar at openjdk.org>
Date:      2020-10-16 08:09:57 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/34583ebd

8254161: Prevent instantiation of EnumSet subclasses through deserialization

Reviewed-by: dfuchs, alanb, rriggs, smarks

! src/java.base/share/classes/java/util/EnumSet.java

Changeset: 1742c44a
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2020-10-16 09:19:22 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/1742c44a

8254695: G1: Next mark bitmap clear not cancelled after marking abort

Reviewed-by: iwalulya, sjohanss

! src/hotspot/share/gc/g1/g1ConcurrentMark.cpp

Changeset: 0570cc10
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2020-10-16 11:38:02 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/0570cc10

8254855: Clean up and remove unused code in vmIntrinsics

Reviewed-by: kbarrett, iklam, kvn

! src/hotspot/share/classfile/vmIntrinsics.cpp
! src/hotspot/share/classfile/vmIntrinsics.hpp

Changeset: 07ec35e2
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2020-10-16 15:21:37 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/07ec35e2

8254623: gc/g1/TestHumongousConcurrentStartUndo.java still fails sometimes

Reviewed-by: kbarrett, sjohanss

! test/hotspot/jtreg/gc/g1/TestHumongousConcurrentStartUndo.java

Changeset: 402d01aa
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2020-10-16 19:35:10 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/402d01aa

8254795: Remove obsolete template files

Reviewed-by: ksrini

- test/langtools/jdk/javadoc/doclet/_template/Template.java
- test/langtools/jdk/javadoc/doclet/_template/TemplateComplete.java

Changeset: e66c6bb9
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2020-10-16 21:56:54 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/e66c6bb9

8254349: The TestNoScreenMenuBar test should be updated

Reviewed-by: pbansal

! test/jdk/java/awt/MenuBar/TestNoScreenMenuBar.java

Changeset: 83ea8631
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2020-10-16 22:15:52 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/83ea8631

8253559: The INDEX page should link to Serialized Form and Constant Values pages

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Contents.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/IndexWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/IndexItem.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java
! test/langtools/jdk/javadoc/doclet/testPackagePage/TestPackagePage.java
! test/langtools/jdk/javadoc/doclet/testSystemPropertyPage/TestSystemPropertyPage.java

Changeset: ce1aac1e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2020-10-17 07:12:59 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/ce1aac1e

8028707: javax/swing/JComboBox/6236162/bug6236162.java fails on azure

Reviewed-by: serb, pbansal

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JComboBox/6236162/bug6236162.java

Changeset: 0b3e6c51
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2020-10-17 07:18:48 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/0b3e6c51

8194126: Regression automated Test '/open/test/jdk/javax/swing/JColorChooser/Test7194184.java' fails

Reviewed-by: serb, trebari

! test/jdk/ProblemList.txt
! test/jdk/javax/swing/JColorChooser/Test7194184.java

Changeset: c17d5851
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2020-10-18 18:54:33 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/c17d5851

8246774: implement Record Classes as a standard feature in Java

Co-authored-by: Vicente Romero <vromero at openjdk.org>
Co-authored-by: Harold Seigel <hseigel at openjdk.org>
Co-authored-by: Chris Hegarty <chegar at openjdk.org>
Reviewed-by: coleenp, jlahoda, sspitsyn, chegar

! src/hotspot/share/classfile/classFileParser.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/Record.java
! src/java.base/share/classes/java/lang/annotation/ElementType.java
! src/java.base/share/classes/java/lang/reflect/RecordComponent.java
! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java
! src/java.base/share/classes/sun/reflect/annotation/TypeAnnotation.java
! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/hotspot/jtreg/runtime/records/RedefineRecord.java
! test/hotspot/jtreg/runtime/records/abstractRecord.jcod
! test/hotspot/jtreg/runtime/records/badRecordAttribute.jcod
! test/hotspot/jtreg/runtime/records/ignoreRecordAttribute.java
! test/hotspot/jtreg/runtime/records/notFinalRecord.jcod
! test/hotspot/jtreg/runtime/records/recordAttributeTest.java
- test/hotspot/jtreg/runtime/records/recordIgnoredVersion.jcod
! test/hotspot/jtreg/runtime/records/recordReflectionTest.java
! test/hotspot/jtreg/runtime/records/shortRecordAttribute.jcod
! test/hotspot/jtreg/runtime/records/superNotJLRecord.jcod
! test/hotspot/jtreg/runtime/records/twoRecordAttributes.jcod
! test/jdk/java/io/Serializable/records/AbsentStreamValuesTest.java
! test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
! test/jdk/java/io/Serializable/records/BasicRecordSer.java
! test/jdk/java/io/Serializable/records/ConstructorAccessTest.java
! test/jdk/java/io/Serializable/records/ConstructorPermissionTest.java
! test/jdk/java/io/Serializable/records/CycleTest.java
! test/jdk/java/io/Serializable/records/DifferentStreamFieldsTest.java
! test/jdk/java/io/Serializable/records/ProhibitedMethods.java
! test/jdk/java/io/Serializable/records/ReadResolveTest.java
! test/jdk/java/io/Serializable/records/RecordClassTest.java
! test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
! test/jdk/java/io/Serializable/records/SerialVersionUIDTest.java
! test/jdk/java/io/Serializable/records/StreamRefTest.java
! test/jdk/java/io/Serializable/records/ThrowingConstructorTest.java
! test/jdk/java/io/Serializable/records/UnsharedTest.java
! test/jdk/java/io/Serializable/records/WriteReplaceTest.java
! test/jdk/java/io/Serializable/records/migration/AbstractTest.java
! test/jdk/java/io/Serializable/records/migration/AssignableFromTest.java
! test/jdk/java/io/Serializable/records/migration/DefaultValuesTest.java
! test/jdk/java/io/Serializable/records/migration/SuperStreamFieldsTest.java
! test/jdk/java/lang/instrument/RedefineRecordAttr/TestRecordAttr.java
! test/jdk/java/lang/instrument/RedefineRecordAttrGenericSig/TestRecordAttrGenericSig.java
! test/jdk/java/lang/runtime/ObjectMethodsTest.java
! test/langtools/jdk/javadoc/doclet/testRecordLinks/TestRecordLinks.java
! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java
! test/langtools/jdk/javadoc/tool/api/basic/GetTask_DiagListenerTest.java
! test/langtools/jdk/jshell/CompletenessTest.java
! test/langtools/jdk/jshell/RecordsTest.java
! test/langtools/jdk/jshell/ToolSimpleTest.java
! test/langtools/tools/javac/IllegalAnnotation.java
! test/langtools/tools/javac/IllegalAnnotation.out
! test/langtools/tools/javac/LocalInterface.java
! test/langtools/tools/javac/LocalInterface.out
! test/langtools/tools/javac/LocalRecord.java
! test/langtools/tools/javac/annotations/ApplicableAnnotationsOnRecords.java
! test/langtools/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java
! test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnotationsPositionsOnRecords.java
! test/langtools/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.out
! test/langtools/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out
! test/langtools/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.out
! test/langtools/tools/javac/api/TestGetScopeResult.java
! test/langtools/tools/javac/diags/examples/AccessorCantBeGeneric.java
! test/langtools/tools/javac/diags/examples/AccessorCantThrowException.java
! test/langtools/tools/javac/diags/examples/AccessorMethodCantBeStatic.java
! test/langtools/tools/javac/diags/examples/AccessorReturnTypeDoesntMatch.java
! test/langtools/tools/javac/diags/examples/CanonicalCantHaveStrongerAccessPrivileges.java
! test/langtools/tools/javac/diags/examples/CanonicalCantInvokeOtherConstructor.java
! test/langtools/tools/javac/diags/examples/CanonicalConstructorArgumentMismatch.java
! test/langtools/tools/javac/diags/examples/CanonicalConstructorCantHaveReturn.java
! test/langtools/tools/javac/diags/examples/CanonicalConstructorCantHaveThrowsClause.java
! test/langtools/tools/javac/diags/examples/CanonicalMustNotDeclareTypeVariables.java
! test/langtools/tools/javac/diags/examples/ConstructorWithSameErasureAsCanonical.java
! test/langtools/tools/javac/diags/examples/Expected3.java
! test/langtools/tools/javac/diags/examples/FirstInvocationMustBeAnotherConstructor.java
! test/langtools/tools/javac/diags/examples/IllegalRecordComponentName.java
! test/langtools/tools/javac/diags/examples/IncorrectRecordDeclaration.java
! test/langtools/tools/javac/diags/examples/InstanceInitializersNotAllowedInRecords.java
! test/langtools/tools/javac/diags/examples/InterfaceNotAllowed.java
! test/langtools/tools/javac/diags/examples/InvalidSuperTypeRecord.java
! test/langtools/tools/javac/diags/examples/KindnameRecord.java
! test/langtools/tools/javac/diags/examples/LocalEnum.java
! test/langtools/tools/javac/diags/examples/MethodMustBePublic.java
! test/langtools/tools/javac/diags/examples/Records.java
! test/langtools/tools/javac/diags/examples/RecordsCanNotDeclareInstanceFields.java
! test/langtools/tools/javac/diags/examples/RecordsCantDeclareComponentModifiers.java
! test/langtools/tools/javac/diags/examples/RecordsComponentsCanNotDeclareCStyleArrays.java
! test/langtools/tools/javac/diags/examples/RecordsNotAllowedInInnerClasses.java
! test/langtools/tools/javac/enum/FauxEnum3.java
! test/langtools/tools/javac/enum/FauxEnum3.out
! test/langtools/tools/javac/enum/LocalEnum.java
! test/langtools/tools/javac/enum/LocalEnum.out
! test/langtools/tools/javac/launcher/SourceLauncherTest.java
! test/langtools/tools/javac/parser/JavacParserTest.java
! test/langtools/tools/javac/parser/SingleCommaAnnotationValueFail.out
! test/langtools/tools/javac/processing/model/element/JavaxLangModelForRecords.java
! test/langtools/tools/javac/records/ElementFilterRecordComponentTest.java
! test/langtools/tools/javac/records/LocalStaticDeclarations.java
! test/langtools/tools/javac/records/MapAccessorToComponent.java
! test/langtools/tools/javac/records/RecordCompilationTests.java
! test/langtools/tools/javac/records/RecordMemberTests.java
! test/langtools/tools/javac/records/VarargsRecordsTest.java
! test/langtools/tools/javac/records/mandated_members/CheckRecordMembers.java
! test/langtools/tools/javac/records/writeread/WriteReadTest.java
! test/langtools/tools/javac/tree/TreePosTest.java
! test/langtools/tools/sjavac/PubApisTest.java

Changeset: 272bb5d5
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2020-10-19 02:03:10 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/272bb5d5

8253455: Record Classes javax.lang.model changes

Reviewed-by: darcy

! src/java.base/share/classes/jdk/internal/PreviewFeature.java
! src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java
! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java
! src/java.compiler/share/classes/javax/lang/model/element/RecordComponentElement.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java
! src/java.compiler/share/classes/javax/lang/model/util/Elements.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java

Changeset: dd032b7f
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2020-10-19 03:11:51 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/dd032b7f

8254798: Deprecate for removal an empty finalize() methods in java.desktop module

Reviewed-by: kcr, pbansal

! src/java.desktop/share/classes/com/sun/media/sound/AbstractMidiDevice.java
! src/java.desktop/share/classes/java/awt/color/ICC_Profile.java
! src/java.desktop/share/classes/java/awt/image/ColorModel.java
! src/java.desktop/share/classes/java/awt/image/IndexColorModel.java
! src/java.desktop/share/classes/sun/java2d/pipe/RegionClipSpanIterator.java
! src/java.desktop/share/classes/sun/java2d/pipe/RegionSpanIterator.java

Changeset: 51a865d6
Author:    Alexander Zuev <kizune at openjdk.org>
Date:      2020-10-19 04:26:42 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/51a865d6

8254085: javax/swing/text/Caret/TestCaretPositionJTextPane.java failed with "RuntimeException:  Wrong caret position"

Reviewed-by: serb

! test/jdk/javax/swing/text/Caret/TestCaretPositionJTextPane.java

Changeset: 736e0773
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-19 06:16:50 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/736e0773

8254178: Remove .hgignore

Reviewed-by: ehelin

- .hgignore

Changeset: 011dd0d8
Author:    Robbin Ehn <rehn at openjdk.org>
Date:      2020-10-19 06:28:47 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/011dd0d8

8254824: SignalHandlerMark have no purpose

Reviewed-by: stuefe, shade, dholmes, coleenp

! src/hotspot/os_cpu/aix_ppc/os_aix_ppc.cpp
! src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp
! src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp
! src/hotspot/os_cpu/linux_aarch64/os_linux_aarch64.cpp
! src/hotspot/os_cpu/linux_arm/os_linux_arm.cpp
! src/hotspot/os_cpu/linux_ppc/os_linux_ppc.cpp
! src/hotspot/os_cpu/linux_s390/os_linux_s390.cpp
! src/hotspot/os_cpu/linux_x86/os_linux_x86.cpp
! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp
! src/hotspot/share/runtime/thread.cpp
! src/hotspot/share/runtime/thread.hpp

Changeset: 98a395a3
Author:    Per Liden <pliden at openjdk.org>
Date:      2020-10-19 07:11:40 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/98a395a3

8254880: ZGC: Let ZList iterators be alias templates

Reviewed-by: ayang, kbarrett, tschatzl

! src/hotspot/share/gc/z/zList.hpp
! src/hotspot/share/gc/z/zList.inline.hpp

Changeset: 672f5669
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2020-10-19 07:22:29 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/672f5669

8254874: ZGC: JNIHandleBlock verification failure in stack watermark processing

Reviewed-by: tschatzl, cjplummer, sspitsyn, pliden

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/cm03t001.cpp

Changeset: 8edc2f05
Author:    Stefan Karlsson <stefank at openjdk.org>
Date:      2020-10-19 07:23:43 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/8edc2f05

8254912: ZGC: Change ZCollectionInterval type to double

Reviewed-by: pliden, ayang

! src/hotspot/share/gc/z/zDirector.cpp
! src/hotspot/share/gc/z/z_globals.hpp

Changeset: a1a3e9de
Author:    Per Liden <pliden at openjdk.org>
Date:      2020-10-19 07:35:36 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/a1a3e9de

8254882: ZGC: Use static_assert instead of guarantee

Reviewed-by: kbarrett, tschatzl

! src/hotspot/share/gc/z/zBitField.hpp
! src/hotspot/share/gc/z/zMarkStack.hpp
! src/hotspot/share/gc/z/zMarkStackAllocator.cpp

Changeset: e10b5385
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
Date:      2020-10-19 09:18:40 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/e10b5385

8243962: Various JVM TI tests time out using JFR on Windows

Reviewed-by: sspitsyn, cjplummer

! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP03/sp03t002/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t001/TestDescription.java
! test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/sampling/SP04/sp04t002/TestDescription.java

Changeset: e9be2db7
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2020-10-19 10:49:33 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/e9be2db7

8253453: SourceFileInfoTable should be allocated lazily

Reviewed-by: neliasso, chagedorn

! src/hotspot/share/compiler/disassembler.cpp

Changeset: e76de189
Author:    Roland Westrelin <roland at openjdk.org>
Date:      2020-10-19 11:30:13 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/e76de189

8223051: support loops with long (64b) trip counts

Reviewed-by: vlivanov, thartmann, jrose

! src/hotspot/share/opto/c2_globals.hpp
! src/hotspot/share/opto/callnode.cpp
! src/hotspot/share/opto/callnode.hpp
! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/convertnode.cpp
! src/hotspot/share/opto/loopnode.cpp
! src/hotspot/share/opto/loopnode.hpp
! src/hotspot/share/opto/loopopts.cpp
! src/hotspot/share/opto/macro.cpp
! src/hotspot/share/opto/macroArrayCopy.cpp
! src/hotspot/share/opto/parse1.cpp

Changeset: cd66e0f2
Author:    Thomas Schatzl <tschatzl at openjdk.org>
Date:      2020-10-19 11:40:58 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/cd66e0f2

8253877: gc/g1/TestGCLogMessages.java fails - missing "Evacuation failure" message

Reviewed-by: sjohanss

! test/hotspot/jtreg/gc/g1/TestGCLogMessages.java

Changeset: 4ffed326
Author:    Anton Kozlov <akozlov at openjdk.org>
Committer: Vladimir Kempik <vkempik at openjdk.org>
Date:      2020-10-19 11:43:02 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/4ffed326

8254940: AArch64: Cleanup non-product thread members

Reviewed-by: aph

! src/hotspot/os_cpu/linux_aarch64/thread_linux_aarch64.hpp
! src/hotspot/os_cpu/windows_aarch64/thread_windows_aarch64.hpp

Changeset: cb7701b7
Author:    Jie Fu <jiefu at openjdk.org>
Date:      2020-10-19 13:18:50 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/cb7701b7

8253970: Build error: address argument to atomic builtin must be a pointer to integer or pointer ('volatile narrowOop *' invalid)

Reviewed-by: kbarrett, dholmes

! src/hotspot/os_cpu/bsd_zero/atomic_bsd_zero.hpp
! src/hotspot/os_cpu/linux_zero/atomic_linux_zero.hpp

Changeset: a0382cd1
Author:    Ekaterina Vergizova <katya at azul.com>
Committer: Vladimir Kempik <vkempik at openjdk.org>
Date:      2020-10-19 14:19:58 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/a0382cd1

8253235: JFR.dump does not respect maxage parameter

Reviewed-by: egahlin

! src/jdk.jfr/share/classes/jdk/jfr/internal/PlatformRecording.java

Changeset: 1da28de8
Author:    Vicente Romero <vromero at openjdk.org>
Date:      2020-10-19 15:55:54 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/1da28de8

8255009: delta apply fixes for JDK-8246774 and JDK-8253455, pushed too soon

Reviewed-by: jlahoda

! src/hotspot/share/classfile/classFileParser.cpp
! src/java.base/share/classes/java/lang/Class.java
! src/java.base/share/classes/java/lang/Record.java
! src/java.base/share/classes/java/lang/annotation/ElementType.java
! src/java.base/share/classes/java/lang/reflect/RecordComponent.java
! src/java.base/share/classes/java/lang/runtime/ObjectMethods.java
! src/java.base/share/classes/jdk/internal/PreviewFeature.java
! src/java.base/share/classes/sun/reflect/annotation/TypeAnnotation.java
! src/java.compiler/share/classes/javax/lang/model/element/ElementKind.java
! src/java.compiler/share/classes/javax/lang/model/element/ElementVisitor.java
! src/java.compiler/share/classes/javax/lang/model/element/RecordComponentElement.java
! src/java.compiler/share/classes/javax/lang/model/element/TypeElement.java
! src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementFilter.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor6.java
! src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java
! src/java.compiler/share/classes/javax/lang/model/util/Elements.java
! src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java
! src/jdk.compiler/share/classes/com/sun/source/tree/Tree.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
! src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
! test/hotspot/jtreg/runtime/records/RedefineRecord.java
! test/hotspot/jtreg/runtime/records/abstractRecord.jcod
! test/hotspot/jtreg/runtime/records/badRecordAttribute.jcod
! test/hotspot/jtreg/runtime/records/ignoreRecordAttribute.java
! test/hotspot/jtreg/runtime/records/notFinalRecord.jcod
! test/hotspot/jtreg/runtime/records/recordAttributeTest.java
+ test/hotspot/jtreg/runtime/records/recordIgnoredVersion.jcod
! test/hotspot/jtreg/runtime/records/recordReflectionTest.java
! test/hotspot/jtreg/runtime/records/shortRecordAttribute.jcod
! test/hotspot/jtreg/runtime/records/superNotJLRecord.jcod
! test/hotspot/jtreg/runtime/records/twoRecordAttributes.jcod
! test/jdk/java/io/Serializable/records/AbsentStreamValuesTest.java
! test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
! test/jdk/java/io/Serializable/records/BasicRecordSer.java
! test/jdk/java/io/Serializable/records/ConstructorAccessTest.java
! test/jdk/java/io/Serializable/records/ConstructorPermissionTest.java
! test/jdk/java/io/Serializable/records/CycleTest.java
! test/jdk/java/io/Serializable/records/DifferentStreamFieldsTest.java
! test/jdk/java/io/Serializable/records/ProhibitedMethods.java
! test/jdk/java/io/Serializable/records/ReadResolveTest.java
! test/jdk/java/io/Serializable/records/RecordClassTest.java
! test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
! test/jdk/java/io/Serializable/records/SerialVersionUIDTest.java
! test/jdk/java/io/Serializable/records/StreamRefTest.java
! test/jdk/java/io/Serializable/records/ThrowingConstructorTest.java
! test/jdk/java/io/Serializable/records/UnsharedTest.java
! test/jdk/java/io/Serializable/records/WriteReplaceTest.java
! test/jdk/java/io/Serializable/records/migration/AbstractTest.java
! test/jdk/java/io/Serializable/records/migration/AssignableFromTest.java
! test/jdk/java/io/Serializable/records/migration/DefaultValuesTest.java
! test/jdk/java/io/Serializable/records/migration/SuperStreamFieldsTest.java
! test/jdk/java/lang/instrument/RedefineRecordAttr/TestRecordAttr.java
! test/jdk/java/lang/instrument/RedefineRecordAttrGenericSig/TestRecordAttrGenericSig.java
! test/jdk/java/lang/runtime/ObjectMethodsTest.java
! test/langtools/jdk/javadoc/doclet/testRecordLinks/TestRecordLinks.java
! test/langtools/jdk/javadoc/doclet/testRecordTypes/TestRecordTypes.java
! test/langtools/jdk/javadoc/tool/api/basic/GetTask_DiagListenerTest.java
! test/langtools/jdk/jshell/CompletenessTest.java
! test/langtools/jdk/jshell/RecordsTest.java
! test/langtools/jdk/jshell/ToolSimpleTest.java
! test/langtools/tools/javac/IllegalAnnotation.java
! test/langtools/tools/javac/IllegalAnnotation.out
! test/langtools/tools/javac/LocalInterface.java
! test/langtools/tools/javac/LocalInterface.out
! test/langtools/tools/javac/LocalRecord.java
! test/langtools/tools/javac/annotations/ApplicableAnnotationsOnRecords.java
! test/langtools/tools/javac/annotations/repeatingAnnotations/combo/TargetAnnoCombo.java
! test/langtools/tools/javac/annotations/typeAnnotations/TypeAnnotationsPositionsOnRecords.java
! test/langtools/tools/javac/annotations/typeAnnotations/failures/AnnotatedImport.out
! test/langtools/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage1.out
! test/langtools/tools/javac/annotations/typeAnnotations/failures/AnnotatedPackage2.out
! test/langtools/tools/javac/api/TestGetScopeResult.java
! test/langtools/tools/javac/diags/examples/AccessorCantBeGeneric.java
! test/langtools/tools/javac/diags/examples/AccessorCantThrowException.java
! test/langtools/tools/javac/diags/examples/AccessorMethodCantBeStatic.java
! test/langtools/tools/javac/diags/examples/AccessorReturnTypeDoesntMatch.java
! test/langtools/tools/javac/diags/examples/CanonicalCantHaveStrongerAccessPrivileges.java
! test/langtools/tools/javac/diags/examples/CanonicalCantInvokeOtherConstructor.java
! test/langtools/tools/javac/diags/examples/CanonicalConstructorArgumentMismatch.java
! test/langtools/tools/javac/diags/examples/CanonicalConstructorCantHaveReturn.java
! test/langtools/tools/javac/diags/examples/CanonicalConstructorCantHaveThrowsClause.java
! test/langtools/tools/javac/diags/examples/CanonicalMustNotDeclareTypeVariables.java
! test/langtools/tools/javac/diags/examples/ConstructorWithSameErasureAsCanonical.java
! test/langtools/tools/javac/diags/examples/Expected3.java
! test/langtools/tools/javac/diags/examples/FirstInvocationMustBeAnotherConstructor.java
! test/langtools/tools/javac/diags/examples/IllegalRecordComponentName.java
! test/langtools/tools/javac/diags/examples/IncorrectRecordDeclaration.java
! test/langtools/tools/javac/diags/examples/InstanceInitializersNotAllowedInRecords.java
! test/langtools/tools/javac/diags/examples/InterfaceNotAllowed.java
! test/langtools/tools/javac/diags/examples/InvalidSuperTypeRecord.java
! test/langtools/tools/javac/diags/examples/KindnameRecord.java
! test/langtools/tools/javac/diags/examples/LocalEnum.java
! test/langtools/tools/javac/diags/examples/MethodMustBePublic.java
! test/langtools/tools/javac/diags/examples/Records.java
! test/langtools/tools/javac/diags/examples/RecordsCanNotDeclareInstanceFields.java
! test/langtools/tools/javac/diags/examples/RecordsCantDeclareComponentModifiers.java
! test/langtools/tools/javac/diags/examples/RecordsComponentsCanNotDeclareCStyleArrays.java
! test/langtools/tools/javac/diags/examples/RecordsNotAllowedInInnerClasses.java
! test/langtools/tools/javac/enum/FauxEnum3.java
! test/langtools/tools/javac/enum/FauxEnum3.out
! test/langtools/tools/javac/enum/LocalEnum.java
! test/langtools/tools/javac/enum/LocalEnum.out
! test/langtools/tools/javac/launcher/SourceLauncherTest.java
! test/langtools/tools/javac/parser/JavacParserTest.java
! test/langtools/tools/javac/parser/SingleCommaAnnotationValueFail.out
! test/langtools/tools/javac/processing/model/element/JavaxLangModelForRecords.java
! test/langtools/tools/javac/records/ElementFilterRecordComponentTest.java
! test/langtools/tools/javac/records/LocalStaticDeclarations.java
! test/langtools/tools/javac/records/MapAccessorToComponent.java
! test/langtools/tools/javac/records/RecordCompilationTests.java
! test/langtools/tools/javac/records/RecordMemberTests.java
! test/langtools/tools/javac/records/VarargsRecordsTest.java
! test/langtools/tools/javac/records/mandated_members/CheckRecordMembers.java
! test/langtools/tools/javac/records/writeread/WriteReadTest.java
! test/langtools/tools/javac/tree/TreePosTest.java
! test/langtools/tools/sjavac/PubApisTest.java

Changeset: 953e472d
Author:    Michael McMahon <michaelm at openjdk.org>
Date:      2020-10-19 16:57:40 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/953e472d

8254967: com.sun.net.HttpsServer spins on TLS session close

Reviewed-by: dfuchs

! src/jdk.httpserver/share/classes/sun/net/httpserver/SSLStreams.java

Changeset: 60f63ec8
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2020-10-19 17:08:06 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/60f63ec8

8254796: Cleanup pervasive unnecessary parameter

Reviewed-by: ksrini, hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SourceToHTMLConverter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/AbstractDoclet.java

Changeset: 52cb3292
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2020-10-19 17:38:22 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/52cb3292

8254862: lldb in devkit doesn't work

Reviewed-by: lmesnik, mikael, ihse

! make/conf/jib-profiles.js
! make/devkit/createMacosxDevkit.sh

Changeset: 0b510165
Author:    Erik Joelsson <erikj at openjdk.org>
Date:      2020-10-19 17:40:54 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/0b510165

8253660: Need better error report when artifact resolution fails in AotCompiler.java

Reviewed-by: ihse

! test/hotspot/jtreg/compiler/aot/AotCompiler.java
! test/jdk/sun/security/pkcs11/PKCS11Test.java
! test/lib/jdk/test/lib/artifacts/ArtifactResolverException.java

Changeset: e2e11d34
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2020-10-19 17:50:40 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/e2e11d34

8254955: x86: MethodHandlesAdapterBlob is too big

Reviewed-by: neliasso, kvn

! src/hotspot/cpu/x86/methodHandles_x86.hpp

Changeset: 74ac77e2
Author:    Calvin Cheung <ccheung at openjdk.org>
Date:      2020-10-19 18:27:50 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/74ac77e2

8247666: Support Lambda proxy classes in static CDS archive

Reviewed-by: iklam, mchung

! make/hotspot/symbols/symbols-unix
! src/hotspot/share/classfile/classListParser.cpp
! src/hotspot/share/classfile/classListParser.hpp
+ src/hotspot/share/classfile/classListWriter.hpp
! src/hotspot/share/classfile/systemDictionary.cpp
! src/hotspot/share/classfile/systemDictionaryShared.cpp
! src/hotspot/share/classfile/systemDictionaryShared.hpp
! src/hotspot/share/include/jvm.h
! src/hotspot/share/interpreter/linkResolver.cpp
! src/hotspot/share/memory/archiveUtils.cpp
! src/hotspot/share/memory/archiveUtils.hpp
! src/hotspot/share/memory/metaspaceShared.cpp
! src/hotspot/share/oops/instanceKlass.cpp
! src/hotspot/share/oops/klass.cpp
! src/hotspot/share/prims/jvm.cpp
! src/hotspot/share/runtime/mutexLocker.cpp
! src/hotspot/share/runtime/mutexLocker.hpp
! src/hotspot/share/utilities/ostream.cpp
! src/hotspot/share/utilities/ostream.hpp
! src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java
! src/java.base/share/classes/java/lang/invoke/LambdaProxyClassArchive.java
! src/java.base/share/classes/jdk/internal/misc/CDS.java
! src/java.base/share/native/libjava/CDS.c
! test/hotspot/jtreg/TEST.groups
+ test/hotspot/jtreg/runtime/cds/appcds/BadBSM.java
+ test/hotspot/jtreg/runtime/cds/appcds/LambdaProxyClasslist.java
+ test/hotspot/jtreg/runtime/cds/appcds/StaticArchiveWithLambda.java
+ test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaInBaseArchive.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/CustomLoaderApp.java
! test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/test-classes/LambHello.java
+ test/hotspot/jtreg/runtime/cds/appcds/methodHandles/CDSMHTest_generate.sh
+ test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesAsCollectorTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesCastFailureTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesGeneralTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesInvokersTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesPermuteArgumentsTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/methodHandles/MethodHandlesSpreadArgumentsTest.java
+ test/hotspot/jtreg/runtime/cds/appcds/test-classes/WrongBSM.jcod

Changeset: f42c0322
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2020-10-19 19:06:23 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/f42c0322

8254793: [JVMCI] improve speculation encoding

Reviewed-by: kvn, dlong, never

! src/hotspot/share/jvmci/jvmciRuntime.cpp
! src/hotspot/share/jvmci/jvmciRuntime.hpp
! src/hotspot/share/jvmci/vmStructs_jvmci.cpp
! src/hotspot/share/runtime/thread.hpp
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotResolvedJavaFieldImpl.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSpeculationEncoding.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotSpeculationLog.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotVMConfig.java
! test/hotspot/jtreg/compiler/jvmci/jdk.vm.ci.hotspot.test/src/jdk/vm/ci/hotspot/test/TestHotSpotSpeculationLog.java

Changeset: 14e1e174
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2020-10-19 19:39:19 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/14e1e174

8255004: [JVMCI] expose JVM_ACC_FIELD_INITIALIZED_FINAL_UPDATE

Reviewed-by: never, kvn

! src/hotspot/share/jvmci/vmStructs_jvmci.cpp

Changeset: 00014350
Author:    Paul Sandoz <psandoz at openjdk.org>
Date:      2020-10-19 20:37:36 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/00014350

8255020: Minor updates to docs jdk.incubator.vector

Reviewed-by: erikj, darcy

! make/CompileJavaModules.gmk
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java
! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/package-info.java

Changeset: cb5cdd77
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2020-10-19 20:52:01 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/cb5cdd77

8254721: Improve support for conditionally generated files

Reviewed-by: hannesw

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ConstantsSummaryWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/DeprecatedListWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlOptions.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/Navigation.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SerializedFormWriterImpl.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/SystemPropertiesWriter.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/BuilderFactory.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/ConstantsSummaryBuilder.java
! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/DeprecatedAPIListBuilder.java
! test/langtools/jdk/javadoc/doclet/WindowTitles/p1/C1.java
+ test/langtools/jdk/javadoc/doclet/testConditionalPages/TestConditionalPages.java
! test/langtools/jdk/javadoc/doclet/testCopyFiles/modules/acme.mdle/p/Foo.java
! test/langtools/jdk/javadoc/doclet/testGeneratedBy/pkg/MyClass.java
! test/langtools/jdk/javadoc/doclet/testHelpFile/TestHelpFile.java
! test/langtools/jdk/javadoc/doclet/testMetadata/TestMetadata.java
! test/langtools/jdk/javadoc/doclet/testModuleDirs/TestModuleDirs.java
! test/langtools/jdk/javadoc/doclet/testNavigation/TestModuleNavigation.java
! test/langtools/jdk/javadoc/doclet/testPackagePage/com/pkg/C.java
! test/langtools/jdk/javadoc/doclet/testTopOption/pkg/Cl.java
! test/langtools/jdk/javadoc/tool/api/basic/APITest.java
! test/langtools/jdk/javadoc/tool/api/basic/pkg/C.java

Changeset: 0f4fb367
Author:    Jonathan Gibbons <jjg at openjdk.org>
Date:      2020-10-19 22:05:47 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/0f4fb367

8255032: Conflict between recent pushes breaks the build

Reviewed-by: redestad, vromero

! src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlDoclet.java

Changeset: bf19581a
Author:    Stuart Marks <smarks at openjdk.org>
Date:      2020-10-19 23:53:06 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/bf19581a

8255016: ConstantDescs.FALSE claims it represents TRUE

Reviewed-by: bpb, jvernee, mchung, rriggs

! src/java.base/share/classes/java/lang/constant/ConstantDescs.java

Changeset: 6e8835c6
Author:    Sergey Bylokhov <serb at openjdk.org>
Date:      2020-10-19 23:54:10 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/6e8835c6

7110890: reg test TranslucentShapedFrameTest fails to create non-opaque frame

Reviewed-by: prr

! test/jdk/java/awt/Window/TranslucentShapedFrameTest/TSFrame.java
! test/jdk/java/awt/Window/TranslucentShapedFrameTest/TranslucentShapedFrameTest.java

Changeset: 7a580ca8
Author:    Vladimir Kozlov <kvn at openjdk.org>
Date:      2020-10-20 00:12:37 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/7a580ca8

8255027: Problem list for Graal test gc/stress/TestStressG1Humongous.java

Reviewed-by: dlong

! test/hotspot/jtreg/ProblemList-graal.txt

Changeset: c87cdf70
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
Date:      2020-10-20 01:08:19 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/c87cdf70

8254029: ObjectMonitor cleanup/minor bug-fix changes extracted from JDK-8253064

Reviewed-by: dholmes, eosterlund

! src/hotspot/share/runtime/init.cpp
! src/hotspot/share/runtime/objectMonitor.hpp
! src/hotspot/share/runtime/serviceThread.cpp
! src/hotspot/share/runtime/synchronizer.cpp
! src/hotspot/share/runtime/synchronizer.hpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmOperations.hpp
! src/hotspot/share/runtime/vmThread.cpp

Changeset: 5b51085c
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-20 05:25:57 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/5b51085c

8254997: Remove unimplemented OSContainer::read_memory_limit_in_bytes

Reviewed-by: sgehwolf

! src/hotspot/os/linux/osContainer_linux.hpp

Changeset: b65dcfa3
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-20 05:26:59 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/b65dcfa3

8197981: Missing return statement in __sync_val_compare_and_swap_8

Reviewed-by: andrew, dholmes

! src/hotspot/os_cpu/bsd_zero/os_bsd_zero.cpp
! src/hotspot/os_cpu/linux_zero/os_linux_zero.cpp

Changeset: 0a75b37f
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-20 05:28:22 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/0a75b37f

8254776: Remove unimplemented LowMemoryDetector::check_memory_usage

Reviewed-by: sspitsyn, cjplummer

! src/hotspot/share/services/lowMemoryDetector.hpp

Changeset: 355f44dd
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-20 05:31:39 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/355f44dd

8254994: [x86] C1 StubAssembler::call_RT, "call_offset might not be initialized"

Reviewed-by: chagedorn, kvn

! src/hotspot/cpu/x86/c1_Runtime1_x86.cpp

Changeset: 98ec4a67
Author:    Roberto Casta?eda Lozano <roberto.castaneda.lozano at oracle.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2020-10-20 06:08:25 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/98ec4a67

8254805: compiler/debug/TestStressCM.java is still failing

Use the code motion trace produced by TraceOptoPipelining (excluding traces of
stubs) to assert that two compilations with the same seed cause StressLCM and
StressGCM to take the same randomized decisions. Previously, the entire output
produced by PrintOptoStatistics was used instead, which has shown to be too
fragile. Also, disable inlining in both TestStressCM.java and the similar
TestStressIGVN.java to prevent flaky behavior, and run both tests for ten
different seeds to improve coverage.

Reviewed-by: kvn, thartmann

! test/hotspot/jtreg/compiler/debug/TestStressCM.java
! test/hotspot/jtreg/compiler/debug/TestStressIGVN.java

Changeset: 5fedfa70
Author:    Nhat Nguyen <hoangnhat2911 at gmail.com>
Committer: Tobias Hartmann <thartmann at openjdk.org>
Date:      2020-10-20 06:18:49 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/5fedfa70

8251271: C2: Compile::_for_igvn list is corrupted after RenumberLiveNodes

Reviewed-by: vlivanov, thartmann

! src/hotspot/share/opto/compile.cpp
! src/hotspot/share/opto/phaseX.cpp

Changeset: 7ba6a6bf
Author:    Thomas Stuefe <stuefe at openjdk.org>
Date:      2020-10-20 06:48:09 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/7ba6a6bf

8251158: Implementation of JEP 387: Elastic Metaspace

Reviewed-by: lkorinth, coleenp, iklam, rrich

! src/hotspot/share/classfile/classLoaderData.cpp
! src/hotspot/share/classfile/classLoaderData.hpp
! src/hotspot/share/classfile/classLoaderDataGraph.cpp
! src/hotspot/share/classfile/classLoaderDataGraph.hpp
! src/hotspot/share/classfile/classLoaderStats.cpp
! src/hotspot/share/gc/g1/g1CollectedHeap.cpp
! src/hotspot/share/gc/parallel/psParallelCompact.cpp
! src/hotspot/share/gc/shared/collectedHeap.cpp
! src/hotspot/share/gc/shared/gcVMOperations.cpp
! src/hotspot/share/gc/shared/gcVMOperations.hpp
! src/hotspot/share/gc/shared/genCollectedHeap.cpp
! src/hotspot/share/gc/shared/generationSpec.cpp
! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.cpp
! src/hotspot/share/gc/shared/jvmFlagConstraintsGC.hpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp
! src/hotspot/share/gc/shenandoah/shenandoahHeap.hpp
! src/hotspot/share/gc/shenandoah/shenandoahUnload.cpp
! src/hotspot/share/gc/z/zCollectedHeap.cpp
! src/hotspot/share/gc/z/zCollectedHeap.hpp
! src/hotspot/share/gc/z/zStat.cpp
! src/hotspot/share/gc/z/zUnload.cpp
! src/hotspot/share/jfr/recorder/checkpoint/types/jfrType.cpp
! src/hotspot/share/jvmci/jvmciCompilerToVM.hpp
! src/hotspot/share/memory/allocation.hpp
- src/hotspot/share/memory/binaryTreeDictionary.hpp
- src/hotspot/share/memory/binaryTreeDictionary.inline.hpp
+ src/hotspot/share/memory/classLoaderMetaspace.cpp
+ src/hotspot/share/memory/classLoaderMetaspace.hpp
- src/hotspot/share/memory/freeList.hpp
- src/hotspot/share/memory/freeList.inline.hpp
! src/hotspot/share/memory/metadataFactory.hpp
! src/hotspot/share/memory/metaspace.cpp
! src/hotspot/share/memory/metaspace.hpp
+ src/hotspot/share/memory/metaspace/allocationGuard.hpp
+ src/hotspot/share/memory/metaspace/binList.hpp
- src/hotspot/share/memory/metaspace/blockFreelist.cpp
- src/hotspot/share/memory/metaspace/blockFreelist.hpp
+ src/hotspot/share/memory/metaspace/blockTree.cpp
+ src/hotspot/share/memory/metaspace/blockTree.hpp
+ src/hotspot/share/memory/metaspace/chunkHeaderPool.cpp
+ src/hotspot/share/memory/metaspace/chunkHeaderPool.hpp
! src/hotspot/share/memory/metaspace/chunkManager.cpp
! src/hotspot/share/memory/metaspace/chunkManager.hpp
+ src/hotspot/share/memory/metaspace/chunklevel.cpp
+ src/hotspot/share/memory/metaspace/chunklevel.hpp
+ src/hotspot/share/memory/metaspace/commitLimiter.cpp
+ src/hotspot/share/memory/metaspace/commitLimiter.hpp
+ src/hotspot/share/memory/metaspace/commitMask.cpp
+ src/hotspot/share/memory/metaspace/commitMask.hpp
+ src/hotspot/share/memory/metaspace/counters.hpp
+ src/hotspot/share/memory/metaspace/freeBlocks.cpp
+ src/hotspot/share/memory/metaspace/freeBlocks.hpp
+ src/hotspot/share/memory/metaspace/freeChunkList.cpp
+ src/hotspot/share/memory/metaspace/freeChunkList.hpp
+ src/hotspot/share/memory/metaspace/internalStats.cpp
+ src/hotspot/share/memory/metaspace/internalStats.hpp
- src/hotspot/share/memory/metaspace/metaDebug.cpp
- src/hotspot/share/memory/metaspace/metaDebug.hpp
- src/hotspot/share/memory/metaspace/metabase.hpp
- src/hotspot/share/memory/metaspace/metablock.hpp
! src/hotspot/share/memory/metaspace/metachunk.cpp
! src/hotspot/share/memory/metaspace/metachunk.hpp
+ src/hotspot/share/memory/metaspace/metachunkList.cpp
+ src/hotspot/share/memory/metaspace/metachunkList.hpp
+ src/hotspot/share/memory/metaspace/metaspaceArena.cpp
+ src/hotspot/share/memory/metaspace/metaspaceArena.hpp
+ src/hotspot/share/memory/metaspace/metaspaceArenaGrowthPolicy.cpp
+ src/hotspot/share/memory/metaspace/metaspaceArenaGrowthPolicy.hpp
! src/hotspot/share/memory/metaspace/metaspaceCommon.cpp
! src/hotspot/share/memory/metaspace/metaspaceCommon.hpp
+ src/hotspot/share/memory/metaspace/metaspaceContext.cpp
+ src/hotspot/share/memory/metaspace/metaspaceContext.hpp
! src/hotspot/share/memory/metaspace/metaspaceDCmd.cpp
! src/hotspot/share/memory/metaspace/metaspaceDCmd.hpp
+ src/hotspot/share/memory/metaspace/metaspaceReporter.cpp
+ src/hotspot/share/memory/metaspace/metaspaceReporter.hpp
+ src/hotspot/share/memory/metaspace/metaspaceSettings.cpp
+ src/hotspot/share/memory/metaspace/metaspaceSettings.hpp
! src/hotspot/share/memory/metaspace/metaspaceSizesSnapshot.cpp
! src/hotspot/share/memory/metaspace/metaspaceSizesSnapshot.hpp
! src/hotspot/share/memory/metaspace/metaspaceStatistics.cpp
! src/hotspot/share/memory/metaspace/metaspaceStatistics.hpp
- src/hotspot/share/memory/metaspace/occupancyMap.cpp
- src/hotspot/share/memory/metaspace/occupancyMap.hpp
! src/hotspot/share/memory/metaspace/printCLDMetaspaceInfoClosure.cpp
! src/hotspot/share/memory/metaspace/printCLDMetaspaceInfoClosure.hpp
! src/hotspot/share/memory/metaspace/printMetaspaceInfoKlassClosure.cpp
+ src/hotspot/share/memory/metaspace/rootChunkArea.cpp
+ src/hotspot/share/memory/metaspace/rootChunkArea.hpp
+ src/hotspot/share/memory/metaspace/runningCounters.cpp
+ src/hotspot/share/memory/metaspace/runningCounters.hpp
- src/hotspot/share/memory/metaspace/smallBlocks.cpp
- src/hotspot/share/memory/metaspace/smallBlocks.hpp
- src/hotspot/share/memory/metaspace/spaceManager.cpp
- src/hotspot/share/memory/metaspace/spaceManager.hpp
+ src/hotspot/share/memory/metaspace/testHelpers.cpp
+ src/hotspot/share/memory/metaspace/testHelpers.hpp
! src/hotspot/share/memory/metaspace/virtualSpaceList.cpp
! src/hotspot/share/memory/metaspace/virtualSpaceList.hpp
! src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp
! src/hotspot/share/memory/metaspace/virtualSpaceNode.hpp
! src/hotspot/share/memory/metaspaceChunkFreeListSummary.hpp
! src/hotspot/share/memory/metaspaceClosure.hpp
! src/hotspot/share/memory/metaspaceCounters.cpp
! src/hotspot/share/memory/metaspaceCounters.hpp
- src/hotspot/share/memory/metaspaceGCThresholdUpdater.hpp
! src/hotspot/share/memory/metaspaceTracer.hpp
! src/hotspot/share/memory/universe.cpp
! src/hotspot/share/prims/whitebox.cpp
! src/hotspot/share/runtime/globals.hpp
! src/hotspot/share/runtime/vmOperations.cpp
! src/hotspot/share/runtime/vmStructs.cpp
! src/hotspot/share/services/memReporter.cpp
! src/hotspot/share/services/memoryService.hpp
! src/hotspot/share/services/virtualMemoryTracker.cpp
! src/hotspot/share/services/virtualMemoryTracker.hpp
- test/hotspot/gtest/memory/test_chunkManager.cpp
- test/hotspot/gtest/memory/test_is_metaspace_obj.cpp
- test/hotspot/gtest/memory/test_metachunk.cpp
- test/hotspot/gtest/memory/test_metaspace.cpp
- test/hotspot/gtest/memory/test_metaspace_allocation.cpp
- test/hotspot/gtest/memory/test_spaceManager.cpp
+ test/hotspot/gtest/metaspace/metaspaceGtestCommon.cpp
+ test/hotspot/gtest/metaspace/metaspaceGtestCommon.hpp
+ test/hotspot/gtest/metaspace/metaspaceGtestContexts.cpp
+ test/hotspot/gtest/metaspace/metaspaceGtestContexts.hpp
+ test/hotspot/gtest/metaspace/metaspaceGtestRangeHelpers.hpp
+ test/hotspot/gtest/metaspace/metaspaceGtestSparseArray.hpp
+ test/hotspot/gtest/metaspace/test_allocationGuard.cpp
+ test/hotspot/gtest/metaspace/test_arenagrowthpolicy.cpp
+ test/hotspot/gtest/metaspace/test_binlist.cpp
+ test/hotspot/gtest/metaspace/test_blocktree.cpp
+ test/hotspot/gtest/metaspace/test_chunkManager_stress.cpp
+ test/hotspot/gtest/metaspace/test_chunkheaderpool.cpp
+ test/hotspot/gtest/metaspace/test_commitmask.cpp
+ test/hotspot/gtest/metaspace/test_freeblocks.cpp
+ test/hotspot/gtest/metaspace/test_internstats.cpp
+ test/hotspot/gtest/metaspace/test_is_metaspace_obj.cpp
+ test/hotspot/gtest/metaspace/test_metachunk.cpp
+ test/hotspot/gtest/metaspace/test_metachunklist.cpp
+ test/hotspot/gtest/metaspace/test_metaspaceUtils.cpp
+ test/hotspot/gtest/metaspace/test_metaspace_misc.cpp
+ test/hotspot/gtest/metaspace/test_metaspacearena.cpp
+ test/hotspot/gtest/metaspace/test_metaspacearena_stress.cpp
+ test/hotspot/gtest/metaspace/test_virtualspacenode.cpp
! test/hotspot/jtreg/TEST.groups
! test/hotspot/jtreg/gc/TestSystemGC.java
! test/hotspot/jtreg/gc/class_unloading/TestG1ClassUnloadingHWM.java
! test/hotspot/jtreg/gc/metaspace/CompressedClassSpaceSizeInJmapHeap.java
! test/hotspot/jtreg/gtest/GTestWrapper.java
+ test/hotspot/jtreg/gtest/MetaspaceGtests.java
! test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestOptionsWithRanges.java
! test/hotspot/jtreg/runtime/CompressedOops/CompressedClassSpaceSize.java
! test/hotspot/jtreg/runtime/Metaspace/MaxMetaspaceSizeTest.java
! test/hotspot/jtreg/runtime/Metaspace/PrintMetaspaceDcmd.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/Allocation.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/AllocationProfile.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestArena.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestContext.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestManyArenasManyThreads.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestOneArenaManyThreads.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/MetaspaceTestWithThreads.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocator.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/RandomAllocatorThread.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/RandomHelper.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/Settings.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocation.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT1.java
+ test/hotspot/jtreg/runtime/Metaspace/elastic/TestMetaspaceAllocationMT2.java
! test/hotspot/jtreg/runtime/cds/MaxMetaspaceSize.java
! test/hotspot/jtreg/runtime/cds/appcds/sharedStrings/LargePages.java
! test/hotspot/jtreg/vmTestbase/metaspace/gc/MetaspaceBaseGC.java
! test/jdk/java/lang/management/MemoryMXBean/LowMemoryTest2.sh
! test/lib/sun/hotspot/WhiteBox.java

Changeset: 5d1397fa
Author:    Aleksey Shipilev <shade at openjdk.org>
Date:      2020-10-20 06:55:36 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/5d1397fa

8254282: Add Linux x86_32 builds to submit workflow

Reviewed-by: erikj, rwestberg

! .github/workflows/submit.yml

Changeset: 017d151e
Author:    Doug Simon <dnsimon at openjdk.org>
Date:      2020-10-20 08:38:14 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/017d151e

8254842: [JVMCI] copy thread name when attaching libgraal thread to HotSpot

Reviewed-by: kvn, never

! src/hotspot/share/jvmci/jvmciCompilerToVM.cpp
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/CompilerToVM.java
! src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.hotspot/src/jdk/vm/ci/hotspot/HotSpotJVMCIRuntime.java

Changeset: 21e67e54
Author:    Pankaj Bansal <pbansal at openjdk.org>
Date:      2020-10-20 09:05:51 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/21e67e54

8225790: Two NestedDialogs tests fail on Ubuntu

Reviewed-by: serb

! test/jdk/java/awt/Dialog/NestedDialogs/Modal/NestedModalDialogTest.java
! test/jdk/java/awt/Dialog/NestedDialogs/Modeless/NestedModelessDialogTest.java
- test/jdk/java/awt/regtesthelpers/VisibilityValidator.java
- test/jdk/java/awt/regtesthelpers/Waypoint.java

Changeset: 3f9c8a39
Author:    Claes Redestad <redestad at openjdk.org>
Date:      2020-10-20 09:27:35 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/3f9c8a39

8254966: Remove unused code from Matcher

Reviewed-by: neliasso, kvn

! src/hotspot/cpu/aarch64/aarch64.ad
! src/hotspot/cpu/arm/arm.ad
! src/hotspot/cpu/arm/arm_32.ad
! src/hotspot/cpu/ppc/ppc.ad
! src/hotspot/cpu/s390/s390.ad
! src/hotspot/cpu/x86/x86_32.ad
! src/hotspot/cpu/x86/x86_64.ad
! src/hotspot/share/adlc/adlparse.cpp
! src/hotspot/share/adlc/formsopt.hpp
! src/hotspot/share/adlc/output_c.cpp
! src/hotspot/share/opto/matcher.hpp

Changeset: 3ee0380e
Author:    Vipin Menon <vipinmv1 at in.ibm.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
Date:      2020-10-20 11:14:28 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/3ee0380e

8234393: [macos] printing ignores printer tray

Reviewed-by: psadhukhan, prr

! src/java.desktop/macosx/classes/sun/lwawt/macosx/CPrinterJob.java
! src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m
! src/java.desktop/share/classes/sun/print/CustomMediaTray.java
! test/jdk/java/awt/print/PrinterJob/TestMediaTraySelection.java


From neliasso at openjdk.java.net  Tue Oct 20 16:04:14 2020
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Tue, 20 Oct 2020 16:04:14 GMT
Subject: RFR: 8255000: C2: Unify IGVN processing when loop opts are over
In-Reply-To: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
References: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
Message-ID: <T3pUgJPKWZY3NxhrG-t4Jc_C9yClgT-pu1ksGdQEQbY=.affcf62b-e8de-4547-b3fb-d5703a5cc7de@github.com>

On Mon, 19 Oct 2020 20:27:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> There is a number of use cases when ideal nodes (either individual or even the whole classes) delay some
> transformations until loop optimizations are over.
> Unfortunately, there are multiple solutions in the code base with their pros and cons: either a custom per-node class
> logic (e.g., for range check dependent `CastII` or `Opaque4` nodes) or `Compile::major_progress() == 0` as a signal
> that loop opts are over.     I propose to introduce a unified approach to reliably process nodes that require (or may
> benefit from) IGVN pass once loop opts are finally over and migrate existing use cases to it.
> After some experimentation, I decided not to rely on `Compile::major_progress()` because:
>   * it's hard to reason about its properties (there are many places where it is adjusted);
>   * attempts to verify its monotonicity using asserts triggered too many sporadic failures.
> 
> So, I wasn't persuaded that `Compile::major_progress() == 0` is reliable enough and introduced a dedicated flag
> (`Compile::post_loop_opts_phase()`) which signals that loop opts are over.
> (The patch - 69a93d4 commit - is on top of 8255026 cleanup which is reviewed separately.)
> 
> Testing: tier1-tier5

There is a lot to like in this cleanup. Thanks!

Reviewed.

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

Marked as reviewed by neliasso (Reviewer).

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

From duke at openjdk.java.net  Tue Oct 20 17:12:27 2020
From: duke at openjdk.java.net (duke)
Date: Tue, 20 Oct 2020 17:12:27 GMT
Subject: git: openjdk/shenandoah: master: Adjust jcheck config to allow
 commits without issue ID and merge commits
Message-ID: <b4486003-29fc-4a47-b337-a9d082481f13@openjdk.java.net>

Changeset: 77a241de
Author:    Roman Kennke <rkennke at redhat.com>
Date:      2020-10-20 19:10:52 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/77a241de

Adjust jcheck config to allow commits without issue ID and merge commits

! .jcheck/conf


From zgu at openjdk.java.net  Tue Oct 20 23:54:18 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 20 Oct 2020 23:54:18 GMT
Subject: RFR: 8255070: Shenandoah: use single thread for concurrent CLD
 liveness test	
Message-ID: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>

Since the concurrent liveness test does not touch any oops, there is no point to use multi-thread for the task, they
just duplicate the work.

Also, multi-thread version requires to acquire ClassLoaderGraph_lock early, which is deadlock prone.

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

Commit messages:
 - Fix include
 - 8255070: Shenandoah: use single thread for concurrent CLD liveness test

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

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

From azeemj at openjdk.java.net  Wed Oct 21 00:09:12 2020
From: azeemj at openjdk.java.net (Azeem Jiva)
Date: Wed, 21 Oct 2020 00:09:12 GMT
Subject: RFR: 8255070: Shenandoah: use single thread for concurrent CLD
 liveness test	
In-Reply-To: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
References: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
Message-ID: <twx-im9HpSoGCyyAR0cM-qQg3BSNVI1FOJnlgkEJG_0=.4e4c602b-c2cf-4b54-9662-37d3e1f613bc@github.com>

On Tue, 20 Oct 2020 23:48:58 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Since the concurrent liveness test does not touch any oops, there is no point to use multi-thread for the task, they
> just duplicate the work.
> Also, multi-thread version requires to acquire ClassLoaderGraph_lock early, which is deadlock prone.

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

> 1942:
> 1943:   // Roots related to concurrent class unloading
> 1944:   ShenandoahClassLoaderDataRoots<true /* concurrent */, true /* single thread*/>

Should the first input be false?

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

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

From zgu at openjdk.java.net  Wed Oct 21 00:09:14 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 21 Oct 2020 00:09:14 GMT
Subject: RFR: 8255070: Shenandoah: use single thread for concurrent CLD
 liveness test	
In-Reply-To: <twx-im9HpSoGCyyAR0cM-qQg3BSNVI1FOJnlgkEJG_0=.4e4c602b-c2cf-4b54-9662-37d3e1f613bc@github.com>
References: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
 <twx-im9HpSoGCyyAR0cM-qQg3BSNVI1FOJnlgkEJG_0=.4e4c602b-c2cf-4b54-9662-37d3e1f613bc@github.com>
Message-ID: <uWAkbQiiD6u-rsKDAUvNA1D29ufLacVl72i8lyC9LgM=.e296e058-4987-4f53-89bf-929004d42008@github.com>

On Wed, 21 Oct 2020 00:04:09 GMT, Azeem Jiva <azeemj at openjdk.org> wrote:

>> Since the concurrent liveness test does not touch any oops, there is no point to use multi-thread for the task, they
>> just duplicate the work.
>> Also, multi-thread version requires to acquire ClassLoaderGraph_lock early, which is deadlock prone.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1944:
> 
>> 1942:
>> 1943:   // Roots related to concurrent class unloading
>> 1944:   ShenandoahClassLoaderDataRoots<true /* concurrent */, true /* single thread*/>
> 
> Should the first input be false?

No. It runs concurrently, so will need to acquire ClassLoaderGraph_lock.

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

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

From iveresov at openjdk.java.net  Wed Oct 21 00:28:12 2020
From: iveresov at openjdk.java.net (Igor Veresov)
Date: Wed, 21 Oct 2020 00:28:12 GMT
Subject: RFR: 8255000: C2: Unify IGVN processing when loop opts are over
In-Reply-To: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
References: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
Message-ID: <uwmR-Yog_pFDmOk6vUzal9tL6uKe_mydyQWcgFgat68=.c726b384-316e-4ec0-9e37-741b87b18447@github.com>

On Mon, 19 Oct 2020 20:27:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> There is a number of use cases when ideal nodes (either individual or even the whole classes) delay some
> transformations until loop optimizations are over.
> Unfortunately, there are multiple solutions in the code base with their pros and cons: either a custom per-node class
> logic (e.g., for range check dependent `CastII` or `Opaque4` nodes) or `Compile::major_progress() == 0` as a signal
> that loop opts are over.     I propose to introduce a unified approach to reliably process nodes that require (or may
> benefit from) IGVN pass once loop opts are finally over and migrate existing use cases to it.
> After some experimentation, I decided not to rely on `Compile::major_progress()` because:
>   * it's hard to reason about its properties (there are many places where it is adjusted);
>   * attempts to verify its monotonicity using asserts triggered too many sporadic failures.
> 
> So, I wasn't persuaded that `Compile::major_progress() == 0` is reliable enough and introduced a dedicated flag
> (`Compile::post_loop_opts_phase()`) which signals that loop opts are over.
> (The patch - 69a93d4 commit - is on top of 8255026 cleanup which is reviewed separately.)
> 
> Testing: tier1-tier5

Marked as reviewed by iveresov (Reviewer).

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

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

From kvn at openjdk.java.net  Wed Oct 21 00:56:16 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 21 Oct 2020 00:56:16 GMT
Subject: RFR: 8255000: C2: Unify IGVN processing when loop opts are over
In-Reply-To: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
References: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
Message-ID: <Ib6kZc9dur1COEpSvJqnL37Z7w_keOmlRVvgLnT-eSI=.c1391d93-93b9-4c0a-b165-9306873cc679@github.com>

On Mon, 19 Oct 2020 20:27:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> There is a number of use cases when ideal nodes (either individual or even the whole classes) delay some
> transformations until loop optimizations are over.
> Unfortunately, there are multiple solutions in the code base with their pros and cons: either a custom per-node class
> logic (e.g., for range check dependent `CastII` or `Opaque4` nodes) or `Compile::major_progress() == 0` as a signal
> that loop opts are over.     I propose to introduce a unified approach to reliably process nodes that require (or may
> benefit from) IGVN pass once loop opts are finally over and migrate existing use cases to it.
> After some experimentation, I decided not to rely on `Compile::major_progress()` because:
>   * it's hard to reason about its properties (there are many places where it is adjusted);
>   * attempts to verify its monotonicity using asserts triggered too many sporadic failures.
> 
> So, I wasn't persuaded that `Compile::major_progress() == 0` is reliable enough and introduced a dedicated flag
> (`Compile::post_loop_opts_phase()`) which signals that loop opts are over.
> (The patch - 69a93d4 commit - is on top of 8255026 cleanup which is reviewed separately.)
> 
> Testing: tier1-tier5

Nice clean up.

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

Marked as reviewed by kvn (Reviewer).

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

From gnu.andrew at redhat.com  Wed Oct 21 07:02:33 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 21 Oct 2020 08:02:33 +0100
Subject: [RFR] [8u] 8u272-b10 Upstream Sync
Message-ID: <20201021070233.GE2428148@stopbrexit>

Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/

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

Changes in aarch64-shenandoah-jdk8u272-b10:
  - JDK-8233624: Enhance JNI linkage
  - JDK-8236196: Improve string pooling
  - JDK-8236862: Enhance support of Proxy class
  - JDK-8237990: Enhanced LDAP contexts
  - JDK-8237995: Enhance certificate processing
  - JDK-8240124: Better VM Interning
  - JDK-8241114: Better range handling
  - JDK-8242680: Improved URI Support
  - JDK-8242685: Better Path Validation
  - JDK-8242695: Enhanced buffer support
  - JDK-8243302: Advanced class supports
  - JDK-8244136: Improved Buffer supports
  - JDK-8244479: Further constrain certificates
  - JDK-8244955: Additional Fix for JDK-8240124
  - JDK-8245407: Enhance zoning of times
  - JDK-8245412: Better class definitions
  - JDK-8245417: Improve certificate chain handling
  - JDK-8248574: Improve jpeg processing
  - JDK-8249927: Specify limits of jdk.serialProxyInterfaceLimit
  - JDK-8253019: Enhanced JPEG decoding
  - JDK-8254673: Call to JvmtiExport::post_vm_start() was removed by the fix for JDK-8249158
  - JDK-8254937: Revert JDK-8148854 for 8u272

Main issues of note:

Change in g1StringDedupTable.cpp to replace AltHashing::murmur3_32
with AltHashing::halfsiphash_32 had to be duplicated in
src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.cpp
for the merge to build.

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/Connection.java                   |   36 +++
 b/src/share/classes/com/sun/jndi/ldap/LdapClient.java                   |    8 
 b/src/share/classes/com/sun/jndi/ldap/LdapCtx.java                      |  115 +++++++++-
 b/src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java     |    6 
 b/src/share/classes/java/io/ObjectInputStream.java                      |   43 +++
 b/src/share/classes/java/nio/X-Buffer.java.template                     |   28 +-
 b/src/share/classes/java/util/Calendar.java                             |    4 
 b/src/share/classes/sun/security/ssl/CertificateMessage.java            |   19 +
 b/src/share/classes/sun/security/ssl/SSLConfiguration.java              |   11 
 b/src/share/classes/sun/security/ssl/SSLEngineInputRecord.java          |   11 
 b/src/share/classes/sun/security/ssl/SSLSocketInputRecord.java          |   11 
 b/src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java |   12 -
 b/src/share/classes/sun/security/util/UntrustedCertificates.java        |   21 -
 b/src/share/lib/security/BlacklistedCertsConverter.java                 |  113 ++++++++-
 b/src/share/lib/security/blacklisted.certs                              |   59 +++--
 b/src/share/native/sun/awt/image/jpeg/jmemnobs.c                        |    5 
 b/src/solaris/classes/sun/nio/fs/UnixUriUtils.java                      |    8 
 b/src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java          |    9 
 b/src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java           |    7 
 b/src/windows/classes/sun/nio/fs/WindowsUriSupport.java                 |    5 
 b/test/lib/security/CheckBlacklistedCerts.java                          |    7 
 22 files changed, 445 insertions(+), 94 deletions(-)

diffstat for hotspot
 a/test/runtime/ClassFile/BadHelloWorld.jcod                             |  138 ---
 a/test/runtime/ClassFile/FormatCheckingTest.java                        |   43 -
 b/.hgtags                                                               |    1 
 b/src/share/vm/classfile/altHashing.cpp                                 |  417 +++++-----
 b/src/share/vm/classfile/altHashing.hpp                                 |   41 
 b/src/share/vm/classfile/classFileParser.cpp                            |  113 ++
 b/src/share/vm/classfile/classFileParser.hpp                            |    7 
 b/src/share/vm/classfile/symbolTable.cpp                                |    6 
 b/src/share/vm/classfile/systemDictionary.cpp                           |   55 -
 b/src/share/vm/classfile/verifier.cpp                                   |    2 
 b/src/share/vm/classfile/verifier.hpp                                   |    6 
 b/src/share/vm/gc_implementation/g1/g1StringDedupTable.cpp              |    7 
 b/src/share/vm/gc_implementation/g1/g1StringDedupTable.hpp              |   10 
 b/src/share/vm/gc_implementation/shenandoah/shenandoahStrDedupTable.cpp |    2 
 b/src/share/vm/jfr/writers/jfrWriterHost.inline.hpp                     |   34 
 b/src/share/vm/memory/filemap.cpp                                       |    2 
 b/src/share/vm/oops/constantPool.cpp                                    |    2 
 b/src/share/vm/oops/constantPool.hpp                                    |    4 
 b/src/share/vm/oops/oop.cpp                                             |    2 
 b/src/share/vm/oops/symbol.cpp                                          |    2 
 b/src/share/vm/opto/addnode.cpp                                         |   38 
 b/src/share/vm/opto/loopTransform.cpp                                   |  224 ++---
 b/src/share/vm/opto/loopnode.hpp                                        |    4 
 b/src/share/vm/prims/nativeLookup.cpp                                   |  144 +++
 b/src/share/vm/runtime/globals.hpp                                      |    3 
 b/src/share/vm/runtime/reflection.cpp                                   |    2 
 b/src/share/vm/runtime/thread.cpp                                       |    1 
 27 files changed, 671 insertions(+), 639 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 vlivanov at openjdk.java.net  Wed Oct 21 07:43:10 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 21 Oct 2020 07:43:10 GMT
Subject: RFR: 8255000: C2: Unify IGVN processing when loop opts are over
In-Reply-To: <Ib6kZc9dur1COEpSvJqnL37Z7w_keOmlRVvgLnT-eSI=.c1391d93-93b9-4c0a-b165-9306873cc679@github.com>
References: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
 <Ib6kZc9dur1COEpSvJqnL37Z7w_keOmlRVvgLnT-eSI=.c1391d93-93b9-4c0a-b165-9306873cc679@github.com>
Message-ID: <uhY7ja692iiR7c-4yIs9pRtfTPSRj5d8wJ4KvMHp0IQ=.9ea4634c-0ab3-4c38-a0db-831d9c7f5f2a@github.com>

On Wed, 21 Oct 2020 00:53:01 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> There is a number of use cases when ideal nodes (either individual or even the whole classes) delay some
>> transformations until loop optimizations are over.
>> Unfortunately, there are multiple solutions in the code base with their pros and cons: either a custom per-node class
>> logic (e.g., for range check dependent `CastII` or `Opaque4` nodes) or `Compile::major_progress() == 0` as a signal
>> that loop opts are over.     I propose to introduce a unified approach to reliably process nodes that require (or may
>> benefit from) IGVN pass once loop opts are finally over and migrate existing use cases to it.
>> After some experimentation, I decided not to rely on `Compile::major_progress()` because:
>>   * it's hard to reason about its properties (there are many places where it is adjusted);
>>   * attempts to verify its monotonicity using asserts triggered too many sporadic failures.
>> 
>> So, I wasn't persuaded that `Compile::major_progress() == 0` is reliable enough and introduced a dedicated flag
>> (`Compile::post_loop_opts_phase()`) which signals that loop opts are over.
>> (The patch - 69a93d4 commit - is on top of 8255026 cleanup which is reviewed separately.)
>> 
>> Testing: tier1-tier5
>
> Nice clean up.

Thanks for the reviews, Nils, Igor, and Vladimir.

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

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

From vlivanov at openjdk.java.net  Wed Oct 21 08:14:30 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 21 Oct 2020 08:14:30 GMT
Subject: RFR: 8255000: C2: Unify IGVN processing when loop opts are over
 [v2]
In-Reply-To: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
References: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
Message-ID: <yl61BxYw4YUmIzaxgjjVNEIsUXFF860lZjYhPgPLQJ4=.8c980d1a-f765-43b6-b34e-72f784fcd440@github.com>

> There is a number of use cases when ideal nodes (either individual or even the whole classes) delay some
> transformations until loop optimizations are over.
> Unfortunately, there are multiple solutions in the code base with their pros and cons: either a custom per-node class
> logic (e.g., for range check dependent `CastII` or `Opaque4` nodes) or `Compile::major_progress() == 0` as a signal
> that loop opts are over.     I propose to introduce a unified approach to reliably process nodes that require (or may
> benefit from) IGVN pass once loop opts are finally over and migrate existing use cases to it.
> After some experimentation, I decided not to rely on `Compile::major_progress()` because:
>   * it's hard to reason about its properties (there are many places where it is adjusted);
>   * attempts to verify its monotonicity using asserts triggered too many sporadic failures.
> 
> So, I wasn't persuaded that `Compile::major_progress() == 0` is reliable enough and introduced a dedicated flag
> (`Compile::post_loop_opts_phase()`) which signals that loop opts are over.
> (The patch - 69a93d4 commit - is on top of 8255026 cleanup which is reviewed separately.)
> 
> Testing: tier1-tier5

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

 - Merge branch 'master' into 8255000+8255026
 - Unify post loop opts IGVN
 - 8255026: C2: Miscellaneous cleanups in Compile and PhaseIdealLoop code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/751/files
  - new: https://git.openjdk.java.net/jdk/pull/751/files/69a93d4d..590a6493

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

  Stats: 35020 lines in 471 files changed: 24314 ins; 8566 del; 2140 mod
  Patch: https://git.openjdk.java.net/jdk/pull/751.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/751/head:pull/751

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

From vlivanov at openjdk.java.net  Wed Oct 21 08:14:31 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 21 Oct 2020 08:14:31 GMT
Subject: Integrated: 8255000: C2: Unify IGVN processing when loop opts are over
In-Reply-To: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
References: <5hxd0p94QlH5wKSuHZOGXBfPxeuFUxTdLtIEH7Lxxxo=.e8fbd981-e866-486e-9e08-0c3376a2c529@github.com>
Message-ID: <tih0LbKZv6qBeQvPl2zLykvlycpLAmqHrI32xQHCSfg=.7ca206ad-31a3-4152-b49c-c75be5d8bf17@github.com>

On Mon, 19 Oct 2020 20:27:40 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> There is a number of use cases when ideal nodes (either individual or even the whole classes) delay some
> transformations until loop optimizations are over.
> Unfortunately, there are multiple solutions in the code base with their pros and cons: either a custom per-node class
> logic (e.g., for range check dependent `CastII` or `Opaque4` nodes) or `Compile::major_progress() == 0` as a signal
> that loop opts are over.     I propose to introduce a unified approach to reliably process nodes that require (or may
> benefit from) IGVN pass once loop opts are finally over and migrate existing use cases to it.
> After some experimentation, I decided not to rely on `Compile::major_progress()` because:
>   * it's hard to reason about its properties (there are many places where it is adjusted);
>   * attempts to verify its monotonicity using asserts triggered too many sporadic failures.
> 
> So, I wasn't persuaded that `Compile::major_progress() == 0` is reliable enough and introduced a dedicated flag
> (`Compile::post_loop_opts_phase()`) which signals that loop opts are over.
> (The patch - 69a93d4 commit - is on top of 8255026 cleanup which is reviewed separately.)
> 
> Testing: tier1-tier5

This pull request has now been integrated.

Changeset: 7e264043
Author:    Vladimir Ivanov <vlivanov at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e264043
Stats:     274 lines in 13 files changed: 74 ins; 82 del; 118 mod

8255000: C2: Unify IGVN processing when loop opts are over

Reviewed-by: neliasso, iveresov, kvn

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

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

From shade at redhat.com  Wed Oct 21 09:37:34 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 21 Oct 2020 11:37:34 +0200
Subject: [RFR] [8u] 8u272-b10 Upstream Sync
In-Reply-To: <20201021070233.GE2428148@stopbrexit>
References: <20201021070233.GE2428148@stopbrexit>
Message-ID: <e22218ad-2f25-39a2-2cbc-a278b47f710b@redhat.com>

On 10/21/20 9:02 AM, Andrew Hughes wrote:
> Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/
> 
> Merge changesets:
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/corba/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/jaxp/merge.changeset
> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/jaxws/merge.changeset

Trivially good.

> http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/jdk/merge.changeset

Looks fine in comparison with upstream CPU.

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

Looks fine. I believe Shenandoah conflict was resolved properly.

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

Trivially good.

> Ok to push?

Yes, I think so.

-- 
Thanks,
-Aleksey


From zgu at openjdk.java.net  Wed Oct 21 12:46:22 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 21 Oct 2020 12:46:22 GMT
Subject: RFR: 8255036:  Shenandoah: need to reset GC state for root verifier
Message-ID: <LHeTlw-HkAx-QZUgHB9nOW6iiKJ7v0TYoyF2CoeGkN4=.29665b8b-b954-40a4-b44e-e99f5843f443@github.com>

Shenandoah has ShenandoahGCStateResetter to reset gc state for verifier to avoid triggering barriers inadvertently, root verifier should do the same.

Also, SH::_concurrent_weak_root_in_progress flag now has implication for native barrier, ShenandoahGCStateResetter should reset this flag too.

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

Commit messages:
 - Merge branch 'master' into JDK-8255036-gcstate_resetter
 - 8255036: Shenandoah: need to reset GC state for root verifier

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

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

From rkennke at openjdk.java.net  Wed Oct 21 12:55:20 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 21 Oct 2020 12:55:20 GMT
Subject: RFR: 8255070: Shenandoah: use single thread for concurrent CLD
 liveness test	
In-Reply-To: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
References: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
Message-ID: <Q3XAgzL1cGJbbeqyDKziCbTA7E5zIxz3cUKy2edF2H4=.176e4c23-070a-4c9d-8e93-c63b6850cc07@github.com>

On Tue, 20 Oct 2020 23:48:58 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Since the concurrent liveness test does not touch any oops, there is no point to use multi-thread for the task, they just duplicate the work.
> 
> Also, multi-thread version requires to acquire ClassLoaderGraph_lock early, which is deadlock prone.

Also, I'd change the commit message to begin uppercase after Shenandoah: "Use..."

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp line 112:

> 110:       ClassLoaderDataGraph::always_strong_cld_do(clds);
> 111:     }
> 112:   } else if (_semaphore.try_acquire()) {

It looks to me that we do:
if (_semaphore.try_acquire()) {

in both branches now. Can this be reshaped to do try_acquire() and claim_all() outermost?

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp line 134:

> 132:       ClassLoaderDataGraph::cld_do(clds);
> 133:     }
> 134:   } else if (_semaphore.try_acquire()) {

Same as above. Also, the only difference to above is cld_do() vs always_strong_cld_do(), with *lots* of identical boilerplate. Can this be refactored into a generic method that takes the final target method as argument?

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

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

From rkennke at openjdk.java.net  Wed Oct 21 12:57:14 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 21 Oct 2020 12:57:14 GMT
Subject: RFR: 8255036: Shenandoah: need to reset GC state for root verifier
In-Reply-To: <LHeTlw-HkAx-QZUgHB9nOW6iiKJ7v0TYoyF2CoeGkN4=.29665b8b-b954-40a4-b44e-e99f5843f443@github.com>
References: <LHeTlw-HkAx-QZUgHB9nOW6iiKJ7v0TYoyF2CoeGkN4=.29665b8b-b954-40a4-b44e-e99f5843f443@github.com>
Message-ID: <-RN0oSbeAD9A6hbyExFfiGrWIYN6pDhlu-MNnTVQIBk=.a95dae48-1fdc-403a-b3b2-5bf7ca4154dc@github.com>

On Wed, 21 Oct 2020 12:40:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah has ShenandoahGCStateResetter to reset gc state for verifier to avoid triggering barriers inadvertently, root verifier should do the same.
> 
> Also, SH::_concurrent_weak_root_in_progress flag now has implication for native barrier, ShenandoahGCStateResetter should reset this flag too.

Looks good to me. I'd change the commit msg to begin with uppercase after Shenandoah: and form an imperative statement: "Shenandoah: Reset GC state for root verifier"

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

Marked as reviewed by rkennke (Reviewer).

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

From zgu at openjdk.java.net  Wed Oct 21 14:49:21 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 21 Oct 2020 14:49:21 GMT
Subject: Integrated: 8255036:  Shenandoah: Reset GC state for root verifier
In-Reply-To: <LHeTlw-HkAx-QZUgHB9nOW6iiKJ7v0TYoyF2CoeGkN4=.29665b8b-b954-40a4-b44e-e99f5843f443@github.com>
References: <LHeTlw-HkAx-QZUgHB9nOW6iiKJ7v0TYoyF2CoeGkN4=.29665b8b-b954-40a4-b44e-e99f5843f443@github.com>
Message-ID: <HC9_rfwje3HhuypnM2RLk7_tU14Z6yBvn2d-GF8zmqU=.49956b51-da55-4ecf-b678-ff4e05ddf1c2@github.com>

On Wed, 21 Oct 2020 12:40:04 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah has ShenandoahGCStateResetter to reset gc state for verifier to avoid triggering barriers inadvertently, root verifier should do the same.
> 
> Also, SH::_concurrent_weak_root_in_progress flag now has implication for native barrier, ShenandoahGCStateResetter should reset this flag too.

This pull request has now been integrated.

Changeset: c9269bf5
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c9269bf5
Stats:     43 lines in 3 files changed: 26 ins; 17 del; 0 mod

8255036: Shenandoah: Reset GC state for root verifier

Reviewed-by: rkennke

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

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

From zgu at openjdk.java.net  Wed Oct 21 15:28:26 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 21 Oct 2020 15:28:26 GMT
Subject: RFR: 8255070: Shenandoah: Use single thread for concurrent CLD
 liveness test	 [v2]
In-Reply-To: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
References: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
Message-ID: <STSMVKkW3QtN8Qv6ip3eyq6vMfzw-zC4PiOZSSEqJjU=.b570dfb1-008d-41b5-b948-f102351128e0@github.com>

> Since the concurrent liveness test does not touch any oops, there is no point to use multi-thread for the task, they just duplicate the work.
> 
> Also, multi-thread version requires to acquire ClassLoaderGraph_lock early, which is deadlock prone.

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

  Reduce duplicated code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/777/files
  - new: https://git.openjdk.java.net/jdk/pull/777/files/5b69d7bb..c46f8d35

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

  Stats: 50 lines in 2 files changed: 14 ins; 25 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/777.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/777/head:pull/777

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

From rkennke at openjdk.java.net  Wed Oct 21 15:42:17 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 21 Oct 2020 15:42:17 GMT
Subject: RFR: 8255070: Shenandoah: Use single thread for concurrent CLD
 liveness test	 [v2]
In-Reply-To: <STSMVKkW3QtN8Qv6ip3eyq6vMfzw-zC4PiOZSSEqJjU=.b570dfb1-008d-41b5-b948-f102351128e0@github.com>
References: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
 <STSMVKkW3QtN8Qv6ip3eyq6vMfzw-zC4PiOZSSEqJjU=.b570dfb1-008d-41b5-b948-f102351128e0@github.com>
Message-ID: <NhMVCCZY0iF3rENemSxFTcr2X4G4s5HNFSR9rErXZoI=.6c5cb07f-6c15-427e-b035-d490bbabd74c@github.com>

On Wed, 21 Oct 2020 15:28:26 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Since the concurrent liveness test does not touch any oops, there is no point to use multi-thread for the task, they just duplicate the work.
>> 
>> Also, multi-thread version requires to acquire ClassLoaderGraph_lock early, which is deadlock prone.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reduce duplicated code

src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp line 108:

> 106:       f(clds);
> 107:       if (SINGLE_THREADED) ClassLoaderDataGraph_lock->unlock();
> 108:       _semaphore.claim_all();

Would it be nicer to write this as follows?
if (SINGLE_THREADED) {
  MutexLocker ml(ClassLoaderDataGraph_lock);
  f(clds);
} else {
  f(clds);
}

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

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

From zgu at openjdk.java.net  Wed Oct 21 15:42:15 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 21 Oct 2020 15:42:15 GMT
Subject: RFR: 8255070: Shenandoah: Use single thread for concurrent CLD
 liveness test	 [v2]
In-Reply-To: <Q3XAgzL1cGJbbeqyDKziCbTA7E5zIxz3cUKy2edF2H4=.176e4c23-070a-4c9d-8e93-c63b6850cc07@github.com>
References: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
 <Q3XAgzL1cGJbbeqyDKziCbTA7E5zIxz3cUKy2edF2H4=.176e4c23-070a-4c9d-8e93-c63b6850cc07@github.com>
Message-ID: <yxUDkU7cc4h5mV2-WiHIKI3wyAGuYdfxOeZ1NWxrur4=.a5f03f2a-143f-49c4-83d1-57afd2e94bbc@github.com>

On Wed, 21 Oct 2020 12:49:35 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reduce duplicated code
>
> src/hotspot/share/gc/shenandoah/shenandoahRootProcessor.inline.hpp line 134:
> 
>> 132:       ClassLoaderDataGraph::cld_do(clds);
>> 133:     }
>> 134:   } else if (_semaphore.try_acquire()) {
> 
> Same as above. Also, the only difference to above is cld_do() vs always_strong_cld_do(), with *lots* of identical boilerplate. Can this be refactored into a generic method that takes the final target method as argument?

Refactored and retested. Thanks for the suggestion.

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

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

From zgu at openjdk.java.net  Wed Oct 21 16:43:33 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 21 Oct 2020 16:43:33 GMT
Subject: RFR: 8255070: Shenandoah: Use single thread for concurrent CLD
 liveness test	 [v3]
In-Reply-To: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
References: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
Message-ID: <vmMh9VswFMI4N51xjvW2-49OgzMIQqRYgorcfeyUHPY=.4a6f4ba6-310d-4454-b0fc-cc0fafcfdac7@github.com>

> Since the concurrent liveness test does not touch any oops, there is no point to use multi-thread for the task, they just duplicate the work.
> 
> Also, multi-thread version requires to acquire ClassLoaderGraph_lock early, which is deadlock prone.

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

  Replaced naked lock/unlock with MutexLocker

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/777/files
  - new: https://git.openjdk.java.net/jdk/pull/777/files/c46f8d35..f2dded6b

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

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

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

From zgu at openjdk.java.net  Wed Oct 21 17:07:18 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 21 Oct 2020 17:07:18 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v10]
In-Reply-To: <5LY7Ty5Q2S8j9S30uXyeX0EE8AQWQ4BFFd02NYMzVio=.2e423faa-895a-42c9-ad9f-6c85844e1ff8@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <5LY7Ty5Q2S8j9S30uXyeX0EE8AQWQ4BFFd02NYMzVio=.2e423faa-895a-42c9-ad9f-6c85844e1ff8@github.com>
Message-ID: <rFCbv91JRKYX3wxMwb8NIjGRgyTW7PI8BqSw0o7j_ew=.408b542a-0b07-43d6-b60a-9ab2563a7b84@github.com>

On Wed, 14 Oct 2020 14:32:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
>> 
>> There are 3 main items that contribute to pause time linear to number of references, or worse:
>> - We need to scan and consider each reference on the various 'discovered' lists.
>> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
>> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
>> 
>> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
>> 
>> The solution to this is two-fold:
>> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
>> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
>> 
>> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add fallback support for new properties in ObjArrayChunkedTask
>  - Fix 32bit interpreter LRB-native call

src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp line 64:

> 62:   void load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr);
> 63:   void load_reference_barrier_native(MacroAssembler* masm, Register dst, Address load_addr, bool native);
> 64: 

is_native parameter seems weird. Maybe invert to is_weak_ref? 
BTW, I think I am seeing compressed oops in conc-stack-scanning.

src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 399:

> 397: 
> 398:   save_xmm_registers(masm);
> 399:   if (UseCompressedOops && !native) {

What's problem you saw with compressed oop + native?

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 42:

> 40:     WEAK
> 41:   };
> 42: private:

Declare as enum class for stronger typing?

src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 750:

> 748:   __ load_parameter(0, r0);
> 749:   __ load_parameter(1, r1);
> 750:   if (kind == ShenandoahBarrierSet::NATIVE) {

Use "switch" statement to be consistent with above

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp line 139:

> 137: 
> 138:   // template <typename T>
> 139:   // void keep_alive(oop reference, ReferenceType type) const;

Remove this

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 100:

> 98:   oop load_reference_barrier_not_null(oop obj);
> 99: 
> 100:   template <class T>

class -> typename also?

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

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

From gnu.andrew at redhat.com  Wed Oct 21 17:59:34 2020
From: gnu.andrew at redhat.com (Andrew Hughes)
Date: Wed, 21 Oct 2020 18:59:34 +0100
Subject: [RFR] [8u] 8u272-b10 Upstream Sync
In-Reply-To: <e22218ad-2f25-39a2-2cbc-a278b47f710b@redhat.com>
References: <20201021070233.GE2428148@stopbrexit>
 <e22218ad-2f25-39a2-2cbc-a278b47f710b@redhat.com>
Message-ID: <20201021175934.GG2463725@stopbrexit>

On 11:37 Wed 21 Oct     , Aleksey Shipilev wrote:
> On 10/21/20 9:02 AM, Andrew Hughes wrote:
> > Webrevs: https://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/
> > 
> > Merge changesets:
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/corba/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/jaxp/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/jaxws/merge.changeset
> 
> Trivially good.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/jdk/merge.changeset
> 
> Looks fine in comparison with upstream CPU.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/hotspot/merge.changeset
> 
> Looks fine. I believe Shenandoah conflict was resolved properly.
> 
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/langtools/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/nashorn/merge.changeset
> > http://cr.openjdk.java.net/~andrew/shenandoah-8/u272-b10/root/merge.changeset
> 
> Trivially good.
> 
> > Ok to push?
> 
> Yes, I think so.
> 
> -- 
> Thanks,
> -Aleksey
> 

Pushed.

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 rkennke at openjdk.java.net  Wed Oct 21 18:05:16 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 21 Oct 2020 18:05:16 GMT
Subject: RFR: 8255070: Shenandoah: Use single thread for concurrent CLD
 liveness test	 [v3]
In-Reply-To: <vmMh9VswFMI4N51xjvW2-49OgzMIQqRYgorcfeyUHPY=.4a6f4ba6-310d-4454-b0fc-cc0fafcfdac7@github.com>
References: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
 <vmMh9VswFMI4N51xjvW2-49OgzMIQqRYgorcfeyUHPY=.4a6f4ba6-310d-4454-b0fc-cc0fafcfdac7@github.com>
Message-ID: <y37OqPNeeRRqY7Lgim0ibyRlSVFcw2oTjhDDl0tnBJ0=.464b18fe-481d-47c1-a645-b060048a92e3@github.com>

On Wed, 21 Oct 2020 16:43:33 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Since the concurrent liveness test does not touch any oops, there is no point to use multi-thread for the task, they just duplicate the work.
>> 
>> Also, multi-thread version requires to acquire ClassLoaderGraph_lock early, which is deadlock prone.
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced naked lock/unlock with MutexLocker

Looks good to me! Thank you!

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

Marked as reviewed by rkennke (Reviewer).

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

From zgu at openjdk.java.net  Wed Oct 21 19:50:13 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 21 Oct 2020 19:50:13 GMT
Subject: Integrated: 8255070: Shenandoah: Use single thread for concurrent CLD
 liveness test	
In-Reply-To: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
References: <3kG75O-OjSwYMJzXV6g2HG_jiSmuM_uIEbLIKdkO-OI=.29799b43-9832-48eb-9ece-0ae1798234b7@github.com>
Message-ID: <QCASaIAx0FXe-DQPN9KxIdIz6_fUzpTGK9enEBmgWqc=.c304e862-a0ce-4b4d-94ca-3b09629e3e16@github.com>

On Tue, 20 Oct 2020 23:48:58 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Since the concurrent liveness test does not touch any oops, there is no point to use multi-thread for the task, they just duplicate the work.
> 
> Also, multi-thread version requires to acquire ClassLoaderGraph_lock early, which is deadlock prone.

This pull request has now been integrated.

Changeset: 615b759e
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/615b759e
Stats:     50 lines in 3 files changed: 29 ins; 16 del; 5 mod

8255070: Shenandoah: Use single thread for concurrent CLD liveness test

Reviewed-by: rkennke

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

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

From rkennke at openjdk.java.net  Wed Oct 21 20:12:22 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 21 Oct 2020 20:12:22 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v10]
In-Reply-To: <rFCbv91JRKYX3wxMwb8NIjGRgyTW7PI8BqSw0o7j_ew=.408b542a-0b07-43d6-b60a-9ab2563a7b84@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <5LY7Ty5Q2S8j9S30uXyeX0EE8AQWQ4BFFd02NYMzVio=.2e423faa-895a-42c9-ad9f-6c85844e1ff8@github.com>
 <rFCbv91JRKYX3wxMwb8NIjGRgyTW7PI8BqSw0o7j_ew=.408b542a-0b07-43d6-b60a-9ab2563a7b84@github.com>
Message-ID: <iDQSeaz6sRIbwgtP7P0hbJekbJb3Qzg05Okk3WWeurU=.ffc5135d-9f4a-414e-9a1b-30b92fee5650@github.com>

On Mon, 19 Oct 2020 14:42:25 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Add fallback support for new properties in ObjArrayChunkedTask
>>  - Fix 32bit interpreter LRB-native call
>
> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp line 64:
> 
>> 62:   void load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr);
>> 63:   void load_reference_barrier_native(MacroAssembler* masm, Register dst, Address load_addr, bool native);
>> 64: 
> 
> is_native parameter seems weird. Maybe invert to is_weak_ref? 
> BTW, I think I am seeing compressed oops in conc-stack-scanning.

I think it's clearer as it is. The motivation for this is that native references are always oops, while weak reference's referents can be oops or narrowOops. Which means that we need to call a different method for native-refs (the always-oops entry point).
The interesting differentiator is native vs. not-native, because one is always-oops, the other can be narrowOop. Weak vs not-weak is not as clear because there can also be weak/phantom native-refs.

> src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 399:
> 
>> 397: 
>> 398:   save_xmm_registers(masm);
>> 399:   if (UseCompressedOops && !native) {
> 
> What's problem you saw with compressed oop + native?

None, but see above.

> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 42:
> 
>> 40:     WEAK
>> 41:   };
>> 42: private:
> 
> Declare as enum class for stronger typing?

Ok will do.

> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 750:
> 
>> 748:   __ load_parameter(0, r0);
>> 749:   __ load_parameter(1, r1);
>> 750:   if (kind == ShenandoahBarrierSet::NATIVE) {
> 
> Use "switch" statement to be consistent with above

OK.

> src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp line 139:
> 
>> 137: 
>> 138:   // template <typename T>
>> 139:   // void keep_alive(oop reference, ReferenceType type) const;
> 
> Remove this

Ok.

> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 100:
> 
>> 98:   oop load_reference_barrier_not_null(oop obj);
>> 99: 
>> 100:   template <class T>
> 
> class -> typename also?

Right. Will do.

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

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

From rkennke at openjdk.java.net  Wed Oct 21 20:48:29 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 21 Oct 2020 20:48:29 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v11]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <rkqhZP6Rd9jeeIrR1uYxH6a4W-5WlrGIdF9QKKwJfDc=.c0dc2cc4-8fd1-4ec5-8fe4-372940a61133@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Change ShenandoahLRBKind to be an enum class instead of plain enum, and some minor touch-ups

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/46dc1b75..f2a9bb61

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=09-10

  Stats: 112 lines in 10 files changed: 47 ins; 20 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at redhat.com  Thu Oct 22 10:33:22 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Thu, 22 Oct 2020 12:33:22 +0200
Subject: RFR: Update sh/jdk8 from aarch64/jdk8-sh
Message-ID: <975b4c641ecfa503824b8de2baf7e9da6de57b34.camel@redhat.com>

Hi there,

I would like to sync aarch64-port/jdk8-shenandoah -> shenandoah/jdk8.
It is a straigt pull without any merges.

Testing: hotspot_gc_shenandoah

Do you need to see the actual incoming changesets?

Good?

Roman


From shade at redhat.com  Thu Oct 22 10:35:35 2020
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 22 Oct 2020 12:35:35 +0200
Subject: RFR: Update sh/jdk8 from aarch64/jdk8-sh
In-Reply-To: <975b4c641ecfa503824b8de2baf7e9da6de57b34.camel@redhat.com>
References: <975b4c641ecfa503824b8de2baf7e9da6de57b34.camel@redhat.com>
Message-ID: <10e40000-9103-2d0a-62df-09a6e3936d99@redhat.com>

Hi,

On 10/22/20 12:33 PM, rkennke at redhat.com wrote:
> I would like to sync aarch64-port/jdk8-shenandoah -> shenandoah/jdk8.
> It is a straight pull without any merges.

Right.

> Do you need to see the actual incoming changesets?

No.

> Good?

Yes.

-- 
Thanks,
-Aleksey


From rkennke at redhat.com  Thu Oct 22 10:45:20 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Thu, 22 Oct 2020 10:45:20 +0000
Subject: hg: shenandoah/jdk8: 6 new changesets
Message-ID: <202010221045.09MAjKrc009943@aojmv0008.oracle.com>

Changeset: 6464ce0569e7
Author:    andrew
Date:      2020-09-28 01:52 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/6464ce0569e7

Added tag jdk8u272-b09 for changeset 7f60c2d9823e

! .hgtags

Changeset: abc67ed75a37
Author:    andrew
Date:      2020-09-28 03:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/abc67ed75a37

Merge jdk8u272-b09

! .hgtags

Changeset: 92c59c4523b1
Author:    andrew
Date:      2020-09-28 03:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/92c59c4523b1

Added tag aarch64-shenandoah-jdk8u272-b09 for changeset abc67ed75a37

! .hgtags

Changeset: 21afcde96da4
Author:    andrew
Date:      2020-10-17 03:50 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/21afcde96da4

Added tag jdk8u272-b10 for changeset 6464ce0569e7

! .hgtags

Changeset: b3044e7962a6
Author:    andrew
Date:      2020-10-17 05:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/b3044e7962a6

Merge jdk8u272-b10

! .hgtags

Changeset: 85a438e74ccb
Author:    andrew
Date:      2020-10-17 05:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/rev/85a438e74ccb

Added tag aarch64-shenandoah-jdk8u272-b10 for changeset b3044e7962a6

! .hgtags


From rkennke at redhat.com  Thu Oct 22 10:45:19 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Thu, 22 Oct 2020 10:45:19 +0000
Subject: hg: shenandoah/jdk8/corba: 6 new changesets
Message-ID: <202010221045.09MAjJLc009927@aojmv0008.oracle.com>

Changeset: 75460f3d1424
Author:    andrew
Date:      2020-09-28 01:52 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/75460f3d1424

Added tag jdk8u272-b09 for changeset 244b07da2440

! .hgtags

Changeset: 7cd1ed72d0ea
Author:    andrew
Date:      2020-09-28 03:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/7cd1ed72d0ea

Merge jdk8u272-b09

! .hgtags

Changeset: 2844c270135b
Author:    andrew
Date:      2020-09-28 03:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/2844c270135b

Added tag aarch64-shenandoah-jdk8u272-b09 for changeset 7cd1ed72d0ea

! .hgtags

Changeset: df0ad8509937
Author:    andrew
Date:      2020-10-17 03:50 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/df0ad8509937

Added tag jdk8u272-b10 for changeset 75460f3d1424

! .hgtags

Changeset: dd14da250b65
Author:    andrew
Date:      2020-10-17 05:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/dd14da250b65

Merge jdk8u272-b10

! .hgtags

Changeset: 72caff464c9e
Author:    andrew
Date:      2020-10-17 05:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/corba/rev/72caff464c9e

Added tag aarch64-shenandoah-jdk8u272-b10 for changeset dd14da250b65

! .hgtags


From rkennke at redhat.com  Thu Oct 22 10:45:17 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Thu, 22 Oct 2020 10:45:17 +0000
Subject: hg: shenandoah/jdk8/jaxws: 6 new changesets
Message-ID: <202010221045.09MAjHR4009763@aojmv0008.oracle.com>

Changeset: 1dc430818e0c
Author:    andrew
Date:      2020-09-28 01:52 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/1dc430818e0c

Added tag jdk8u272-b09 for changeset d416f2a0773a

! .hgtags

Changeset: 0ebcac0e9114
Author:    andrew
Date:      2020-09-28 03:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/0ebcac0e9114

Merge jdk8u272-b09

! .hgtags

Changeset: 68541a335829
Author:    andrew
Date:      2020-09-28 03:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/68541a335829

Added tag aarch64-shenandoah-jdk8u272-b09 for changeset 0ebcac0e9114

! .hgtags

Changeset: 268fcb5dbff7
Author:    andrew
Date:      2020-10-17 03:50 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/268fcb5dbff7

Added tag jdk8u272-b10 for changeset 1dc430818e0c

! .hgtags

Changeset: 40200c415332
Author:    andrew
Date:      2020-10-17 05:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/40200c415332

Merge jdk8u272-b10

! .hgtags

Changeset: 8879e6d64de2
Author:    andrew
Date:      2020-10-17 05:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jaxws/rev/8879e6d64de2

Added tag aarch64-shenandoah-jdk8u272-b10 for changeset 40200c415332

! .hgtags


From rkennke at redhat.com  Thu Oct 22 10:45:24 2020
From: rkennke at redhat.com (rkennke at redhat.com)
Date: Thu, 22 Oct 2020 10:45:24 +0000
Subject: hg: shenandoah/jdk8/jdk: 19 new changesets
Message-ID: <202010221045.09MAjPdb009965@aojmv0008.oracle.com>

Changeset: 77b682e2d679
Author:    abakhtin
Date:      2020-09-17 12:51 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/77b682e2d679

8252886: [TESTBUG] sun/security/ec/TestEC.java : Compilation failed
Reviewed-by: shade, andrew, mbalao

! test/sun/security/ec/TestEC.java

Changeset: d5c320d784e5
Author:    andrew
Date:      2020-09-28 01:52 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/d5c320d784e5

Added tag jdk8u272-b09 for changeset 77b682e2d679

! .hgtags

Changeset: 7718608594f9
Author:    andrew
Date:      2020-09-28 03:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/7718608594f9

Merge jdk8u272-b09

! .hgtags

Changeset: 2b97a592a53b
Author:    andrew
Date:      2020-09-28 03:43 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/2b97a592a53b

Added tag aarch64-shenandoah-jdk8u272-b09 for changeset 7718608594f9

! .hgtags

Changeset: 0da7153533e6
Author:    bae
Date:      2020-08-07 11:02 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0da7153533e6

8236862: Enhance support of Proxy class
8249927: Specify limits of jdk.serialProxyInterfaceLimit
Reviewed-by: rriggs, coffeys, mbalao, andrew

! src/share/classes/java/io/ObjectInputStream.java

Changeset: ccf97104b8ea
Author:    abakhtin
Date:      2020-06-22 14:30 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/ccf97104b8ea

8237990: Enhanced LDAP contexts
Reviewed-by: dfuchs, robm, weijun, xyin, rhalade, ahgross, mbalao, andrew

! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/LdapClient.java
! src/share/classes/com/sun/jndi/ldap/LdapCtx.java
! src/share/classes/com/sun/jndi/ldap/ext/StartTlsResponseImpl.java

Changeset: eca1dcb470d8
Author:    yan
Date:      2020-09-11 18:58 +0300
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/eca1dcb470d8

8237995: Enhance certificate processing
Reviewed-by: mbalao, andrew

! src/share/classes/sun/security/util/UntrustedCertificates.java
! src/share/lib/security/BlacklistedCertsConverter.java
! src/share/lib/security/blacklisted.certs
! test/lib/security/CheckBlacklistedCerts.java

Changeset: cb50526a9629
Author:    bpb
Date:      2020-04-28 10:14 -0700
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/cb50526a9629

8242685: Better Path Validation
Reviewed-by: alanb, rhalade

! src/solaris/classes/sun/nio/fs/UnixUriUtils.java

Changeset: e333a640d78f
Author:    yan
Date:      2020-10-16 19:55 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/e333a640d78f

8242680: Improved URI Support
Reviewed-by: mbalao, andrew

! src/solaris/classes/sun/nio/fs/UnixUriUtils.java
! src/windows/classes/sun/nio/fs/WindowsUriSupport.java

Changeset: 05922d77fc13
Author:    bpb
Date:      2020-05-20 13:56 -0700
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/05922d77fc13

8242695: Enhanced buffer support
Reviewed-by: alanb, rhalade

! src/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java
! src/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java

Changeset: f6804947798c
Author:    yan
Date:      2020-06-17 08:48 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f6804947798c

8244136: Improved Buffer supports
Reviewed-by: mbalao, andrew

! src/share/classes/java/nio/X-Buffer.java.template

Changeset: a9306ab5534a
Author:    mullan
Date:      2020-05-20 08:07 -0400
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a9306ab5534a

8244479: Further constrain certificates
Reviewed-by: ascarpino, ahgross, rhalade

! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java

Changeset: 1c438aec6cb7
Author:    naoto
Date:      2020-06-02 08:48 -0700
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/1c438aec6cb7

8245407: Enhance zoning of times
Reviewed-by: rriggs, rhalade, skoivu

! src/share/classes/java/util/Calendar.java

Changeset: 0c138a67e647
Author:    yan
Date:      2020-10-17 02:55 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/0c138a67e647

8245417: Improve certificate chain handling
Reviewed-by: mbalao, andrew

! src/share/classes/sun/security/ssl/CertificateMessage.java
! src/share/classes/sun/security/ssl/SSLConfiguration.java
! src/share/classes/sun/security/ssl/SSLEngineInputRecord.java
! src/share/classes/sun/security/ssl/SSLSocketInputRecord.java

Changeset: 276130887f7b
Author:    prr
Date:      2020-07-02 12:02 -0700
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/276130887f7b

8248574: Improve jpeg processing
Reviewed-by: serb, jdv, mschoene, rhalade

! src/share/native/sun/awt/image/jpeg/jdhuff.c
! src/share/native/sun/awt/image/jpeg/jdinput.c
! src/share/native/sun/awt/image/jpeg/jdmarker.c
! src/share/native/sun/awt/image/jpeg/jmemnobs.c
! src/share/native/sun/awt/image/jpeg/jpeglib.h

Changeset: badfd40f15ac
Author:    prr
Date:      2020-09-11 16:12 +0000
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/badfd40f15ac

8253019: Enhanced JPEG decoding
Reviewed-by: rhalade, mschoene, serb, psadhukhan

! src/share/native/sun/awt/image/jpeg/jdhuff.c
! src/share/native/sun/awt/image/jpeg/jdinput.c
! src/share/native/sun/awt/image/jpeg/jdmarker.c
! src/share/native/sun/awt/image/jpeg/jpeglib.h

Changeset: a08759391dc3
Author:    andrew
Date:      2020-10-17 03:50 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/a08759391dc3

Added tag jdk8u272-b10 for changeset badfd40f15ac

! .hgtags

Changeset: f19cdaae1732
Author:    andrew
Date:      2020-10-17 05:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/f19cdaae1732

Merge jdk8u272-b10

! .hgtags
! src/share/classes/com/sun/jndi/ldap/Connection.java
! src/share/classes/com/sun/jndi/ldap/LdapCtx.java
! src/share/classes/java/io/ObjectInputStream.java
! src/share/classes/java/nio/X-Buffer.java.template
! src/share/classes/java/util/Calendar.java
! src/share/classes/sun/security/util/DisabledAlgorithmConstraints.java
! src/solaris/classes/sun/nio/fs/UnixUriUtils.java

Changeset: b840553006ba
Author:    andrew
Date:      2020-10-17 05:31 +0100
URL:       https://hg.openjdk.java.net/shenandoah/jdk8/jdk/rev/b840553006ba

Added tag aarch64-shenandoah-jdk8u272-b10 for changeset f19cdaae1732

! .hgtags


From zgu at openjdk.java.net  Thu Oct 22 12:23:15 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 22 Oct 2020 12:23:15 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v10]
In-Reply-To: <iDQSeaz6sRIbwgtP7P0hbJekbJb3Qzg05Okk3WWeurU=.ffc5135d-9f4a-414e-9a1b-30b92fee5650@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <5LY7Ty5Q2S8j9S30uXyeX0EE8AQWQ4BFFd02NYMzVio=.2e423faa-895a-42c9-ad9f-6c85844e1ff8@github.com>
 <rFCbv91JRKYX3wxMwb8NIjGRgyTW7PI8BqSw0o7j_ew=.408b542a-0b07-43d6-b60a-9ab2563a7b84@github.com>
 <iDQSeaz6sRIbwgtP7P0hbJekbJb3Qzg05Okk3WWeurU=.ffc5135d-9f4a-414e-9a1b-30b92fee5650@github.com>
Message-ID: <y_qTbSBQJ-9aNP45eu_ddOp2Ct24t-E7Zd5Ejawomyg=.323b30d4-7aba-4002-9095-69a3a4bf3c5f@github.com>

On Wed, 21 Oct 2020 20:07:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.hpp line 64:
>> 
>>> 62:   void load_reference_barrier_not_null(MacroAssembler* masm, Register dst, Address load_addr);
>>> 63:   void load_reference_barrier_native(MacroAssembler* masm, Register dst, Address load_addr, bool native);
>>> 64: 
>> 
>> is_native parameter seems weird. Maybe invert to is_weak_ref? 
>> BTW, I think I am seeing compressed oops in conc-stack-scanning.
>
> I think it's clearer as it is. The motivation for this is that native references are always oops, while weak reference's referents can be oops or narrowOops. Which means that we need to call a different method for native-refs (the always-oops entry point).
> The interesting differentiator is native vs. not-native, because one is always-oops, the other can be narrowOop. Weak vs not-weak is not as clear because there can also be weak/phantom native-refs.

The weird part is the method name, load_reference_barrier_**native**(), then you have parameter says that it may not be a native load and the parameter does nothing to hint the possible type differential. How about may_narrow_oop?

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

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

From rkennke at openjdk.java.net  Thu Oct 22 16:04:25 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 22 Oct 2020 16:04:25 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Rename native argument to maybe_narrow_oop for more clarity

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/f2a9bb61..6418428d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=10-11

  Stats: 8 lines in 4 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Thu Oct 22 16:04:26 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 22 Oct 2020 16:04:26 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v10]
In-Reply-To: <y_qTbSBQJ-9aNP45eu_ddOp2Ct24t-E7Zd5Ejawomyg=.323b30d4-7aba-4002-9095-69a3a4bf3c5f@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <5LY7Ty5Q2S8j9S30uXyeX0EE8AQWQ4BFFd02NYMzVio=.2e423faa-895a-42c9-ad9f-6c85844e1ff8@github.com>
 <rFCbv91JRKYX3wxMwb8NIjGRgyTW7PI8BqSw0o7j_ew=.408b542a-0b07-43d6-b60a-9ab2563a7b84@github.com>
 <iDQSeaz6sRIbwgtP7P0hbJekbJb3Qzg05Okk3WWeurU=.ffc5135d-9f4a-414e-9a1b-30b92fee5650@github.com>
 <y_qTbSBQJ-9aNP45eu_ddOp2Ct24t-E7Zd5Ejawomyg=.323b30d4-7aba-4002-9095-69a3a4bf3c5f@github.com>
Message-ID: <f7lxZYHOQtWbg-ZmNSG8bnJsnL-HYsb5sepaZQohdnk=.00e939c1-bff8-4cc0-8088-1dd240a6f354@github.com>

On Thu, 22 Oct 2020 12:20:24 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> I think it's clearer as it is. The motivation for this is that native references are always oops, while weak reference's referents can be oops or narrowOops. Which means that we need to call a different method for native-refs (the always-oops entry point).
>> The interesting differentiator is native vs. not-native, because one is always-oops, the other can be narrowOop. Weak vs not-weak is not as clear because there can also be weak/phantom native-refs.
>
> The weird part is the method name, load_reference_barrier_**native**(), then you have parameter says that it may not be a native load and the parameter does nothing to hint the possible type differential. How about may_narrow_oop?

Ok I renamed the argument. It is indeed better to decouple the meanings there native <-> narrow/wide.

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

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

From zgu at openjdk.java.net  Thu Oct 22 17:04:18 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 22 Oct 2020 17:04:18 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
Message-ID: <pI6y38DUavT3jP7nn7VMObYMn7o9-P37dIlofrxl09Q=.51ae6a3c-e9bc-4197-8cb9-84a89e43be05@github.com>

On Thu, 22 Oct 2020 16:04:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
>> 
>> There are 3 main items that contribute to pause time linear to number of references, or worse:
>> - We need to scan and consider each reference on the various 'discovered' lists.
>> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
>> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
>> 
>> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
>> 
>> The solution to this is two-fold:
>> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
>> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
>> 
>> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename native argument to maybe_narrow_oop for more clarity

Marked as reviewed by zgu (Reviewer).

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

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

From rkennke at openjdk.java.net  Mon Oct 26 20:58:25 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 26 Oct 2020 20:58:25 GMT
Subject: RFR: 8255401: Shenandoah: Allow oldval and newval registers to
 overlap in cmpxchg_oop()
Message-ID: <aYoSNZYvC131cCrit7cbFauLZnSq0MMxdA909g_WA-w=.70cf7b94-6f49-482f-9aca-dfcb8c2d639b@github.com>

We encountered a failure in testing:

Internal Error (/home/jenkins/workspace/nightly/jdk-jdk/src/hotspot/share/asm/register.hpp:141), pid=15470, tid=15611
assert(a != b && a != c && a != d && b != c && b != d && c != d) failed: registers must be different: a=0x0000000000000000, b=0x0000000000000000, c=0x000000000000000b, d=0x000000000000000a

in:

Stack: [0x00007fb8fa2e3000,0x00007fb8fa3e4000], sp=0x00007fb8fa3deca0, free space=1007k
Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x156890e] ShenandoahBarrierSetAssembler::cmpxchg_oop(MacroAssembler*, RegisterImpl*, Address, RegisterImpl*, RegisterImpl*, bool, RegisterImpl*, RegisterImpl*)+0xde
V [libjvm.so+0x3ec1d1] compareAndSwapN_shenandoahNode::emit(CodeBuffer&, PhaseRegAlloc*) const+0x571 

It seems to appear very rarely.

The failure is that both newval and oldval are the same register (rax). I believe it is ok for the two registers to overlap:
- It is not expected that newval is preserved across the cmpxchg
- The CAS will override newval, but:
  - The first CAS is unaffected by the overlap
  - The retry-loop is only entered when previous-value == old-value, and thus newval will still hold the same value

For aarch64 it matters even less, because newval is never overridden.

Testing: hotspot_gc_shenandoah (x86 & aarch64).

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

Commit messages:
 - 8255401: Shenandoah: Allow oldval and newval registers to overlap in cmpxchg_oop()

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

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

From bmathiske at openjdk.java.net  Tue Oct 27 10:13:11 2020
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 27 Oct 2020 10:13:11 GMT
Subject: RFR: Add 'generational' as value choice for JVM option
 'ShenandoahGCMode'.
Message-ID: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>

All upcoming GenShen code will be guarded by this JVM option. If generational mode is not set, Shenandoah will function in its original single-generational form, without changes or degradations.

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

Commit messages:
 - Add 'generational' as value choice for JVM option 'ShenandoahGCMode'.

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

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

From rkennke at openjdk.java.net  Tue Oct 27 10:13:14 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 10:13:14 GMT
Subject: RFR: Add 'generational' as value choice for JVM option
 'ShenandoahGCMode'.
In-Reply-To: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
References: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
Message-ID: <YzjZEqgMvBXQvKrCckfECx083uVo6Rj3YHxvuVEMVnY=.f343e298-cb8d-431e-b24a-4cc5858f79a1@github.com>

On Wed, 21 Oct 2020 12:53:41 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

> All upcoming GenShen code will be guarded by this JVM option. If generational mode is not set, Shenandoah will function in its original single-generational form, without changes or degradations.

You should merge-in the master branch from openjdk/shenandoah, this should hopefully fix the jcheck complaints.

src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2020, Red Hat, Inc. All rights reserved.

I believe "Copyright (c) 2020 ..." would be correct there.

src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.cpp line 32:

> 30: #include "gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp"
> 31: #include "gc/shenandoah/mode/shenandoahGenerationalMode.hpp"
> 32: #include "logging/log.hpp"

Those includes for logging/* look unused. Probably leftovers?

src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2019, Red Hat, Inc. All rights reserved.

Same as above. 2020 is the year ;-)

src/hotspot/share/gc/shenandoah/mode/shenandoahMode.hpp line 28:

> 26: #define SHARE_GC_SHENANDOAH_MODE_SHENANDOAHMODE_HPP
> 27: 
> 28: #include "runtime/java.hpp"

This include looks unused.

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

Changes requested by rkennke (Reviewer).

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

From bmathiske at openjdk.java.net  Tue Oct 27 10:28:56 2020
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 27 Oct 2020 10:28:56 GMT
Subject: RFR: Add 'generational' as value choice for JVM option
 'ShenandoahGCMode'. [v2]
In-Reply-To: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
References: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
Message-ID: <jIfxGDITvoRpibcpJLkUvgcR9svG9aVLG5FeOL_EyBg=.7bac989f-cb00-48fa-90e2-ac4c91837eb9@github.com>

> All upcoming GenShen code will be guarded by this JVM option. If generational mode is not set, Shenandoah will function in its original single-generational form, without changes or degradations.

Bernd Mathiske has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Add 'generational' as value choice for JVM option 'ShenandoahGCMode'.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/4/files
  - new: https://git.openjdk.java.net/shenandoah/pull/4/files/ff5b4624..39b9ee06

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

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

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

From bmathiske at openjdk.java.net  Tue Oct 27 11:01:04 2020
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 27 Oct 2020 11:01:04 GMT
Subject: RFR: Add 'generational' as value choice for JVM option
 'ShenandoahGCMode'. [v3]
In-Reply-To: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
References: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
Message-ID: <MuOvC7GcJ0N2SzITa3U3_iCR_ThSgTJ-Si-3c13xXMM=.17a351f9-13cf-483c-8fa2-cdbac7a8ab6e@github.com>

> All upcoming GenShen code will be guarded by this JVM option. If generational mode is not set, Shenandoah will function in its original single-generational form, without changes or degradations.

Bernd Mathiske has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  Add 'generational' as value choice for JVM option 'ShenandoahGCMode'.

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/4/files
  - new: https://git.openjdk.java.net/shenandoah/pull/4/files/39b9ee06..60ba9d90

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

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

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

From rkennke at openjdk.java.net  Tue Oct 27 11:01:07 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 11:01:07 GMT
Subject: RFR: Add 'generational' as value choice for JVM option
 'ShenandoahGCMode'. [v3]
In-Reply-To: <MuOvC7GcJ0N2SzITa3U3_iCR_ThSgTJ-Si-3c13xXMM=.17a351f9-13cf-483c-8fa2-cdbac7a8ab6e@github.com>
References: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
 <MuOvC7GcJ0N2SzITa3U3_iCR_ThSgTJ-Si-3c13xXMM=.17a351f9-13cf-483c-8fa2-cdbac7a8ab6e@github.com>
Message-ID: <V-PZ1SxCkoX5VZ3IjdeWgS5WbG_zU_KsQSb95LTPQag=.0e9bae79-0d0d-401e-8c2e-4542fdfd604a@github.com>

On Tue, 27 Oct 2020 10:55:14 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

>> All upcoming GenShen code will be guarded by this JVM option. If generational mode is not set, Shenandoah will function in its original single-generational form, without changes or degradations.
>
> Bernd Mathiske has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   Add 'generational' as value choice for JVM option 'ShenandoahGCMode'.

Looks good to me now! Thank you!

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

Marked as reviewed by rkennke (Reviewer).

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

From bmathiske at openjdk.java.net  Tue Oct 27 11:01:16 2020
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 27 Oct 2020 11:01:16 GMT
Subject: RFR: Add 'generational' as value choice for JVM option
 'ShenandoahGCMode'. [v3]
In-Reply-To: <YzjZEqgMvBXQvKrCckfECx083uVo6Rj3YHxvuVEMVnY=.f343e298-cb8d-431e-b24a-4cc5858f79a1@github.com>
References: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
 <YzjZEqgMvBXQvKrCckfECx083uVo6Rj3YHxvuVEMVnY=.f343e298-cb8d-431e-b24a-4cc5858f79a1@github.com>
Message-ID: <_VZ1fAxyDLh7GLijZnsuC_qeLj_dsQLYZlH8li4yPf8=.444c5be7-911d-47e9-a4c5-bc3ad07c386d@github.com>

On Mon, 26 Oct 2020 21:43:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Bernd Mathiske has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   Add 'generational' as value choice for JVM option 'ShenandoahGCMode'.
>
> src/hotspot/share/gc/shenandoah/mode/shenandoahMode.hpp line 28:
> 
>> 26: #define SHARE_GC_SHENANDOAH_MODE_SHENANDOAHMODE_HPP
>> 27: 
>> 28: #include "runtime/java.hpp"
> 
> This include looks unused.

Moved to "shenandoahGenerationalMode.cpp".

> src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, 2020, Red Hat, Inc. All rights reserved.
> 
> I believe "Copyright (c) 2020 ..." would be correct there.

Fixed.

> src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.cpp line 32:
> 
>> 30: #include "gc/shenandoah/heuristics/shenandoahStaticHeuristics.hpp"
>> 31: #include "gc/shenandoah/mode/shenandoahGenerationalMode.hpp"
>> 32: #include "logging/log.hpp"
> 
> Those includes for logging/* look unused. Probably leftovers?

Removed.

> src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.hpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2019, Red Hat, Inc. All rights reserved.
> 
> Same as above. 2020 is the year ;-)

Fixed.

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

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

From bmathiske at openjdk.java.net  Tue Oct 27 11:01:17 2020
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 27 Oct 2020 11:01:17 GMT
Subject: Withdrawn: Add 'generational' as value choice for JVM option
 'ShenandoahGCMode'.
In-Reply-To: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
References: <z0P2mpbMZ_yxBs-uTwYq2Vw1zJUpBT8XqVVSheUamCY=.d106b9db-a1b8-4d84-b55e-d0934aa8085e@github.com>
Message-ID: <Y2x6NbukFoc0iIKPs6Arz9QEM94T01mjGVaeAEZoqg8=.fe89b539-9276-4db7-96ab-a5fb1c8709d2@github.com>

On Wed, 21 Oct 2020 12:53:41 GMT, Bernd Mathiske <bmathiske at openjdk.org> wrote:

> All upcoming GenShen code will be guarded by this JVM option. If generational mode is not set, Shenandoah will function in its original single-generational form, without changes or degradations.

This pull request has been closed without being integrated.

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

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

From shade at openjdk.java.net  Tue Oct 27 11:30:29 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 11:30:29 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
Message-ID: <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>

On Thu, 22 Oct 2020 16:04:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
>> 
>> There are 3 main items that contribute to pause time linear to number of references, or worse:
>> - We need to scan and consider each reference on the various 'discovered' lists.
>> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
>> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
>> 
>> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
>> 
>> The solution to this is two-fold:
>> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
>> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
>> 
>> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename native argument to maybe_narrow_oop for more clarity

My initial review follows. I have not digested the whole thing yet.

src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 360:

> 358: 
> 359:     if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
> 360:       load_reference_barrier_native(masm, dst, src, (decorators & IN_NATIVE) == 0);

I am a bit confused. If we introduce the local variable, would it be `maybe_narrow_oop`? How does it relate to `IS_NATIVE`? Also, see that `use_load_reference_barrier_native` already tests `IS_NATIVE`.

src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 525:

> 523: 
> 524:     if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
> 525:       load_reference_barrier_native(masm, dst, src, (decorators & IN_NATIVE) == 0);

Same comment as in `aarch64` code.

src/hotspot/share/gc/shenandoah/c1/shenandoahBarrierSetC1.cpp line 287:

> 285:     _load_reference_barrier_weakref_rt_code_blob = Runtime1::generate_blob(buffer_blob, -1,
> 286:                                                                           "shenandoah_load_reference_barrier_weakref_slow",
> 287:                                                                           false, &lrb_weakref_code_gen_cl);

Nit: Looks like indenting is a bit off here, in comparisons with blocks above.

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 41:

> 39:     NATIVE,
> 40:     WEAK
> 41:   };

Descriptions maybe? Also, `ShenandoahLRBKind` seems noisy. Since it is already in `SBS`, maybe `ShenandoahBarrierSet::LRBKind`?

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 64:

> 62:   static bool use_load_reference_barrier_native(DecoratorSet decorators, BasicType type);
> 63:   static bool need_keep_alive_barrier(DecoratorSet decorators, BasicType type);
> 64:   static ShenandoahLRBKind access_kind(DecoratorSet decorators, BasicType type);

...or in fact, `ShenandoahBarrierSet::AccessKind` to match the `access_kind` here? Or does it clash with something else? Or rename this to `lrb_kind`?

src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 1062:

> 1060:     Node* in2 = n->in(2);
> 1061:     if (in1->bottom_type() == TypePtr::NULL_PTR &&
> 1062:         (in2->Opcode() != Op_ShenandoahLoadReferenceBarrier ||

This is a bugfix, right? It changes `in1` (seemingly incorrect) to `in2` (seemingly correct). If so, maybe we should split it out to fix previous releases too?

src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 996:

> 994:       break;
> 995:     default:
> 996:       ShouldNotReachHere();

I expect some compilers to complain here about the uninitialized `name`, please add `name = NULL;` before the `ShouldNotReachHere()`?

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 104:

> 102: 
> 103:   template<typename T>
> 104:   inline oop load_reference_barrier_native(oop obj, T* load_addr);

These might be forked to a separate cleanup? Not insisting... That would make backports a bit cleaner, though.

src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 81:

> 79:   _heap(ShenandoahHeap::heap()),
> 80:   _mark_context(_heap->marking_context()),
> 81:   _strong(true)

Do we want to turn this to yet another template parameter, like for dedup? That would also resolve passing `true` or `false` to `strong` argument without comments.

src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp line 264:

> 262:         marked = mark_context->mark_strong(obj, marked_first);
> 263:       } else {
> 264:         marked = mark_context->mark_final(obj, marked_first);

Is this `mark_final` actually `mark_weak`?

src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 64:

> 62: }
> 63: 
> 64: inline bool ShenandoahMarkBitMap::mark_final(HeapWord* heap_addr, bool& marked_first) {

It looks to me that `marked_first` is always the same as the return value? If so, can we drop that out-argument?

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

> 1731:       }
> 1732:     }
> 1733: 

Why this move?

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

> 3051: 
> 3052:   ShenandoahWorkerScope scope(workers(),
> 3053:                               ShenandoahWorkerPolicy::calc_workers_for_conc_root_processing(),

It probably does not matter, but maybe we should be having a separate `ShenandoahWorkerPolicy` entry for `conc_weak_refs`.

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

> 402:   assert(ctx->is_complete(), "sanity");
> 403: 
> 404:   const ShenandoahMarkBitMap* mark_bit_map = ctx->mark_bit_map();

Why `const`? Not necessarily wrong, but inconsistent with the rest of the method.

src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2020, Red Hat, Inc. and/or its affiliates.

Was it copied from the `MarkBitMap`? Oracle's copyright needs to be left in place, methinks, along with Red Hat-s for Red Hat-s modifications.

src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2020, Red Hat, Inc. and/or its affiliates.

Ditto.

src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2020, Red Hat, Inc. and/or its affiliates.

Ditto.

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

> 83:   f(conc_weak_refs,                                 "Concurrent Weak References")      \
> 84:   f(conc_weak_refs_work,                            "  Process")                       \
> 85:   SHENANDOAH_PAR_PHASE_DO(conc_weak_refs_work_,     "    CWR: ", f)                    \

Eh. Clashes with `CWR:` below... Maybe `CWRF`?

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp line 42:

> 40:  * 1. Concurrent reference marking: Discover all j.l.r.Reference objects and determine reachability of all live objects.
> 41:  * 2. Concurrent reference processing: For all discoved j.l.r.References, determine whether or not to keep or clean
> 42:  *    them. Also, clean and enqueue relevant references concurrently.

"determine whether to keep them alive or clean them", right? These are the choices?

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp line 53:

> 51:  * These reachabilities are implemented in shenandoahMarkBitMap.*
> 52:  * Conceptually, marking starts with a strong wavefront at the GC roots. Whenever a Reference object is encountered,
> 53:  * that Reference is discovered, it may be discovered by the ShenandoahReferenceProcessor. If it is discovered, it

"Whenever a Reference object is encountered, it may be discovered by the ShenandoahReferenceProcessor"?

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp line 55:

> 53:  * that Reference is discovered, it may be discovered by the ShenandoahReferenceProcessor. If it is discovered, it
> 54:  * gets added to the discovered list, and that wavefront stops there, except when it's a FinalReference, in which
> 55:  * case the wavefront switches to finalizable marking and marks through the refenent. When a Reference is not

"refenent" -> "referent"

src/hotspot/share/gc/shenandoah/shenandoahReferenceProcessor.hpp line 57:

> 55:  * case the wavefront switches to finalizable marking and marks through the refenent. When a Reference is not
> 56:  * discovered, e.g. if it's a SoftReference that is not eligible for discovery, then marking continues as if the
> 57:  * Reference were a regular object. Whenever a strong wavefront encounters an object that is already marked

"was a regular object"

src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp line 154:

> 152: public:
> 153:   ObjArrayChunkedTask(oop o = NULL, bool count_liveness = true, bool strong = true) {
> 154:     assert(decode_oop(encode_oop(o, count_liveness, strong)) ==  o, "oop can be encoded: " PTR_FORMAT, p2i(o));

Need encodeability `assert`-s for `count_liveness` and `strong` too? Also in the other constructor? This might get costly, and the whole thing might need rethinking... But at least the initial testing better check there are no bugs here.

src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp line 180:

> 178:   inline uintptr_t encode_oop(oop obj, bool count_liveness, bool strong) const {
> 179:     uintptr_t encoded_oop = ((uintptr_t)(void*) obj) << oop_shift;
> 180:     assert((encoded_oop & (count_liveness_decode_mask | strong_decode_mask)) == 0, "need bit for encoding count-liveness and strong bits");

Ah! This assert can be sacrificed for the additional asserts in constructors, right?

src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp line 55:

> 53:   int  _disarmed_value;
> 54:   double _paced_time;
> 55:   ShenandoahMarkRefsSuperClosure* _mark_closure;

This rubs me the wrong way. Closures are usually stack-allocated, so we are exposing the stack pointer here.

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 97:

> 95:     if (!CompressedOops::is_null(o)) {
> 96:       oop obj = CompressedOops::decode_not_null(o);
> 97:       obj = ShenandoahForwarding::get_forwardee(obj);

But... `verify_oop` verifies the consistency of `obj` and its fwdptr. Here, we effectively omit those checks, making verification less effective! Is this for `Reference` classes only?

src/hotspot/share/gc/shenandoah/shenandoahVerifier.cpp line 853:

> 851:           _verify_forwarded_none,                  // no forwarded references
> 852:           _verify_marked_complete_except_references, // walk over marked objects too
> 853:           _verify_cset_disable,                        // non-forwarded references to cset expected

Please make sure these are indented properly.

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

Changes requested by shade (Reviewer).

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

From shade at openjdk.java.net  Tue Oct 27 11:30:30 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 11:30:30 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v11]
In-Reply-To: <rkqhZP6Rd9jeeIrR1uYxH6a4W-5WlrGIdF9QKKwJfDc=.c0dc2cc4-8fd1-4ec5-8fe4-372940a61133@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <rkqhZP6Rd9jeeIrR1uYxH6a4W-5WlrGIdF9QKKwJfDc=.c0dc2cc4-8fd1-4ec5-8fe4-372940a61133@github.com>
Message-ID: <ZQRYfDgmMHLeW6Reqyhf2tIkMxYd2gN5d5JbYN_Brjs=.ef5eb67a-2854-459d-8c85-4f18ea750040@github.com>

On Wed, 21 Oct 2020 20:48:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
>> 
>> There are 3 main items that contribute to pause time linear to number of references, or worse:
>> - We need to scan and consider each reference on the various 'discovered' lists.
>> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
>> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
>> 
>> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
>> 
>> The solution to this is two-fold:
>> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
>> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
>> 
>> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change ShenandoahLRBKind to be an enum class instead of plain enum, and some minor touch-ups

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 100:

> 98:     ShenandoahHeap::cas_oop(fwd, load_addr, obj);
> 99:   }
> 100:   return fwd;

Unnecessary change?

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

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

From rkennke at openjdk.java.net  Tue Oct 27 11:53:23 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 11:53:23 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
Message-ID: <dLMEfiF-shTiF833YI6RQ73MohRBi6dPGC-Syu9n9XI=.69df7086-0d0d-4936-b6c4-07e7044993b0@github.com>

On Tue, 27 Oct 2020 10:36:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename native argument to maybe_narrow_oop for more clarity
>
> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 360:
> 
>> 358: 
>> 359:     if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
>> 360:       load_reference_barrier_native(masm, dst, src, (decorators & IN_NATIVE) == 0);
> 
> I am a bit confused. If we introduce the local variable, would it be `maybe_narrow_oop`? How does it relate to `IS_NATIVE`? Also, see that `use_load_reference_barrier_native` already tests `IS_NATIVE`.

Yeah, this is confusing. Zhengyu also stumbled over this. Notice that (decorators & IN_NATIVE) == 0 tests for 'is *not* native'. The point is that native-access is *always* uncompressed-oops, while accessing a referent is narrowOop or oop depending on UseCompressedOops. Hence the distinction. If you have a good suggestion on how to make this less confusing, I'd appreciate it.

> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 64:
> 
>> 62:   static bool use_load_reference_barrier_native(DecoratorSet decorators, BasicType type);
>> 63:   static bool need_keep_alive_barrier(DecoratorSet decorators, BasicType type);
>> 64:   static ShenandoahLRBKind access_kind(DecoratorSet decorators, BasicType type);
> 
> ...or in fact, `ShenandoahBarrierSet::AccessKind` to match the `access_kind` here? Or does it clash with something else? Or rename this to `lrb_kind`?

AccessKind seems sensible. I'll try it.

> src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp line 55:
> 
>> 53:   int  _disarmed_value;
>> 54:   double _paced_time;
>> 55:   ShenandoahMarkRefsSuperClosure* _mark_closure;
> 
> This rubs me the wrong way. Closures are usually stack-allocated, so we are exposing the stack pointer here.

Yeah we need to pass it between the mark-loop and the reference-processor. It's still thread-local.

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

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

From bmathiske at openjdk.java.net  Tue Oct 27 12:04:58 2020
From: bmathiske at openjdk.java.net (Bernd Mathiske)
Date: Tue, 27 Oct 2020 12:04:58 GMT
Subject: RFR: Card marking write barrier for generational mode.
Message-ID: <UXC_VSsfsTWf0X1qPkKI-ywQJ2zLyrBYgxePAZ9-beY=.ff77d174-a867-4c29-a161-1dfb7aa59ac2@github.com>

Adding a typical generational card marking write barrier, which is only active in generational mode and has no other effect yet than writing into a card table that is allocated at startup on the side and covers the whole heap as specified by -Xmx.

The code for card marking is copied verbatim from existing shared barrier code. A previous version inherited this code, by making ShenandoahBarrierSet a subclass of CardTableBarrierSet. Now the code pertinent to post write barriers is just copied down instead. This allows adding the new code without any changes to shared code (code that is not specific to Shenandoah).

Initializing the card table in proper sequence comes with slightly rearranging heap initialization. This can be seen near the bottom of the listing here.

Testing: ran the same SPECjvm2008 benchmark programs as before. Performance seems to be 1-1.5% less with card marking active, in average for this kind of benchmark. In non-generational mode, no change observed.

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

Commit messages:
 - Card marking write barrier for generational mode.

Changes: https://git.openjdk.java.net/shenandoah/pull/5/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=5&range=00
  Stats: 541 lines in 13 files changed: 499 ins; 22 del; 20 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/5.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/5/head:pull/5

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

From rkennke at openjdk.java.net  Tue Oct 27 13:45:38 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 13:45:38 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v13]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <9OMvQQo4NDb-SXiBw9kh46B5ABD6ykwumz70Q6Z6maQ=.9ada24e7-de57-4aa2-8993-0d8143e29057@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with three additional commits since the last revision:

 - Rename ShenandoahLRBKind -> AccessKind
 - Relax verification only for j.l.r.Reference objects
 - Intendation fixes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/6418428d..3a3f1c44

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=11-12

  Stats: 82 lines in 14 files changed: 11 ins; 4 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Tue Oct 27 14:00:33 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 14:00:33 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
Message-ID: <BwY2Ftu_2bUyZXlFKJ3MaWQmCaS4FNdrQczM0IMIPaI=.477da532-6e2f-4e05-aa8e-3eebc7751bb1@github.com>

On Tue, 27 Oct 2020 10:49:58 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename native argument to maybe_narrow_oop for more clarity
>
> src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 1062:
> 
>> 1060:     Node* in2 = n->in(2);
>> 1061:     if (in1->bottom_type() == TypePtr::NULL_PTR &&
>> 1062:         (in2->Opcode() != Op_ShenandoahLoadReferenceBarrier ||
> 
> This is a bugfix, right? It changes `in1` (seemingly incorrect) to `in2` (seemingly correct). If so, maybe we should split it out to fix previous releases too?

Actually I think I *introduced* a bug there. It seems curious that it worked that way :-) I'm fixing it.

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

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

From rkennke at openjdk.java.net  Tue Oct 27 14:22:31 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 14:22:31 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v14]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <CT2TTu-kGezYspLznT2mP4yLeb4F_EX5fpGBfr7jVQc=.877a2a3a-668a-4ca7-a84b-2be2e3c62313@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:

 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Fix CmpP optimization
 - Rename ShenandoahLRBKind -> AccessKind
 - Relax verification only for j.l.r.Reference objects
 - Intendation fixes
 - Rename native argument to maybe_narrow_oop for more clarity
 - Change ShenandoahLRBKind to be an enum class instead of plain enum, and some minor touch-ups
 - Add fallback support for new properties in ObjArrayChunkedTask
 - Fix 32bit interpreter LRB-native call
 - Explicitely use concurrent vs stw reference processing, don't rely on is_at_shenandoah_safepoint()
 - ... and 51 more: https://git.openjdk.java.net/jdk/compare/83a91bfa...d95e88c6

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

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=13
  Stats: 2394 lines in 56 files changed: 1628 ins; 567 del; 199 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Tue Oct 27 14:30:42 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 14:30:42 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v15]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <Pw6mGqJ_RujqsFpwBnyJwaDuXglcTU77_jPDmNtODQg=.9bdfa249-f8e5-44cf-9d8d-8057ef16386f@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Fix CmpP optimization
 - Rename ShenandoahLRBKind -> AccessKind
 - Relax verification only for j.l.r.Reference objects
 - Intendation fixes
 - Rename native argument to maybe_narrow_oop for more clarity
 - Change ShenandoahLRBKind to be an enum class instead of plain enum, and some minor touch-ups
 - Add fallback support for new properties in ObjArrayChunkedTask
 - Fix 32bit interpreter LRB-native call
 - ... and 52 more: https://git.openjdk.java.net/jdk/compare/504cb005...4e63ff73

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

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=14
  Stats: 2394 lines in 56 files changed: 1628 ins; 567 del; 199 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Tue Oct 27 14:59:24 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 14:59:24 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
Message-ID: <I3zHDcPGQi_Km7CNwaXEnU1YHsv79ZbEP3tBEBngsoI=.1bd2f0da-1b91-4ac8-977c-b5ae6a1b9493@github.com>

On Tue, 27 Oct 2020 10:54:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename native argument to maybe_narrow_oop for more clarity
>
> src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.hpp line 104:
> 
>> 102: 
>> 103:   template<typename T>
>> 104:   inline oop load_reference_barrier_native(oop obj, T* load_addr);
> 
> These might be forked to a separate cleanup? Not insisting... That would make backports a bit cleaner, though.

I am changing back the template arg of load_reference_barrier_mutator() instead, we are using class everywhere else.

> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 81:
> 
>> 79:   _heap(ShenandoahHeap::heap()),
>> 80:   _mark_context(_heap->marking_context()),
>> 81:   _strong(true)
> 
> Do we want to turn this to yet another template parameter, like for dedup? That would also resolve passing `true` or `false` to `strong` argument without comments.

We need to switch strength in ShenandoahConcurrentMark::do_task() and we get passed-in a ready closure there. I am not sure how we could do that with template-args. Template args only make sense for things that don't change during marking.

> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp line 264:
> 
>> 262:         marked = mark_context->mark_strong(obj, marked_first);
>> 263:       } else {
>> 264:         marked = mark_context->mark_final(obj, marked_first);
> 
> Is this `mark_final` actually `mark_weak`?

We could name it so, but it really means 'reachable through a FinalReference' so 'finalizably reachable' and 'marked final(izable)' seems the more correct term. It is weaker than 'strong' though, so yeah we could rename this. WDYT?

> src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 64:
> 
>> 62: }
>> 63: 
>> 64: inline bool ShenandoahMarkBitMap::mark_final(HeapWord* heap_addr, bool& marked_first) {
> 
> It looks to me that `marked_first` is always the same as the return value? If so, can we drop that out-argument?

Yes, that is true for mark_final(), but not for mark_strong(). I am changing it as you suggested.

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

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

From shade at openjdk.java.net  Tue Oct 27 14:59:24 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 14:59:24 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <I3zHDcPGQi_Km7CNwaXEnU1YHsv79ZbEP3tBEBngsoI=.1bd2f0da-1b91-4ac8-977c-b5ae6a1b9493@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <I3zHDcPGQi_Km7CNwaXEnU1YHsv79ZbEP3tBEBngsoI=.1bd2f0da-1b91-4ac8-977c-b5ae6a1b9493@github.com>
Message-ID: <jjmqDjqJwJmUne6chF4k2lEw2n4-3KMfYI_uIFvYAWg=.02e45413-3170-4e77-b79f-9631dc21d2e1@github.com>

On Tue, 27 Oct 2020 14:54:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahMarkBitMap.inline.hpp line 64:
>> 
>>> 62: }
>>> 63: 
>>> 64: inline bool ShenandoahMarkBitMap::mark_final(HeapWord* heap_addr, bool& marked_first) {
>> 
>> It looks to me that `marked_first` is always the same as the return value? If so, can we drop that out-argument?
>
> Yes, that is true for mark_final(), but not for mark_strong(). I am changing it as you suggested.

No wait, maybe that's fine then. Let me think about it.

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

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

From shade at openjdk.java.net  Tue Oct 27 15:13:29 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 15:13:29 GMT
Subject: RFR: 8255457: Shenandoah: cleanup ShenandoahMarkTask
Message-ID: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>

The code in ObjArrayChunkedTask is rough around the edges, and can be cleaned up. It would be further extended in JDK-8254315, so it makes sense to make the change before the bulk of JDK-8254315 arrives.

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

Commit messages:
 - 8255457: Shenandoah: cleanup ShenandoahMarkTask

Changes: https://git.openjdk.java.net/jdk/pull/883/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=883&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255457
  Stats: 94 lines in 3 files changed: 42 ins; 24 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/883.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/883/head:pull/883

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

From shade at openjdk.java.net  Tue Oct 27 15:21:24 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 15:21:24 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
Message-ID: <ZHVitbfBvVGwylGYoP0uSezAqXHbLCssx9PsIBSoDF4=.50bd3ee2-3d1e-4b52-bf76-575b53bcb34a@github.com>

On Tue, 27 Oct 2020 10:51:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename native argument to maybe_narrow_oop for more clarity
>
> src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp line 996:
> 
>> 994:       break;
>> 995:     default:
>> 996:       ShouldNotReachHere();
> 
> I expect some compilers to complain here about the uninitialized `name`, please add `name = NULL;` before the `ShouldNotReachHere()`?

Ditto for `calladdr`, now that I looking at this block again. Maybe just initialize them at declaration.

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

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

From shade at openjdk.java.net  Tue Oct 27 15:30:33 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 15:30:33 GMT
Subject: RFR: 8255457: Shenandoah: cleanup ShenandoahMarkTask [v2]
In-Reply-To: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>
References: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>
Message-ID: <RR77D93Z44KpD69r15yEevJ5Mfhtxr_UY6MRK4NbalY=.f5a4b433-5d44-4622-89e8-5d42bba61442@github.com>

> The code in ObjArrayChunkedTask is rough around the edges, and can be cleaned up. It would be further extended in JDK-8254315, so it makes sense to make the change before the bulk of JDK-8254315 arrives.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/883/files
  - new: https://git.openjdk.java.net/jdk/pull/883/files/cb954b7f..12a0927e

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

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

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

From shade at openjdk.java.net  Tue Oct 27 15:30:36 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 15:30:36 GMT
Subject: RFR: 8255457: Shenandoah: cleanup ShenandoahMarkTask [v2]
In-Reply-To: <WRpJ6HTSCcj2O4sb7JAlUu8qve-vUFiQbjidzjhSLVk=.5e2edabc-25b1-46f0-be86-989159c16daa@github.com>
References: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>
 <RR77D93Z44KpD69r15yEevJ5Mfhtxr_UY6MRK4NbalY=.f5a4b433-5d44-4622-89e8-5d42bba61442@github.com>
 <WRpJ6HTSCcj2O4sb7JAlUu8qve-vUFiQbjidzjhSLVk=.5e2edabc-25b1-46f0-be86-989159c16daa@github.com>
Message-ID: <HWafyDYVipNCP8Nvekvg4TdagKrKrAE3YM5epDSNLyc=.6d8a9119-9bbd-4cca-8cea-05e3f3ef4e7f@github.com>

On Tue, 27 Oct 2020 15:21:53 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace
>
> src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp line 213:
> 
>> 211:   inline bool is_not_chunked() const { return decode_not_chunked(_obj); }
>> 212: 
>> 213:   DEBUG_ONLY(bool is_valid() const;) // Tasks to be pushed/popped must be valid.
> 
> That looks weird. I guess I prefer the previous notation, but it's your call.

Actually, the previous version looks weird (and CLion highlights it): `DEBUG_ONLY` is a macro that removes all contents, so `;` is left dangling in release mode.

> src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp line 167:
> 
>> 165: 
>> 166:   inline uintptr_t encode_oop(oop obj) const {
>> 167:     return ((uintptr_t) (void *) obj) << oop_shift;
> 
> Looks like an extra space sneaked in here. Or was that intentional?

Not intentional, fixed.

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

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

From rkennke at openjdk.java.net  Tue Oct 27 15:30:34 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 15:30:34 GMT
Subject: RFR: 8255457: Shenandoah: cleanup ShenandoahMarkTask [v2]
In-Reply-To: <RR77D93Z44KpD69r15yEevJ5Mfhtxr_UY6MRK4NbalY=.f5a4b433-5d44-4622-89e8-5d42bba61442@github.com>
References: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>
 <RR77D93Z44KpD69r15yEevJ5Mfhtxr_UY6MRK4NbalY=.f5a4b433-5d44-4622-89e8-5d42bba61442@github.com>
Message-ID: <WRpJ6HTSCcj2O4sb7JAlUu8qve-vUFiQbjidzjhSLVk=.5e2edabc-25b1-46f0-be86-989159c16daa@github.com>

On Tue, 27 Oct 2020 15:28:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The code in ObjArrayChunkedTask is rough around the edges, and can be cleaned up. It would be further extended in JDK-8254315, so it makes sense to make the change before the bulk of JDK-8254315 arrives.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace

Looks ok. Some minor whitespace/formatting nits, but I leave it to you if/what to do about it.

src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp line 167:

> 165: 
> 166:   inline uintptr_t encode_oop(oop obj) const {
> 167:     return ((uintptr_t) (void *) obj) << oop_shift;

Looks like an extra space sneaked in here. Or was that intentional?

src/hotspot/share/gc/shenandoah/shenandoahTaskqueue.hpp line 213:

> 211:   inline bool is_not_chunked() const { return decode_not_chunked(_obj); }
> 212: 
> 213:   DEBUG_ONLY(bool is_valid() const;) // Tasks to be pushed/popped must be valid.

That looks weird. I guess I prefer the previous notation, but it's your call.

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

Marked as reviewed by rkennke (Reviewer).

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

From shade at openjdk.java.net  Tue Oct 27 18:51:22 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 18:51:22 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <dLMEfiF-shTiF833YI6RQ73MohRBi6dPGC-Syu9n9XI=.69df7086-0d0d-4936-b6c4-07e7044993b0@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <dLMEfiF-shTiF833YI6RQ73MohRBi6dPGC-Syu9n9XI=.69df7086-0d0d-4936-b6c4-07e7044993b0@github.com>
Message-ID: <tEL_rMm5ulPAE7jITcvy1gzd4-27vlCVbmtTQ-HIFMA=.364e2dfe-40a3-40eb-af96-a4c3298f8563@github.com>

On Tue, 27 Oct 2020 11:50:10 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahThreadLocalData.hpp line 55:
>> 
>>> 53:   int  _disarmed_value;
>>> 54:   double _paced_time;
>>> 55:   ShenandoahMarkRefsSuperClosure* _mark_closure;
>> 
>> This rubs me the wrong way. Closures are usually stack-allocated, so we are exposing the stack pointer here.
>
> Yeah we need to pass it between the mark-loop and the reference-processor. It's still thread-local.

While I am browsing the code here... why not record it in `ShenandoahRefProcThreadLocal` then? It has a benefit of not polluting the "common" `ShenandoahThreadLocalData`, and clearly says the whole thing is about Shenandoah reference processor.

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

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

From shade at openjdk.java.net  Tue Oct 27 19:00:34 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 27 Oct 2020 19:00:34 GMT
Subject: RFR: 8255457: Shenandoah: cleanup ShenandoahMarkTask [v3]
In-Reply-To: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>
References: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>
Message-ID: <Clty1HKaPIwg-7he0abrZb2wTL4XCUFcnQkUiFye9Ig=.44997f4e-f781-469c-a408-c387f6d4b59a@github.com>

> The code in ObjArrayChunkedTask is rough around the edges, and can be cleaned up. It would be further extended in JDK-8254315, so it makes sense to make the change before the bulk of JDK-8254315 arrives.

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Minor reformatting, comments
 - Deeper cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/883/files
  - new: https://git.openjdk.java.net/jdk/pull/883/files/12a0927e..b7792dde

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

  Stats: 44 lines in 1 file changed: 13 ins; 12 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/883.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/883/head:pull/883

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

From rkennke at openjdk.java.net  Tue Oct 27 19:36:22 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 27 Oct 2020 19:36:22 GMT
Subject: RFR: 8255457: Shenandoah: cleanup ShenandoahMarkTask [v3]
In-Reply-To: <Clty1HKaPIwg-7he0abrZb2wTL4XCUFcnQkUiFye9Ig=.44997f4e-f781-469c-a408-c387f6d4b59a@github.com>
References: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>
 <Clty1HKaPIwg-7he0abrZb2wTL4XCUFcnQkUiFye9Ig=.44997f4e-f781-469c-a408-c387f6d4b59a@github.com>
Message-ID: <Kw4DEBlXPH2vdZ_OdQ3rQyji0UIuQtzRCQbjb-B-e4I=.d7286141-993e-4e41-9b57-3f9194235984@github.com>

On Tue, 27 Oct 2020 19:00:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> The code in ObjArrayChunkedTask is rough around the edges, and can be cleaned up. It would be further extended in JDK-8254315, so it makes sense to make the change before the bulk of JDK-8254315 arrives.
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Minor reformatting, comments
>  - Deeper cleanup

Looks good to me!

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

Marked as reviewed by rkennke (Reviewer).

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

From rkennke at openjdk.java.net  Wed Oct 28 09:17:31 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 09:17:31 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v16]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <K5SNgj8Sb8TdM1JYbpJfCSdWHBdOOVDRzOadrIeDhqg=.1b2a6744-13f1-40d1-bf99-339475732cfd@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 60 commits:

 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Rename ShenandoahLRBKind -> AccessKind
 - Relax verification only for j.l.r.Reference objects
 - Intendation fixes
 - Rename native argument to maybe_narrow_oop for more clarity
 - Change ShenandoahLRBKind to be an enum class instead of plain enum, and some minor touch-ups
 - Add fallback support for new properties in ObjArrayChunkedTask
 - Fix 32bit interpreter LRB-native call
 - Explicitely use concurrent vs stw reference processing, don't rely on is_at_shenandoah_safepoint()
 - Exclude Shenandoah from TestSoftReferencesBehaviorOnOOME.java, it doesn't play with concurrent reference processing
 - ... and 50 more: https://git.openjdk.java.net/jdk/compare/7a7ce021...c36f745a

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

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=15
  Stats: 2394 lines in 56 files changed: 1628 ins; 567 del; 199 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Wed Oct 28 10:50:27 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 10:50:27 GMT
Subject: RFR: 8255527: Shenandoah: Let ShenadoahGCStateResetter disable
 barriers
Message-ID: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>

JDK-8255036 introduced a regression: the new ShenandoahGCStateResetter does not actually disable barriers: it only records old state (without changing it) and then restores that state (i.e a no-op). 

Testing: hotspot_gc_shenandoah (also on conc-weakref branch, where the bug did manifest)

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

Commit messages:
 - 8255527: Shenandoah: Let ShenadoahGCStateResetter disable barriers

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

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

From shade at openjdk.java.net  Wed Oct 28 11:06:53 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 11:06:53 GMT
Subject: RFR: 8255527: Shenandoah: Let ShenadoahGCStateResetter disable
 barriers
In-Reply-To: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
References: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
Message-ID: <dszOVtJBns4qEPWNGnJnUSfEnWkxdDS5vw8O2Dpom7I=.6ff484f5-75dd-415c-aae3-05792e3d9fe4@github.com>

On Wed, 28 Oct 2020 10:43:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> JDK-8255036 introduced a regression: the new ShenandoahGCStateResetter does not actually disable barriers: it only records old state (without changing it) and then restores that state (i.e a no-op). 
> 
> Testing: hotspot_gc_shenandoah (also on conc-weakref branch, where the bug did manifest)

Minor nit, otherwise looks good.

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

> 44:   _gc_state(ShenandoahHeap::heap()->gc_state()),
> 45:   _concurrent_weak_root_in_progress(ShenandoahHeap::heap()->is_concurrent_weak_root_in_progress()) {
> 46:   ShenandoahHeap* heap = ShenandoahHeap::heap();

L52 below has `ShenandoahHeap* const heap`, should be here as well, at least for consistency?

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

Marked as reviewed by shade (Reviewer).

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

From rkennke at openjdk.java.net  Wed Oct 28 11:14:38 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 11:14:38 GMT
Subject: RFR: 8255527: Shenandoah: Let ShenadoahGCStateResetter disable
 barriers [v2]
In-Reply-To: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
References: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
Message-ID: <hW49SGoRvLE063LZonVfb9UNqpfuI4b3kI7CEtatL30=.b56f9d3a-0fc0-4622-a898-8b2ed1dc4335@github.com>

> JDK-8255036 introduced a regression: the new ShenandoahGCStateResetter does not actually disable barriers: it only records old state (without changing it) and then restores that state (i.e a no-op). 
> 
> Testing: hotspot_gc_shenandoah (also on conc-weakref branch, where the bug did manifest)

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Make heap local variable const for consistency

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/899/files
  - new: https://git.openjdk.java.net/jdk/pull/899/files/4515272b..e51fb430

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

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

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

From zgu at openjdk.java.net  Wed Oct 28 12:03:48 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 28 Oct 2020 12:03:48 GMT
Subject: RFR: 8255527: Shenandoah: Let ShenadoahGCStateResetter disable
 barriers [v2]
In-Reply-To: <hW49SGoRvLE063LZonVfb9UNqpfuI4b3kI7CEtatL30=.b56f9d3a-0fc0-4622-a898-8b2ed1dc4335@github.com>
References: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
 <hW49SGoRvLE063LZonVfb9UNqpfuI4b3kI7CEtatL30=.b56f9d3a-0fc0-4622-a898-8b2ed1dc4335@github.com>
Message-ID: <CF0zrHwk6enwtK03dg1BqtzeOAtOyQ6NeuZ_9D6p7Dw=.5b300dea-6ec4-494f-84c3-04c614a37b52@github.com>

On Wed, 28 Oct 2020 11:14:38 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> JDK-8255036 introduced a regression: the new ShenandoahGCStateResetter does not actually disable barriers: it only records old state (without changing it) and then restores that state (i.e a no-op). 
>> 
>> Testing: hotspot_gc_shenandoah (also on conc-weakref branch, where the bug did manifest)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make heap local variable const for consistency

Marked as reviewed by zgu (Reviewer).

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

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

From shade at openjdk.java.net  Wed Oct 28 12:03:50 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 12:03:50 GMT
Subject: RFR: 8255527: Shenandoah: Let ShenadoahGCStateResetter disable
 barriers [v2]
In-Reply-To: <hW49SGoRvLE063LZonVfb9UNqpfuI4b3kI7CEtatL30=.b56f9d3a-0fc0-4622-a898-8b2ed1dc4335@github.com>
References: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
 <hW49SGoRvLE063LZonVfb9UNqpfuI4b3kI7CEtatL30=.b56f9d3a-0fc0-4622-a898-8b2ed1dc4335@github.com>
Message-ID: <DXtrOOnN1YUvzc3t7KajWVLWCDPPapmo7IiuLaK9wwc=.75dedc74-7f1e-4e0d-8464-599bbe69023c@github.com>

On Wed, 28 Oct 2020 11:14:38 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> JDK-8255036 introduced a regression: the new ShenandoahGCStateResetter does not actually disable barriers: it only records old state (without changing it) and then restores that state (i.e a no-op). 
>> 
>> Testing: hotspot_gc_shenandoah (also on conc-weakref branch, where the bug did manifest)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make heap local variable const for consistency

Marked as reviewed by shade (Reviewer).

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

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

From shade at openjdk.java.net  Wed Oct 28 12:18:56 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 12:18:56 GMT
Subject: RFR: 8255527: Shenandoah: Let ShenadoahGCStateResetter disable
 barriers [v3]
In-Reply-To: <irF0noGbOLGECkxR0EIHfxcNPuxTQXIyBP581hToj1Q=.ad4ced9f-7b15-4fcb-a05e-4f2002c90fc7@github.com>
References: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
 <irF0noGbOLGECkxR0EIHfxcNPuxTQXIyBP581hToj1Q=.ad4ced9f-7b15-4fcb-a05e-4f2002c90fc7@github.com>
Message-ID: <3RSGO_UKu2Vp6BXMsCdORX8Oso6EsifFVQxfnIRbe6Y=.db7803ca-cd01-4034-b124-9db5c0548330@github.com>

On Wed, 28 Oct 2020 12:16:21 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> JDK-8255036 introduced a regression: the new ShenandoahGCStateResetter does not actually disable barriers: it only records old state (without changing it) and then restores that state (i.e a no-op). 
>> 
>> Testing: hotspot_gc_shenandoah (also on conc-weakref branch, where the bug did manifest)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep heap ref in ShenandoahGCStateResetter field

Looks even better.

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

Marked as reviewed by shade (Reviewer).

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

From rkennke at openjdk.java.net  Wed Oct 28 12:18:56 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 12:18:56 GMT
Subject: RFR: 8255527: Shenandoah: Let ShenadoahGCStateResetter disable
 barriers [v3]
In-Reply-To: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
References: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
Message-ID: <irF0noGbOLGECkxR0EIHfxcNPuxTQXIyBP581hToj1Q=.ad4ced9f-7b15-4fcb-a05e-4f2002c90fc7@github.com>

> JDK-8255036 introduced a regression: the new ShenandoahGCStateResetter does not actually disable barriers: it only records old state (without changing it) and then restores that state (i.e a no-op). 
> 
> Testing: hotspot_gc_shenandoah (also on conc-weakref branch, where the bug did manifest)

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Keep heap ref in ShenandoahGCStateResetter field

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/899/files
  - new: https://git.openjdk.java.net/jdk/pull/899/files/e51fb430..ae06bf83

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

  Stats: 10 lines in 2 files changed: 2 ins; 2 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/899.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/899/head:pull/899

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

From rkennke at openjdk.java.net  Wed Oct 28 12:18:57 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 12:18:57 GMT
Subject: Integrated: 8255527: Shenandoah: Let ShenadoahGCStateResetter disable
 barriers
In-Reply-To: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
References: <lEGmtJDnhDBSWN0vt1wDWie-fkrxGYIwC4kv0UwaQCo=.b3f8bfec-177b-4816-b45a-633123561a53@github.com>
Message-ID: <LImTBr5x4a2t2LsQFGlEs8mLbIxPQfppYEvu0wAfdgc=.3bf94311-a29c-4061-94da-8fdf89eed5bd@github.com>

On Wed, 28 Oct 2020 10:43:07 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> JDK-8255036 introduced a regression: the new ShenandoahGCStateResetter does not actually disable barriers: it only records old state (without changing it) and then restores that state (i.e a no-op). 
> 
> Testing: hotspot_gc_shenandoah (also on conc-weakref branch, where the bug did manifest)

This pull request has now been integrated.

Changeset: 1f00c3b9
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1f00c3b9
Stats:     9 lines in 2 files changed: 4 ins; 1 del; 4 mod

8255527: Shenandoah: Let ShenadoahGCStateResetter disable barriers

Reviewed-by: shade, zgu

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

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

From rkennke at openjdk.java.net  Wed Oct 28 12:33:51 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 12:33:51 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <BwY2Ftu_2bUyZXlFKJ3MaWQmCaS4FNdrQczM0IMIPaI=.477da532-6e2f-4e05-aa8e-3eebc7751bb1@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <BwY2Ftu_2bUyZXlFKJ3MaWQmCaS4FNdrQczM0IMIPaI=.477da532-6e2f-4e05-aa8e-3eebc7751bb1@github.com>
Message-ID: <fJcEegFHTHVS0CWokgGjcpc8eqokYr49Hb0h-qOa4S4=.de886e39-4cec-4448-856a-f6f940e460a4@github.com>

On Tue, 27 Oct 2020 13:57:28 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 1062:
>> 
>>> 1060:     Node* in2 = n->in(2);
>>> 1061:     if (in1->bottom_type() == TypePtr::NULL_PTR &&
>>> 1062:         (in2->Opcode() != Op_ShenandoahLoadReferenceBarrier ||
>> 
>> This is a bugfix, right? It changes `in1` (seemingly incorrect) to `in2` (seemingly correct). If so, maybe we should split it out to fix previous releases too?
>
> Actually I think I *introduced* a bug there. It seems curious that it worked that way :-) I'm fixing it.

You are right. Tracking & fixing this here: https://bugs.openjdk.java.net/browse/JDK-8255534

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

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

From rkennke at openjdk.java.net  Wed Oct 28 12:39:51 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 12:39:51 GMT
Subject: RFR: 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB
Message-ID: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>

JDK-8254314 introduced the following code:

    if (in1->bottom_type() == TypePtr::NULL_PTR &&
        (in1->Opcode() != Op_ShenandoahLoadReferenceBarrier || !((ShenandoahLoadReferenceBarrierNode*)in1)->is_native())) {
      in2 = step_over_gc_barrier(in2);
    }

However, the check for LRB and !native are the wrong way around: they should check if *in2* are not native LRB.

The bug is currently only observed in the conc-weakrefs branch, but may manifest (rarely) in mainline too. 

I am also putting in some refactoring to avoid duped code for good measure.

Testing: hotspot_gc_shenandoah (also in conc-weakrefs-branch where it manifests)

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

Commit messages:
 - 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB

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

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

From shade at openjdk.java.net  Wed Oct 28 13:03:46 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 13:03:46 GMT
Subject: RFR: 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB
In-Reply-To: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
References: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
Message-ID: <gnIl01jLqp3LV1NbLHHVVRqoLR358808ZxVk0dNYfWM=.106c10f4-15a8-4715-a10c-be22208ac305@github.com>

On Wed, 28 Oct 2020 12:34:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> JDK-8254314 introduced the following code:
> 
>     if (in1->bottom_type() == TypePtr::NULL_PTR &&
>         (in1->Opcode() != Op_ShenandoahLoadReferenceBarrier || !((ShenandoahLoadReferenceBarrierNode*)in1)->is_native())) {
>       in2 = step_over_gc_barrier(in2);
>     }
> 
> However, the check for LRB and !native are the wrong way around: they should check if *in2* are not native LRB.
> 
> The bug is currently only observed in the conc-weakrefs branch, but may manifest (rarely) in mainline too. 
> 
> I am also putting in some refactoring to avoid duped code for good measure.
> 
> Testing: hotspot_gc_shenandoah (also in conc-weakrefs-branch where it manifests)

Changes requested by shade (Reviewer).

src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 1047:

> 1045: void ShenandoahBarrierSetC2::maybe_step_over_cmpp_inputs(Node*& in1, Node*& in2) const {
> 1046:   if (in1->bottom_type() == TypePtr::NULL_PTR &&
> 1047:       (in2->Opcode() != Op_ShenandoahLoadReferenceBarrier || !((ShenandoahLoadReferenceBarrierNode*)in2)->is_native())) {

Suggestion: let's write this block like:

    // If first input is NULL, then skip the LRB barriers (except native) on the second input
    if (in1->bottom_type() == TypePtr::NULL_PTR &&
        !((in2->Opcode() == Op_ShenandoahLoadReferenceBarrier) &&
          ((ShenandoahLoadReferenceBarrierNode*)in2)->is_native()) {

src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 1045:

> 1043: #endif
> 1044: 
> 1045: void ShenandoahBarrierSetC2::maybe_step_over_cmpp_inputs(Node*& in1, Node*& in2) const {

`Node*&` or `Node*`?

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

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

From rkennke at openjdk.java.net  Wed Oct 28 13:56:48 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 13:56:48 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
Message-ID: <5hNdcR3PevZ5mvvcPbZcivU9EdEUL6Kw3K6fv_rnzeA=.5150351b-814e-474f-9399-70580e3f4d30@github.com>

On Tue, 27 Oct 2020 11:04:02 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename native argument to maybe_narrow_oop for more clarity
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1733:
> 
>> 1731:       }
>> 1732:     }
>> 1733: 
> 
> Why this move?

That seems to be a leftover from when the verifier was not yet working correctly. I think it can be reverted.

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

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

From rkennke at openjdk.java.net  Wed Oct 28 14:41:54 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 14:41:54 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <pwhGLGLMWPhbeLdsUOsD_p1YEGYr5APvBxgvIkvyi6E=.c5ffee73-2c1a-4101-9cd5-0a24f35e162d@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <pwhGLGLMWPhbeLdsUOsD_p1YEGYr5APvBxgvIkvyi6E=.c5ffee73-2c1a-4101-9cd5-0a24f35e162d@github.com>
Message-ID: <4jaq_DRQhEuLVTL3CoeYEJrlanL_svXcTVhiFzjH37o=.31457feb-c243-4ca6-bd87-bb03563161ac@github.com>

On Wed, 28 Oct 2020 14:38:02 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 404:
>> 
>>> 402:   assert(ctx->is_complete(), "sanity");
>>> 403: 
>>> 404:   const ShenandoahMarkBitMap* mark_bit_map = ctx->mark_bit_map();
>> 
>> Why `const`? Not necessarily wrong, but inconsistent with the rest of the method.
>
> mark_bit_map() only returns a const now, and I think that's better: *if* we are to expose the bitmap, then better make it read-only.

OTOH, it is only used to call get_next_marked_addr() which we can do just as well through ctx, and not expose the bitmap to begin with.

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

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

From rkennke at openjdk.java.net  Wed Oct 28 14:41:53 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 14:41:53 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
Message-ID: <pwhGLGLMWPhbeLdsUOsD_p1YEGYr5APvBxgvIkvyi6E=.c5ffee73-2c1a-4101-9cd5-0a24f35e162d@github.com>

On Tue, 27 Oct 2020 11:06:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename native argument to maybe_narrow_oop for more clarity
>
> src/hotspot/share/gc/shenandoah/shenandoahHeap.inline.hpp line 404:
> 
>> 402:   assert(ctx->is_complete(), "sanity");
>> 403: 
>> 404:   const ShenandoahMarkBitMap* mark_bit_map = ctx->mark_bit_map();
> 
> Why `const`? Not necessarily wrong, but inconsistent with the rest of the method.

mark_bit_map() only returns a const now, and I think that's better: *if* we are to expose the bitmap, then better make it read-only.

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

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

From rkennke at openjdk.java.net  Wed Oct 28 15:26:58 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 15:26:58 GMT
Subject: RFR: 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB
 [v2]
In-Reply-To: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
References: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
Message-ID: <Ta9AP1M6Z8EtTWUW7g487NMIocM1AJMAVem_yOdTHCM=.d8d8dbe2-30cd-46a4-a7da-ef9f7a7237a6@github.com>

> JDK-8254314 introduced the following code:
> 
>     if (in1->bottom_type() == TypePtr::NULL_PTR &&
>         (in1->Opcode() != Op_ShenandoahLoadReferenceBarrier || !((ShenandoahLoadReferenceBarrierNode*)in1)->is_native())) {
>       in2 = step_over_gc_barrier(in2);
>     }
> 
> However, the check for LRB and !native are the wrong way around: they should check if *in2* are not native LRB.
> 
> The bug is currently only observed in the conc-weakrefs branch, but may manifest (rarely) in mainline too. 
> 
> I am also putting in some refactoring to avoid duped code for good measure.
> 
> Testing: hotspot_gc_shenandoah (also in conc-weakrefs-branch where it manifests)

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Rewrite condition to be less confusing

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/902/files
  - new: https://git.openjdk.java.net/jdk/pull/902/files/fcaeb02e..922d51ff

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

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

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

From shade at openjdk.java.net  Wed Oct 28 15:41:45 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 15:41:45 GMT
Subject: RFR: 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB
 [v2]
In-Reply-To: <Ta9AP1M6Z8EtTWUW7g487NMIocM1AJMAVem_yOdTHCM=.d8d8dbe2-30cd-46a4-a7da-ef9f7a7237a6@github.com>
References: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
 <Ta9AP1M6Z8EtTWUW7g487NMIocM1AJMAVem_yOdTHCM=.d8d8dbe2-30cd-46a4-a7da-ef9f7a7237a6@github.com>
Message-ID: <XF1qD9ATMsthPCxq8oZOD-r82V3T9LLSebM6wrFzI_A=.c640a26d-c727-4523-a8a4-a496ab89ca9e@github.com>

On Wed, 28 Oct 2020 15:26:58 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> JDK-8254314 introduced the following code:
>> 
>>     if (in1->bottom_type() == TypePtr::NULL_PTR &&
>>         (in1->Opcode() != Op_ShenandoahLoadReferenceBarrier || !((ShenandoahLoadReferenceBarrierNode*)in1)->is_native())) {
>>       in2 = step_over_gc_barrier(in2);
>>     }
>> 
>> However, the check for LRB and !native are the wrong way around: they should check if *in2* are not native LRB.
>> 
>> The bug is currently only observed in the conc-weakrefs branch, but may manifest (rarely) in mainline too. 
>> 
>> I am also putting in some refactoring to avoid duped code for good measure.
>> 
>> Testing: hotspot_gc_shenandoah (also in conc-weakrefs-branch where it manifests)
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rewrite condition to be less confusing

Changes requested by shade (Reviewer).

src/hotspot/share/gc/shenandoah/c2/shenandoahBarrierSetC2.cpp line 1046:

> 1044: 
> 1045: void ShenandoahBarrierSetC2::maybe_step_over_cmpp_inputs(Node*& in1, Node*& in2) const {
> 1046:   // If first input is NULL, then skip the LRB barriers (except native) on the second input

OK, as we discussed offline, this also admits other barriers... so maybe:
`// If first input is NULL, then step over the barriers (except LRB native) on the second input`

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

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

From rkennke at openjdk.java.net  Wed Oct 28 15:59:00 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 15:59:00 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v17]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <3b2ySofmKxLflg6HTT4grDQrG05_e7jM9tpDFwlbFuw=.6fde5caa-5d73-49b7-b230-96a83b58c106@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 71 commits:

 - Add ShenandoahWorkerPolicy entry for conc-weak-refs
 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Better encapsulation of the bitmap within ShMarkingContext
 - Fix docs in shenandoahReferenceProcessor.hpp
 - Change CWR to CWRF phase timing to avoid clash with conc-weak-roots
 - Fix copyrights of shenandoahMarkBitMap.*
 - Move back before-evac verification to where it has been
 - Whitespace fixes
 - Use template-class instead of template-typename for load_reference_barrier* entries
 - Initialize name and calladdr to make compiler happy about empty default branch in switch
 - ... and 61 more: https://git.openjdk.java.net/jdk/compare/aaf4f690...69c81d74

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

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=16
  Stats: 2416 lines in 55 files changed: 1645 ins; 565 del; 206 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From akozlov at openjdk.java.net  Wed Oct 28 16:53:00 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 28 Oct 2020 16:53:00 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	
Message-ID: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>

Hi,

When a single string without formatting arguments is provided to `err_msg`, it's redundancy, as the same message could be used without any err_msg. This is a follow-up to the discussion https://github.com/openjdk/jdk/pull/812#discussion_r511784050

Please review a change that makes `err_msg` with a single string to fail compilation. 

Detected uses of err_msg with a single string were eliminated as well.

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

Commit messages:
 - Fix unnecessary err_msg uses
 - Prevent err_msg without format arguments

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

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

From shade at openjdk.java.net  Wed Oct 28 18:08:46 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 18:08:46 GMT
Subject: Integrated: 8255457: Shenandoah: cleanup ShenandoahMarkTask
In-Reply-To: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>
References: <-s8rDa5tGunMQ7TDsJzurheBhiOOx6vU4Ngus9bRECs=.ae033ec1-4915-4553-94c5-ebd6b27da4ac@github.com>
Message-ID: <Uec7AeI_E6SvewnHGb9YevtT3kWdZswkMdKNetzLCpM=.66c420c1-6a1b-40c1-a15e-e5971c7c11d7@github.com>

On Tue, 27 Oct 2020 15:05:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> The code in ObjArrayChunkedTask is rough around the edges, and can be cleaned up. It would be further extended in JDK-8254315, so it makes sense to make the change before the bulk of JDK-8254315 arrives.

This pull request has now been integrated.

Changeset: 1215b1a8
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1215b1a8
Stats:     109 lines in 3 files changed: 46 ins; 27 del; 36 mod

8255457: Shenandoah: cleanup ShenandoahMarkTask

Reviewed-by: rkennke

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

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

From rkennke at openjdk.java.net  Wed Oct 28 18:15:01 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 18:15:01 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v18]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <82-q-nPH3pC7oWA8mTZQtE5t5Qc6Gs7Dsf2G-NbbLvU=.3ed9e332-f0f0-4f47-b5dd-8ce7aaaa6d2e@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Consolidate native-LRB invocation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/69c81d74..0dc1ed88

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=16-17

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

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

From shade at openjdk.java.net  Wed Oct 28 18:18:51 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 18:18:51 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	
In-Reply-To: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
Message-ID: <GposOXoXzlhJTPQMl3HchdWpkGz7nUeqMgUoUgVg_Hs=.3e3fee06-e0a1-431a-a18e-9ac736a13574@github.com>

On Wed, 28 Oct 2020 16:46:47 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Hi,
> 
> When a single string without formatting arguments is provided to `err_msg`, it's redundancy, as the same message could be used without any err_msg. This is a follow-up to the discussion https://github.com/openjdk/jdk/pull/812#discussion_r511784050
> 
> Please review a change that makes `err_msg` with a single string to fail compilation. 
> 
> Detected uses of err_msg with a single string were eliminated as well.

src/hotspot/share/gc/shenandoah/mode/shenandoahMode.hpp line 35:

> 33:   do {                                                                      \
> 34:     if (!(name)) {                                                          \
> 35:       const char *msg = "GC mode needs -XX:+" #name " to work correctly";   \

Please decide which way the `*` leans in this change. I prefer `const char* msg`, like in the change below.

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

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

From shade at openjdk.java.net  Wed Oct 28 18:18:54 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 18:18:54 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	
In-Reply-To: <GposOXoXzlhJTPQMl3HchdWpkGz7nUeqMgUoUgVg_Hs=.3e3fee06-e0a1-431a-a18e-9ac736a13574@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
 <GposOXoXzlhJTPQMl3HchdWpkGz7nUeqMgUoUgVg_Hs=.3e3fee06-e0a1-431a-a18e-9ac736a13574@github.com>
Message-ID: <b-LQz0W4gJOmMeLHDQXM19jOsAkoMF8aNio8De5BKEM=.3c844420-abc4-4de8-824b-81ec1bdbf2bf@github.com>

On Wed, 28 Oct 2020 18:13:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi,
>> 
>> When a single string without formatting arguments is provided to `err_msg`, it's redundancy, as the same message could be used without any err_msg. This is a follow-up to the discussion https://github.com/openjdk/jdk/pull/812#discussion_r511784050
>> 
>> Please review a change that makes `err_msg` with a single string to fail compilation. 
>> 
>> Detected uses of err_msg with a single string were eliminated as well.
>
> src/hotspot/share/gc/shenandoah/mode/shenandoahMode.hpp line 35:
> 
>> 33:   do {                                                                      \
>> 34:     if (!(name)) {                                                          \
>> 35:       const char *msg = "GC mode needs -XX:+" #name " to work correctly";   \
> 
> Please decide which way the `*` leans in this change. I prefer `const char* msg`, like in the change below.

In fact, maybe just inline this literal down in `vm_exit_during_initialization` invocation.

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

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

From stuefe at openjdk.java.net  Wed Oct 28 18:41:44 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 28 Oct 2020 18:41:44 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	
In-Reply-To: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
Message-ID: <dUAqA0Hlaqy6h0KwI7DxXWPdx6tA384oGAndF9di6I4=.fbc7588d-ee94-4856-85a8-170d2e8d92b5@github.com>

On Wed, 28 Oct 2020 16:46:47 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Hi,
> 
> When a single string without formatting arguments is provided to `err_msg`, it's redundancy, as the same message could be used without any err_msg. This is a follow-up to the discussion https://github.com/openjdk/jdk/pull/812#discussion_r511784050
> 
> Please review a change that makes `err_msg` with a single string to fail compilation. 
> 
> Detected uses of err_msg with a single string were eliminated as well.

Changes requested by stuefe (Reviewer).

src/hotspot/share/gc/shenandoah/mode/shenandoahMode.hpp line 44:

> 42:     if ((name)) {                                                           \
> 43:       const char* msg = "GC mode needs -XX:-" #name " to work correctly";   \
> 44:       vm_exit_during_initialization("Error", msg);                          \

Same as above, can be inlined into one call. No need for the temporary variable.

src/hotspot/share/utilities/formatBuffer.hpp line 124:

> 122:   // If compilation fails because of ambiguity between this and real constructor, you
> 123:   // could drop err_msg use at all.
> 124:   inline FormatErrBuffer(const char* msg) { ShouldNotReachHere(); }

I do not think this is a good idea (apart from it being too complex for a not that serious issue).

The asserts fire, of course, only at runtime. But this function is used usually in some error context, as part of of error reporting. I do not think our tests cover all those paths.

Either somehow make this a compile time error or just leave it as it is. We also could, since this buffer object is used usually as input for vm_exit_during_initialization(), give that function a var-arg overload.

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

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

From shade at openjdk.java.net  Wed Oct 28 18:59:49 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 18:59:49 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <dLMEfiF-shTiF833YI6RQ73MohRBi6dPGC-Syu9n9XI=.69df7086-0d0d-4936-b6c4-07e7044993b0@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <dLMEfiF-shTiF833YI6RQ73MohRBi6dPGC-Syu9n9XI=.69df7086-0d0d-4936-b6c4-07e7044993b0@github.com>
Message-ID: <PbfML5YcPKOduNRZ7b4JpO0DFAQgxjB7XSyA_oLV9ls=.07958a63-9151-4e9e-ac43-9f8a463d7e88@github.com>

On Tue, 27 Oct 2020 11:47:47 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/gc/shenandoah/shenandoahBarrierSetAssembler_aarch64.cpp line 360:
>> 
>>> 358: 
>>> 359:     if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
>>> 360:       load_reference_barrier_native(masm, dst, src, (decorators & IN_NATIVE) == 0);
>> 
>> I am a bit confused. If we introduce the local variable, would it be `maybe_narrow_oop`? How does it relate to `IS_NATIVE`? Also, see that `use_load_reference_barrier_native` already tests `IS_NATIVE`.
>
> Yeah, this is confusing. Zhengyu also stumbled over this. Notice that (decorators & IN_NATIVE) == 0 tests for 'is *not* native'. The point is that native-access is *always* uncompressed-oops, while accessing a referent is narrowOop or oop depending on UseCompressedOops. Hence the distinction. If you have a good suggestion on how to make this less confusing, I'd appreciate it.

But that's the thing that gets my head spinning. Why do we call into `lrb_native` for referents? This contradicts the idea that "native-access is always uncompressed-oops". I think this tries to overload "native" with more meaning that it is equipped to carry. 

I think at very least it should say:

    if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
      // API impedance: when used on native refs, lrb-native necessarily works with full oops,
      // but when used for weak/phantom refs, it might need to work with narrow oops.
      // Therefore, we need to ask barrier code to look back at UseCompressedOops and
      // decide, when lrb-native is not IN_NATIVE. TODO: Resolve this API impedance.
      bool maybe_narrow_oop = (decorators & IN_NATIVE) == 0;
      load_reference_barrier_native(masm, dst, src, maybe_narrow_oop);
    } else {
      load_reference_barrier(masm, dst, src);
    }

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

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

From shade at openjdk.java.net  Wed Oct 28 18:59:51 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 28 Oct 2020 18:59:51 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
Message-ID: <4d4Sj-7PwPgKu80Uv1jE0d9Xcg6kQeojjIUuDtXtaIY=.7f3024d0-9f63-4ebd-9c67-fe6fe17c584f@github.com>

On Tue, 27 Oct 2020 10:41:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename native argument to maybe_narrow_oop for more clarity
>
> src/hotspot/cpu/x86/gc/shenandoah/shenandoahBarrierSetAssembler_x86.cpp line 525:
> 
>> 523: 
>> 524:     if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
>> 525:       load_reference_barrier_native(masm, dst, src, (decorators & IN_NATIVE) == 0);
> 
> Same comment as in `aarch64` code.

This conversation can be resolved, as it is the same as for aarch64 code.

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

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

From rkennke at openjdk.java.net  Wed Oct 28 19:58:48 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 19:58:48 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <PbfML5YcPKOduNRZ7b4JpO0DFAQgxjB7XSyA_oLV9ls=.07958a63-9151-4e9e-ac43-9f8a463d7e88@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <dLMEfiF-shTiF833YI6RQ73MohRBi6dPGC-Syu9n9XI=.69df7086-0d0d-4936-b6c4-07e7044993b0@github.com>
 <PbfML5YcPKOduNRZ7b4JpO0DFAQgxjB7XSyA_oLV9ls=.07958a63-9151-4e9e-ac43-9f8a463d7e88@github.com>
Message-ID: <AXPxHY4vPlQW5Mz-hrKWwA19UXrUv7M8RDDAlOm0ryY=.e050d49d-27b0-49c1-91b6-ba4dc94f5be0@github.com>

On Wed, 28 Oct 2020 18:55:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yeah, this is confusing. Zhengyu also stumbled over this. Notice that (decorators & IN_NATIVE) == 0 tests for 'is *not* native'. The point is that native-access is *always* uncompressed-oops, while accessing a referent is narrowOop or oop depending on UseCompressedOops. Hence the distinction. If you have a good suggestion on how to make this less confusing, I'd appreciate it.
>
> But that's the thing that gets my head spinning. Why do we call into `lrb_native` for referents? This contradicts the idea that "native-access is always uncompressed-oops". I think this tries to overload "native" with more meaning that it is equipped to carry. 
> 
> I think at very least it should say:
> 
>     if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
>       // API impedance: when used on native refs, lrb-native necessarily works with full oops,
>       // but when used for weak/phantom refs, it might need to work with narrow oops.
>       // Therefore, we need to ask barrier code to look back at UseCompressedOops and
>       // decide, when lrb-native is not IN_NATIVE. TODO: Resolve this API impedance.
>       bool maybe_narrow_oop = (decorators & IN_NATIVE) == 0;
>       load_reference_barrier_native(masm, dst, src, maybe_narrow_oop);
>     } else {
>       load_reference_barrier(masm, dst, src);
>     }

I thought about it today. This whole idea of 'LRB-native' is flawed. What it does is prevent resurrection of objects when loading from a field or off-heap-location that is 'weak' or 'phantom'. This has nothing to do with -native. It has to do with the field being not-strong. For this reason I think we should call that variant of LRB something like LRB-weak instead. This warrants a larger reshuffling that I'd do either before or after this change goes in. I'd probably also merge our 3(!) different runtime LRB impls into one, with templated path to prevent resurrection, etc. I guess the 2 interpreter LRB entries can also be unified, and differ only in the target entry being called.

The only distinction for which IN_NATIVE is relevant is for figuring out whether or not the reference is compressed or not. That is all.

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

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

From akozlov at openjdk.java.net  Wed Oct 28 21:57:56 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 28 Oct 2020 21:57:56 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v2]
In-Reply-To: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
Message-ID: <5rGPbr1hKFnW_88PKXtDsnCBL1KoUK1Hl72uAJW-hD0=.9f4072b2-878a-44a2-90ab-5e8a2841a047@github.com>

> Hi,
> 
> When a single string without formatting arguments is provided to `err_msg`, it's redundancy, as the same message could be used without any err_msg. This is a follow-up to the discussion https://github.com/openjdk/jdk/pull/812#discussion_r511784050
> 
> Please review a change that makes `err_msg` with a single string to fail compilation. 
> 
> Detected uses of err_msg with a single string were eliminated as well.

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

  Fix codestyle

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/905/files
  - new: https://git.openjdk.java.net/jdk/pull/905/files/93af93b0..52ff2ccb

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

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

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

From akozlov at openjdk.java.net  Wed Oct 28 21:57:57 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 28 Oct 2020 21:57:57 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v2]
In-Reply-To: <b-LQz0W4gJOmMeLHDQXM19jOsAkoMF8aNio8De5BKEM=.3c844420-abc4-4de8-824b-81ec1bdbf2bf@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
 <GposOXoXzlhJTPQMl3HchdWpkGz7nUeqMgUoUgVg_Hs=.3e3fee06-e0a1-431a-a18e-9ac736a13574@github.com>
 <b-LQz0W4gJOmMeLHDQXM19jOsAkoMF8aNio8De5BKEM=.3c844420-abc4-4de8-824b-81ec1bdbf2bf@github.com>
Message-ID: <0_DgjolEWtNQOrJDn_ydLCTYH1gfPwE2tmdoQ9R3hHk=.cecf2d74-6c79-4270-905e-c651f076bbda@github.com>

On Wed, 28 Oct 2020 18:15:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/mode/shenandoahMode.hpp line 35:
>> 
>>> 33:   do {                                                                      \
>>> 34:     if (!(name)) {                                                          \
>>> 35:       const char *msg = "GC mode needs -XX:+" #name " to work correctly";   \
>> 
>> Please decide which way the `*` leans in this change. I prefer `const char* msg`, like in the change below.
>
> In fact, maybe just inline this literal down in `vm_exit_during_initialization` invocation.

Of course it should align to the left, like in the rest of hotspot. Thanks for noticing!

As for inlining of the message, there are pros and cons. The arguments should be aligned, so it would become
  do {                                                                      \
    if (!(name)) {                                                          \
      vm_exit_during_initialization("Error", msg);                          \
                                    "GC mode needs -XX:+" #name " to work correctly"; \
    }                                                                       \
  } while (0)

(not pretty at all, you see).

After that, there is an option to split the string into multiple lines in attempt to shrink the length, but then the line would become ungreppable (much bigger evil).

Among options, I decided to respect intention and style of original author, who introduced a variable for err_msg, which is unusual and should have some valid rationale behind, like the one above.

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

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

From akozlov at openjdk.java.net  Wed Oct 28 21:57:58 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 28 Oct 2020 21:57:58 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v2]
In-Reply-To: <dUAqA0Hlaqy6h0KwI7DxXWPdx6tA384oGAndF9di6I4=.fbc7588d-ee94-4856-85a8-170d2e8d92b5@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
 <dUAqA0Hlaqy6h0KwI7DxXWPdx6tA384oGAndF9di6I4=.fbc7588d-ee94-4856-85a8-170d2e8d92b5@github.com>
Message-ID: <-P5id4x50oiTzG6JHl4GD-HJbqYM4juVm9IpsNvXlV4=.7e07be8c-8389-41e2-a563-1f3be709ac51@github.com>

On Wed, 28 Oct 2020 18:22:37 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix codestyle
>
> src/hotspot/share/gc/shenandoah/mode/shenandoahMode.hpp line 44:
> 
>> 42:     if ((name)) {                                                           \
>> 43:       const char* msg = "GC mode needs -XX:-" #name " to work correctly";   \
>> 44:       vm_exit_during_initialization("Error", msg);                          \
> 
> Same as above, can be inlined into one call. No need for the temporary variable.

Please see my comment in the thread above.

> src/hotspot/share/utilities/formatBuffer.hpp line 124:
> 
>> 122:   // If compilation fails because of ambiguity between this and real constructor, you
>> 123:   // could drop err_msg use at all.
>> 124:   inline FormatErrBuffer(const char* msg) { ShouldNotReachHere(); }
> 
> I do not think this is a good idea (apart from it being too complex for a not that serious issue).
> 
> The asserts fire, of course, only at runtime. But this function is used usually in some error context, as part of of error reporting. I do not think our tests cover all those paths.
> 
> Either somehow make this a compile time error or just leave it as it is. We also could, since this buffer object is used usually as input for vm_exit_during_initialization(), give that function a var-arg overload.

Actually, this code prevents a single string argument in compile time. It relies on two constructors to introduce ambiguity in overload resolution that makes C++ compiler complain and abort compilation. Comment above the dummy constructor should clarify that for anyone stepping on compile error.
  inline FormatErrBuffer(const char* format, ...) ATTRIBUTE_PRINTF(2, 3);
  inline FormatErrBuffer(const char* msg) { ShouldNotReachHere(); }
For sanity check, I've used this sample code https://godbolt.org/z/szs6rE

And the cases that were fixed have been detected by the compiler.

I don't think that this problem is a serious issue as well. But as for me, it is a minor code complexity increase to ensure that the minor problem of extra string copy will never appear again.

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

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

From rkennke at openjdk.java.net  Wed Oct 28 22:12:59 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 22:12:59 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v19]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <-ziqs4ofM_qJ3qmhcOFvAm9sbfO2AfAAAfiL4M6JgNc=.d7bd465c-a120-4aca-a159-f237950e085e@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 73 commits:

 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Consolidate native-LRB invocation
 - Add ShenandoahWorkerPolicy entry for conc-weak-refs
 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Better encapsulation of the bitmap within ShMarkingContext
 - Fix docs in shenandoahReferenceProcessor.hpp
 - Change CWR to CWRF phase timing to avoid clash with conc-weak-roots
 - Fix copyrights of shenandoahMarkBitMap.*
 - Move back before-evac verification to where it has been
 - Whitespace fixes
 - ... and 63 more: https://git.openjdk.java.net/jdk/compare/3f20612e...0561c2a1

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

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=18
  Stats: 2387 lines in 54 files changed: 1630 ins; 565 del; 192 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Wed Oct 28 22:32:03 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 28 Oct 2020 22:32:03 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v20]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <gy5wkpMeGoTKxnAHfDAnT59G5iBLAjKGoHsScrt64gw=.b689bd84-27d6-479a-a7a9-b019eb92e2a9@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Add missing merge changes of shenandoahTaskQueue.hpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/0561c2a1..072e3817

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=18-19

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

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

From shade at openjdk.java.net  Thu Oct 29 07:52:43 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 29 Oct 2020 07:52:43 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v2]
In-Reply-To: <0_DgjolEWtNQOrJDn_ydLCTYH1gfPwE2tmdoQ9R3hHk=.cecf2d74-6c79-4270-905e-c651f076bbda@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
 <GposOXoXzlhJTPQMl3HchdWpkGz7nUeqMgUoUgVg_Hs=.3e3fee06-e0a1-431a-a18e-9ac736a13574@github.com>
 <b-LQz0W4gJOmMeLHDQXM19jOsAkoMF8aNio8De5BKEM=.3c844420-abc4-4de8-824b-81ec1bdbf2bf@github.com>
 <0_DgjolEWtNQOrJDn_ydLCTYH1gfPwE2tmdoQ9R3hHk=.cecf2d74-6c79-4270-905e-c651f076bbda@github.com>
Message-ID: <5w-53vDjzVgTBPYbZBkfo6hVSlOWJXDTM9oMdvA7LuU=.e76c93fc-919f-4406-bb71-7a00ad622901@github.com>

On Wed, 28 Oct 2020 21:53:11 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> In fact, maybe just inline this literal down in `vm_exit_during_initialization` invocation.
>
> Of course it should align to the left, like in the rest of hotspot. Thanks for noticing!
> 
> As for inlining of the message, there are pros and cons. The arguments should be aligned, so it would become
>   do {                                                                      \
>     if (!(name)) {                                                          \
>       vm_exit_during_initialization("Error", msg);                          \
>                                     "GC mode needs -XX:+" #name " to work correctly"; \
>     }                                                                       \
>   } while (0)
> 
> (not pretty at all, you see).
> 
> After that, there is an option to split the string into multiple lines in attempt to shrink the length, but then the line would become ungreppable (much bigger evil).
> 
> Among options, I decided to respect intention and style of original author, who introduced a variable for err_msg, which is unusual and should have some valid rationale behind, like the one above.

I _am_ the author of those `SHENANDOAH_CHECK_FLAG_SET` blocks ;)

This should be fine:

do {                                                     \
  if (!(name)) {                                         \
    vm_exit_during_initialization("Error",               \
      "GC mode needs -XX:+" #name " to work correctly"); \
  }                                                      \
} while (0)

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

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

From akozlov at openjdk.java.net  Thu Oct 29 08:20:45 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 29 Oct 2020 08:20:45 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v2]
In-Reply-To: <5w-53vDjzVgTBPYbZBkfo6hVSlOWJXDTM9oMdvA7LuU=.e76c93fc-919f-4406-bb71-7a00ad622901@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
 <GposOXoXzlhJTPQMl3HchdWpkGz7nUeqMgUoUgVg_Hs=.3e3fee06-e0a1-431a-a18e-9ac736a13574@github.com>
 <b-LQz0W4gJOmMeLHDQXM19jOsAkoMF8aNio8De5BKEM=.3c844420-abc4-4de8-824b-81ec1bdbf2bf@github.com>
 <0_DgjolEWtNQOrJDn_ydLCTYH1gfPwE2tmdoQ9R3hHk=.cecf2d74-6c79-4270-905e-c651f076bbda@github.com>
 <5w-53vDjzVgTBPYbZBkfo6hVSlOWJXDTM9oMdvA7LuU=.e76c93fc-919f-4406-bb71-7a00ad622901@github.com>
Message-ID: <liIlmlb7GnkLn3exXeTNLYsJyO4wl49yn9Xy9aMWob0=.fd166688-a850-4fbd-aea6-3e4fafd21015@github.com>

On Thu, 29 Oct 2020 07:49:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Of course it should align to the left, like in the rest of hotspot. Thanks for noticing!
>> 
>> As for inlining of the message, there are pros and cons. The arguments should be aligned, so it would become
>>   do {                                                                      \
>>     if (!(name)) {                                                          \
>>       vm_exit_during_initialization("Error", msg);                          \
>>                                     "GC mode needs -XX:+" #name " to work correctly"; \
>>     }                                                                       \
>>   } while (0)
>> 
>> (not pretty at all, you see).
>> 
>> After that, there is an option to split the string into multiple lines in attempt to shrink the length, but then the line would become ungreppable (much bigger evil).
>> 
>> Among options, I decided to respect intention and style of original author, who introduced a variable for err_msg, which is unusual and should have some valid rationale behind, like the one above.
>
> I _am_ the author of those `SHENANDOAH_CHECK_FLAG_SET` blocks ;)
> 
> This should be fine:
> 
> do {                                                     \
>   if (!(name)) {                                         \
>     vm_exit_during_initialization("Error",               \
>       "GC mode needs -XX:+" #name " to work correctly"); \
>   }                                                      \
> } while (0)

OK, if you're OK with that. But let's introduce some consistency with e.g. https://github.com/openjdk/jdk/blob/a804c6a6/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L420 and use 8 spaces for the argument indentation

  do {                                                                      \
    if (!(name)) {                                                          \
      vm_exit_during_initialization("Error",                                \
              "GC mode needs -XX:+" #name " to work correctly");            \
    }                                                                       \
  } while (0)

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

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

From shade at openjdk.java.net  Thu Oct 29 08:20:45 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 29 Oct 2020 08:20:45 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v2]
In-Reply-To: <liIlmlb7GnkLn3exXeTNLYsJyO4wl49yn9Xy9aMWob0=.fd166688-a850-4fbd-aea6-3e4fafd21015@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
 <GposOXoXzlhJTPQMl3HchdWpkGz7nUeqMgUoUgVg_Hs=.3e3fee06-e0a1-431a-a18e-9ac736a13574@github.com>
 <b-LQz0W4gJOmMeLHDQXM19jOsAkoMF8aNio8De5BKEM=.3c844420-abc4-4de8-824b-81ec1bdbf2bf@github.com>
 <0_DgjolEWtNQOrJDn_ydLCTYH1gfPwE2tmdoQ9R3hHk=.cecf2d74-6c79-4270-905e-c651f076bbda@github.com>
 <5w-53vDjzVgTBPYbZBkfo6hVSlOWJXDTM9oMdvA7LuU=.e76c93fc-919f-4406-bb71-7a00ad622901@github.com>
 <liIlmlb7GnkLn3exXeTNLYsJyO4wl49yn9Xy9aMWob0=.fd166688-a850-4fbd-aea6-3e4fafd21015@github.com>
Message-ID: <hHibghEQQnK5IHtiNM_pxSmM9_PPpcDMrnI_KPSDiNk=.1ed189ef-e43b-40c5-b29e-8d094a6ab93d@github.com>

On Thu, 29 Oct 2020 08:15:42 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> I _am_ the author of those `SHENANDOAH_CHECK_FLAG_SET` blocks ;)
>> 
>> This should be fine:
>> 
>> do {                                                     \
>>   if (!(name)) {                                         \
>>     vm_exit_during_initialization("Error",               \
>>       "GC mode needs -XX:+" #name " to work correctly"); \
>>   }                                                      \
>> } while (0)
>
> OK, if you're OK with that. But let's introduce some consistency with e.g. https://github.com/openjdk/jdk/blob/a804c6a6/src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp#L420 and use 8 spaces for the argument indentation
> 
>   do {                                                                      \
>     if (!(name)) {                                                          \
>       vm_exit_during_initialization("Error",                                \
>               "GC mode needs -XX:+" #name " to work correctly");            \
>     }                                                                       \
>   } while (0)

Fine with me!

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

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

From shade at openjdk.java.net  Thu Oct 29 08:26:48 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 29 Oct 2020 08:26:48 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <AXPxHY4vPlQW5Mz-hrKWwA19UXrUv7M8RDDAlOm0ryY=.e050d49d-27b0-49c1-91b6-ba4dc94f5be0@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <dLMEfiF-shTiF833YI6RQ73MohRBi6dPGC-Syu9n9XI=.69df7086-0d0d-4936-b6c4-07e7044993b0@github.com>
 <PbfML5YcPKOduNRZ7b4JpO0DFAQgxjB7XSyA_oLV9ls=.07958a63-9151-4e9e-ac43-9f8a463d7e88@github.com>
 <AXPxHY4vPlQW5Mz-hrKWwA19UXrUv7M8RDDAlOm0ryY=.e050d49d-27b0-49c1-91b6-ba4dc94f5be0@github.com>
Message-ID: <shFYmGihOJdXWJGJdi9WF6QbaenXHlCKkY1bjOR4kYs=.23873524-c95f-4a28-b0ad-17a6de32b669@github.com>

On Wed, 28 Oct 2020 19:55:37 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> But that's the thing that gets my head spinning. Why do we call into `lrb_native` for referents? This contradicts the idea that "native-access is always uncompressed-oops". I think this tries to overload "native" with more meaning that it is equipped to carry. 
>> 
>> I think at very least it should say:
>> 
>>     if (ShenandoahBarrierSet::use_load_reference_barrier_native(decorators, type)) {
>>       // API impedance: when used on native refs, lrb-native necessarily works with full oops,
>>       // but when used for weak/phantom refs, it might need to work with narrow oops.
>>       // Therefore, we need to ask barrier code to look back at UseCompressedOops and
>>       // decide, when lrb-native is not IN_NATIVE. TODO: Resolve this API impedance.
>>       bool maybe_narrow_oop = (decorators & IN_NATIVE) == 0;
>>       load_reference_barrier_native(masm, dst, src, maybe_narrow_oop);
>>     } else {
>>       load_reference_barrier(masm, dst, src);
>>     }
>
> I thought about it today. This whole idea of 'LRB-native' is flawed. What it does is prevent resurrection of objects when loading from a field or off-heap-location that is 'weak' or 'phantom'. This has nothing to do with -native. It has to do with the field being not-strong. For this reason I think we should call that variant of LRB something like LRB-weak instead. This warrants a larger reshuffling that I'd do either before or after this change goes in. I'd probably also merge our 3(!) different runtime LRB impls into one, with templated path to prevent resurrection, etc. I guess the 2 interpreter LRB entries can also be unified, and differ only in the target entry being called.
> 
> The only distinction for which IN_NATIVE is relevant is for figuring out whether or not the reference is compressed or not. That is all.

OK, so that would resolve the `TODO` I suggested in the code comment above, right? If so, we can just put in the code comment for now.

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

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

From stuefe at openjdk.java.net  Thu Oct 29 08:36:44 2020
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 29 Oct 2020 08:36:44 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v2]
In-Reply-To: <-P5id4x50oiTzG6JHl4GD-HJbqYM4juVm9IpsNvXlV4=.7e07be8c-8389-41e2-a563-1f3be709ac51@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
 <dUAqA0Hlaqy6h0KwI7DxXWPdx6tA384oGAndF9di6I4=.fbc7588d-ee94-4856-85a8-170d2e8d92b5@github.com>
 <-P5id4x50oiTzG6JHl4GD-HJbqYM4juVm9IpsNvXlV4=.7e07be8c-8389-41e2-a563-1f3be709ac51@github.com>
Message-ID: <lhpOL7ez4jP7dIfzV0thO0CHjod0ptJ2GwTYAHYPxVo=.6ba093b9-5e3a-4a9b-b6cf-9303e75444b9@github.com>

On Wed, 28 Oct 2020 21:53:19 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/share/utilities/formatBuffer.hpp line 124:
>> 
>>> 122:   // If compilation fails because of ambiguity between this and real constructor, you
>>> 123:   // could drop err_msg use at all.
>>> 124:   inline FormatErrBuffer(const char* msg) { ShouldNotReachHere(); }
>> 
>> I do not think this is a good idea (apart from it being too complex for a not that serious issue).
>> 
>> The asserts fire, of course, only at runtime. But this function is used usually in some error context, as part of of error reporting. I do not think our tests cover all those paths.
>> 
>> Either somehow make this a compile time error or just leave it as it is. We also could, since this buffer object is used usually as input for vm_exit_during_initialization(), give that function a var-arg overload.
>
> Actually, this code prevents a single string argument in compile time. It relies on two constructors to introduce ambiguity in overload resolution that makes C++ compiler complain and abort compilation. Comment above the dummy constructor should clarify that for anyone stepping on compile error.
>   inline FormatErrBuffer(const char* format, ...) ATTRIBUTE_PRINTF(2, 3);
>   inline FormatErrBuffer(const char* msg) { ShouldNotReachHere(); }
> For sanity check, I've used this sample code https://godbolt.org/z/szs6rE
> 
> And the cases that were fixed have been detected by the compiler.
> 
> I don't think that this problem is a serious issue as well. But as for me, it is a minor code complexity increase to ensure that the minor problem of extra string copy will never appear again.

Oh, now I see it. Smart.

But it occurred to me that someone may want to start a err_msg buffer up with a string literal, only to then add additional content via FormatBuffer::append(). So initializing it with a literal and no arguments may be a valid usecase. 

So I'd still prefer keeping this out. Alternatively, if you like to keep it in, could we just not implement the second constructor? Which should give us linker errors if the static check fails.

>> src/hotspot/share/gc/shenandoah/mode/shenandoahMode.hpp line 44:
>> 
>>> 42:     if ((name)) {                                                           \
>>> 43:       const char* msg = "GC mode needs -XX:-" #name " to work correctly";   \
>>> 44:       vm_exit_during_initialization("Error", msg);                          \
>> 
>> Same as above, can be inlined into one call. No need for the temporary variable.
>
> Please see my comment in the thread above.

Whatever you decide with Alexey is fine. The temporary variable is my least favorite option.

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

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

From akozlov at openjdk.java.net  Thu Oct 29 08:42:57 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 29 Oct 2020 08:42:57 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v3]
In-Reply-To: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
Message-ID: <pTdOWbwdc_3ygkOTG2addvFRtWvbYPLXj59M-UOLTWw=.5537aff3-981d-47d0-a761-e71c86f648a6@github.com>

> Hi,
> 
> When a single string without formatting arguments is provided to `err_msg`, it's redundancy, as the same message could be used without any err_msg. This is a follow-up to the discussion https://github.com/openjdk/jdk/pull/812#discussion_r511784050
> 
> Please review a change that makes `err_msg` with a single string to fail compilation. 
> 
> Detected uses of err_msg with a single string were eliminated as well.

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

  shenandoah: inline message to vm_exit call

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/905/files
  - new: https://git.openjdk.java.net/jdk/pull/905/files/52ff2ccb..8a99cdcc

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

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

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

From shade at openjdk.java.net  Thu Oct 29 08:49:47 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 29 Oct 2020 08:49:47 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v3]
In-Reply-To: <lhpOL7ez4jP7dIfzV0thO0CHjod0ptJ2GwTYAHYPxVo=.6ba093b9-5e3a-4a9b-b6cf-9303e75444b9@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
 <dUAqA0Hlaqy6h0KwI7DxXWPdx6tA384oGAndF9di6I4=.fbc7588d-ee94-4856-85a8-170d2e8d92b5@github.com>
 <-P5id4x50oiTzG6JHl4GD-HJbqYM4juVm9IpsNvXlV4=.7e07be8c-8389-41e2-a563-1f3be709ac51@github.com>
 <lhpOL7ez4jP7dIfzV0thO0CHjod0ptJ2GwTYAHYPxVo=.6ba093b9-5e3a-4a9b-b6cf-9303e75444b9@github.com>
Message-ID: <33_QxzGck_FYstuHHF_usmlcLQIL45p-xKBwAWxBQkA=.bf31affe-035f-4466-a2e7-a7cd13cb2617@github.com>

On Thu, 29 Oct 2020 08:20:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Actually, this code prevents a single string argument in compile time. It relies on two constructors to introduce ambiguity in overload resolution that makes C++ compiler complain and abort compilation. Comment above the dummy constructor should clarify that for anyone stepping on compile error.
>>   inline FormatErrBuffer(const char* format, ...) ATTRIBUTE_PRINTF(2, 3);
>>   inline FormatErrBuffer(const char* msg) { ShouldNotReachHere(); }
>> For sanity check, I've used this sample code https://godbolt.org/z/szs6rE
>> 
>> And the cases that were fixed have been detected by the compiler.
>> 
>> I don't think that this problem is a serious issue as well. But as for me, it is a minor code complexity increase to ensure that the minor problem of extra string copy will never appear again.
>
> Oh, now I see it. Smart.
> 
> But it occurred to me that someone may want to start a err_msg buffer up with a string literal, only to then add additional content via FormatBuffer::append(). So initializing it with a literal and no arguments may be a valid usecase. 
> 
> So I'd still prefer keeping this out. Alternatively, if you like to keep it in, could we just not implement the second constructor? Which should give us linker errors if the static check fails.

+1 to leave this undefined to get a linkage error. There are already precedents to do this in Hotspot code, for example

  Node(const Node&);            // not defined; linker error to use these
  ...
  // should never be used
  AdapterHandlerEntry();

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

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

From rkennke at openjdk.java.net  Thu Oct 29 11:08:01 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 29 Oct 2020 11:08:01 GMT
Subject: RFR: 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB
 [v3]
In-Reply-To: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
References: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
Message-ID: <5F1weRisz_IRRzC34eTZrYVOjWplTcvSCFg-rvppDfU=.afcc3482-438c-4eae-a1b8-8b1b21e811ac@github.com>

> JDK-8254314 introduced the following code:
> 
>     if (in1->bottom_type() == TypePtr::NULL_PTR &&
>         (in1->Opcode() != Op_ShenandoahLoadReferenceBarrier || !((ShenandoahLoadReferenceBarrierNode*)in1)->is_native())) {
>       in2 = step_over_gc_barrier(in2);
>     }
> 
> However, the check for LRB and !native are the wrong way around: they should check if *in2* are not native LRB.
> 
> The bug is currently only observed in the conc-weakrefs branch, but may manifest (rarely) in mainline too. 
> 
> I am also putting in some refactoring to avoid duped code for good measure.
> 
> Testing: hotspot_gc_shenandoah (also in conc-weakrefs-branch where it manifests)

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Inline (i.e. revert) maybe_step_over_cmpp_inputs()
 - Clarify comment in maybe_step_over_cmpp_inputs()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/902/files
  - new: https://git.openjdk.java.net/jdk/pull/902/files/922d51ff..6169f948

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

  Stats: 24 lines in 2 files changed: 11 ins; 11 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/902.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/902/head:pull/902

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

From shade at openjdk.java.net  Thu Oct 29 11:08:01 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 29 Oct 2020 11:08:01 GMT
Subject: RFR: 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB
 [v3]
In-Reply-To: <5F1weRisz_IRRzC34eTZrYVOjWplTcvSCFg-rvppDfU=.afcc3482-438c-4eae-a1b8-8b1b21e811ac@github.com>
References: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
 <5F1weRisz_IRRzC34eTZrYVOjWplTcvSCFg-rvppDfU=.afcc3482-438c-4eae-a1b8-8b1b21e811ac@github.com>
Message-ID: <7JZ_XMAcqF1d7yNQC84QhZEWHa82N00K4h3CWRiEnCY=.0d5ce3b5-3117-4282-82ea-19527f9f87ec@github.com>

On Thu, 29 Oct 2020 11:05:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> JDK-8254314 introduced the following code:
>> 
>>     if (in1->bottom_type() == TypePtr::NULL_PTR &&
>>         (in1->Opcode() != Op_ShenandoahLoadReferenceBarrier || !((ShenandoahLoadReferenceBarrierNode*)in1)->is_native())) {
>>       in2 = step_over_gc_barrier(in2);
>>     }
>> 
>> However, the check for LRB and !native are the wrong way around: they should check if *in2* are not native LRB.
>> 
>> The bug is currently only observed in the conc-weakrefs branch, but may manifest (rarely) in mainline too. 
>> 
>> I am also putting in some refactoring to avoid duped code for good measure.
>> 
>> Testing: hotspot_gc_shenandoah (also in conc-weakrefs-branch where it manifests)
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Inline (i.e. revert) maybe_step_over_cmpp_inputs()
>  - Clarify comment in maybe_step_over_cmpp_inputs()

Marked as reviewed by shade (Reviewer).

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

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

From rkennke at openjdk.java.net  Thu Oct 29 11:09:08 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 29 Oct 2020 11:09:08 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v21]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <TvbwgLo6Dg_wIillS6FyhlC87nvfEPkCWQJgIk51z5Y=.5db866df-540f-447e-ac63-956a77ea4554@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Call into native-LRB on unknown oop strenght (i.e. reflection) too
 - Put in comment about API impedence mismatch around interpreter native LRB

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/072e3817..96f2a3ca

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=19-20

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

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

From rkennke at openjdk.java.net  Thu Oct 29 11:17:00 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 29 Oct 2020 11:17:00 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v22]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <oUjMztKKXQsWSI7M2kNWszf3dsE4XjMg3K-pV8MGFms=.1954b744-7869-42b4-897b-c8868705e4ff@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Some more ShMarkTask cleanups

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/96f2a3ca..f2bf4edc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=20-21

  Stats: 31 lines in 1 file changed: 10 ins; 6 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From rkennke at openjdk.java.net  Thu Oct 29 12:07:00 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 29 Oct 2020 12:07:00 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v23]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <nb2dSF5fqiaJqJE7SsZtx2Q7Wsja2FfJnZEVrX_1GiI=.62067518-0de1-4b4b-934a-6c83a8096133@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Rename mark_final -> mark_weak and several cleanups (by shade)

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/f2bf4edc..25879840

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=21-22

  Stats: 68 lines in 7 files changed: 2 ins; 18 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From shade at openjdk.java.net  Thu Oct 29 12:07:01 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 29 Oct 2020 12:07:01 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <I3zHDcPGQi_Km7CNwaXEnU1YHsv79ZbEP3tBEBngsoI=.1bd2f0da-1b91-4ac8-977c-b5ae6a1b9493@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <I3zHDcPGQi_Km7CNwaXEnU1YHsv79ZbEP3tBEBngsoI=.1bd2f0da-1b91-4ac8-977c-b5ae6a1b9493@github.com>
Message-ID: <gdS-KOVKm0I45x_MzMLCvE74zkoWZWnPT8sHArMKciw=.d5e42c59-e8b0-43b8-8da8-dc368dd58403@github.com>

On Tue, 27 Oct 2020 14:54:01 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.inline.hpp line 264:
>> 
>>> 262:         marked = mark_context->mark_strong(obj, marked_first);
>>> 263:       } else {
>>> 264:         marked = mark_context->mark_final(obj, marked_first);
>> 
>> Is this `mark_final` actually `mark_weak`?
>
> We could name it so, but it really means 'reachable through a FinalReference' so 'finalizably reachable' and 'marked final(izable)' seems the more correct term. It is weaker than 'strong' though, so yeah we could rename this. WDYT?

I sent you a patch with this rename and collateral improvements. This discussion can be resolved.

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

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

From shade at openjdk.java.net  Thu Oct 29 12:07:01 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 29 Oct 2020 12:07:01 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <jjmqDjqJwJmUne6chF4k2lEw2n4-3KMfYI_uIFvYAWg=.02e45413-3170-4e77-b79f-9631dc21d2e1@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <I3zHDcPGQi_Km7CNwaXEnU1YHsv79ZbEP3tBEBngsoI=.1bd2f0da-1b91-4ac8-977c-b5ae6a1b9493@github.com>
 <jjmqDjqJwJmUne6chF4k2lEw2n4-3KMfYI_uIFvYAWg=.02e45413-3170-4e77-b79f-9631dc21d2e1@github.com>
Message-ID: <iCTDwMN5lqqwtvA4dhYd7-lyDOpnFRUJVjUBNIxu0bA=.937582fb-3e44-4b8d-a149-0f9e7f4f7cc7@github.com>

On Tue, 27 Oct 2020 14:56:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yes, that is true for mark_final(), but not for mark_strong(). I am changing it as you suggested.
>
> No wait, maybe that's fine then. Let me think about it.

Same, patch sent, improvements delivered. Can resolve this discussion.

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

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

From rkennke at openjdk.java.net  Thu Oct 29 12:58:58 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 29 Oct 2020 12:58:58 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v24]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <Fc-fSz24iRrBM7VTJj9pkTvp6_Oo5Zi0Tg_5w7wpJO4=.5c17a4cb-a96f-49a6-8b56-a45e9579838e@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Pass marking-strength through chunked arrays

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/25879840..f85ab85d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=22-23

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

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

From rkennke at openjdk.java.net  Thu Oct 29 12:59:45 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 29 Oct 2020 12:59:45 GMT
Subject: Integrated: 8255534: Shenandoah: Fix CmpP optimization wrt native-LRB
In-Reply-To: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
References: <P8ThnFgc_TWYThy216qW2MCk6oL2okmhLttY1OV3OoM=.32295a5c-43bf-42b2-9827-9f6bb2bdc90d@github.com>
Message-ID: <6ItzC6IPM6iggsCu2x3g0_SUdhiiiqoLxxkr57lzfhk=.a38a63e8-3d2c-4940-a4a2-f7d19ca3eaa6@github.com>

On Wed, 28 Oct 2020 12:34:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> JDK-8254314 introduced the following code:
> 
>     if (in1->bottom_type() == TypePtr::NULL_PTR &&
>         (in1->Opcode() != Op_ShenandoahLoadReferenceBarrier || !((ShenandoahLoadReferenceBarrierNode*)in1)->is_native())) {
>       in2 = step_over_gc_barrier(in2);
>     }
> 
> However, the check for LRB and !native are the wrong way around: they should check if *in2* are not native LRB.
> 
> The bug is currently only observed in the conc-weakrefs branch, but may manifest (rarely) in mainline too. 
> 
> I am also putting in some refactoring to avoid duped code for good measure.
> 
> Testing: hotspot_gc_shenandoah (also in conc-weakrefs-branch where it manifests)

This pull request has now been integrated.

Changeset: faf23de5
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/faf23de5
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8255534: Shenandoah: Fix CmpP optimization wrt native-LRB

Reviewed-by: shade

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

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

From rkennke at openjdk.java.net  Thu Oct 29 13:18:55 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 29 Oct 2020 13:18:55 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v25]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <gD613jKWSouhHxyFAovcSDJJrD5sun6Ccls-Rdcevu0=.56aa59e3-c130-4c5e-9c52-51e4ab2709b0@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 81 commits:

 - Fix merge mistake
 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Pass marking-strength through chunked arrays
 - Rename mark_final -> mark_weak and several cleanups (by shade)
 - Some more ShMarkTask cleanups
 - Call into native-LRB on unknown oop strenght (i.e. reflection) too
 - Put in comment about API impedence mismatch around interpreter native LRB
 - Add missing merge changes of shenandoahTaskQueue.hpp
 - Merge branch 'master' into shenandoah-concurrent-weakrefs
 - Consolidate native-LRB invocation
 - ... and 71 more: https://git.openjdk.java.net/jdk/compare/faf23de5...75958efb

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

Changes: https://git.openjdk.java.net/jdk/pull/505/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=24
  Stats: 2425 lines in 55 files changed: 1651 ins; 565 del; 209 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From shade at openjdk.java.net  Thu Oct 29 14:09:50 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 29 Oct 2020 14:09:50 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v12]
In-Reply-To: <I3zHDcPGQi_Km7CNwaXEnU1YHsv79ZbEP3tBEBngsoI=.1bd2f0da-1b91-4ac8-977c-b5ae6a1b9493@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
 <Vc-hQpx09QAQq8OqYwuQBMxJRP1n6lurmzqXitKv1Fg=.69ffcdb0-687e-4900-b26a-42ec1f619e5a@github.com>
 <qNJQ_igZwl4qfZqn2mtC1imiZkR_F1K7aQ5xeNO8So8=.ce6975b4-3b9b-4e68-8aee-7660424840ce@github.com>
 <I3zHDcPGQi_Km7CNwaXEnU1YHsv79ZbEP3tBEBngsoI=.1bd2f0da-1b91-4ac8-977c-b5ae6a1b9493@github.com>
Message-ID: <VQyh6P1E5wazHBiFzIzpk32TpAu7Jnly2SeztSo5xP8=.775cda6b-58f1-48cf-b2fc-a0f88e51475c@github.com>

On Tue, 27 Oct 2020 14:52:09 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahConcurrentMark.cpp line 81:
>> 
>>> 79:   _heap(ShenandoahHeap::heap()),
>>> 80:   _mark_context(_heap->marking_context()),
>>> 81:   _strong(true)
>> 
>> Do we want to turn this to yet another template parameter, like for dedup? That would also resolve passing `true` or `false` to `strong` argument without comments.
>
> We need to switch strength in ShenandoahConcurrentMark::do_task() and we get passed-in a ready closure there. I am not sure how we could do that with template-args. Template args only make sense for things that don't change during marking.

Tried to see what if templating can be done. I think the major hurdle is that weak _tasks_ can be stolen by other workers. Which means every worker should check for weakness for every task, and thus would require changing the closure "flavor" on the fly. This seems like a no-go. You can resolve this conversation.

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

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

From rkennke at openjdk.java.net  Thu Oct 29 14:15:04 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 29 Oct 2020 14:15:04 GMT
Subject: RFR: 8254315: Shenandoah: Concurrent weak reference processing
 [v26]
In-Reply-To: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
References: <8byaPRNFSF4tG_fA2jxtiDwcEbbMS_Zmk39w86ugIV4=.6a942481-9fd0-44f7-a42a-3668b22bea3e@github.com>
Message-ID: <KnrzjxqVmyEV7WqbVZzvFkzcKujfiHJB9eLys_Hs2Yc=.a3714d13-fe6f-4082-96b8-dafcf1215347@github.com>

> Until now, references (as in java.lang.ref.Reference and its subclasses WeakReference, SoftReference, PhantomReference and the non-public FinalReference - I'll collectively call them weak references for the purpose of clarity). Workloads that make heavvy use of such weak references will therefore potentially cause significant GC pauses.
> 
> There are 3 main items that contribute to pause time linear to number of references, or worse:
> - We need to scan and consider each reference on the various 'discovered' lists.
> - We need to mark through subgraph of objects that are reachable only through FinalReference. Notice that this is theoretically only bounded by the live data set size.
> - Finally, all no-longer-reachable references need to be enqueued in the 'pending list'
> 
> The problem is somewhat mitigated by pre-cleaning the discovered list: Any weak reference that we find to be strongly reachable will be removed before we go into the final-mark-pause. However, that is only a band-aid.
> 
> The solution to this is two-fold:
> 1. Extend concurrent marking to also mark the 'finalizable' subgraph of the heap. This requires to extend the marking bitmap to allow for two kinds of reachability: each object can now be strongly and finalizably reachable. Whenever marking encounters a FinalReference, it will mark through the referent and switch to 'finalizably' reachability for all objects starting from the referent. When marking encounters finalizably reachable objects while marking strongly, it will 'upgrade' reachability of such objects to strongly reachable. All of this can be done concurrently. Any encounter of a Reference (or subclass) object will enqueue that object into a thread-local 'discovered' list. Except for FinalReference, marking stops there, and does not mark through the referent.
> 2. Concurrent processing is performed after the final-mark pause. GC workers scan all discovered lists that have been collected by concurrent marking, and depending on reachability of the referent, either drop the Reference, or enqueue it into the global 'pending' list (from where it will be processed by Java reference handler thread). In addition to that, we must ensure that no referents become resurrected by accessing Reference.get() on it. In order to achieve this, we employ special barriers in Reference.get() intrinsics that return NULL when the referent is not reachable.
> 
> Testing: hotspot_gc_shenadoah (release+fastdebug, x86+aarch64), specjvm+specjbb without regressions, tier1, tier2, vmTestbase_vm_metaspace, vmTestbase_nsk_jvmti, with -XX:+UseShenandoahGC without regressions, specjvm with various levels of verification

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Invert strong/weak in marking tasks and related code

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/505/files
  - new: https://git.openjdk.java.net/jdk/pull/505/files/75958efb..60b39cb0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=505&range=24-25

  Stats: 58 lines in 7 files changed: 4 ins; 4 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/505.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/505/head:pull/505

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

From akozlov at openjdk.java.net  Thu Oct 29 21:13:00 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 29 Oct 2020 21:13:00 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v4]
In-Reply-To: <33_QxzGck_FYstuHHF_usmlcLQIL45p-xKBwAWxBQkA=.bf31affe-035f-4466-a2e7-a7cd13cb2617@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
 <dUAqA0Hlaqy6h0KwI7DxXWPdx6tA384oGAndF9di6I4=.fbc7588d-ee94-4856-85a8-170d2e8d92b5@github.com>
 <-P5id4x50oiTzG6JHl4GD-HJbqYM4juVm9IpsNvXlV4=.7e07be8c-8389-41e2-a563-1f3be709ac51@github.com>
 <lhpOL7ez4jP7dIfzV0thO0CHjod0ptJ2GwTYAHYPxVo=.6ba093b9-5e3a-4a9b-b6cf-9303e75444b9@github.com>
 <33_QxzGck_FYstuHHF_usmlcLQIL45p-xKBwAWxBQkA=.bf31affe-035f-4466-a2e7-a7cd13cb2617@github.com>
Message-ID: <RdxPX4PvhM9kSulEnWNHVyMGacszfwb9BRRvDlypFmY=.b15b7c15-98d4-425f-a009-93a83fafbbf3@github.com>

On Thu, 29 Oct 2020 08:47:12 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Oh, now I see it. Smart.
>> 
>> But it occurred to me that someone may want to start a err_msg buffer up with a string literal, only to then add additional content via FormatBuffer::append(). So initializing it with a literal and no arguments may be a valid usecase. 
>> 
>> So I'd still prefer keeping this out. Alternatively, if you like to keep it in, could we just not implement the second constructor? Which should give us linker errors if the static check fails.
>
> +1 to leave this undefined to get a linkage error. There are already precedents to do this in Hotspot code, for example
> 
>   Node(const Node&);            // not defined; linker error to use these
>   ...
>   // should never be used
>   AdapterHandlerEntry();

This is a good suggestion. Link-time failure is certainly better than runtime one, thanks!

Although err_msg was implemented with FormatBuffer since the beginning [1], I assume it should be an implementation detail. Otherwise there would be no function-like err_msg thing. And at the present, there is only a single case of append to err_msg.

FormatErrBuffer can inherit FormatBuffer privately. It will completely remove err_msg interface relation with FormatBuffer, which is aligned with the most of current uses.

Although I don't clearly understand reasons not to introduce this (beside it may be a bit over-engineered, but without implications to maintainability, I suppose), this may change assumptions about err_msg.

[1] http://hg.openjdk.java.net/jdk10/jdk10/hotspot/rev/f03d0a26bf83#l32.32

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

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

From akozlov at openjdk.java.net  Thu Oct 29 21:13:00 2020
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 29 Oct 2020 21:13:00 GMT
Subject: RFR: 8255416: Investigate err_msg to detect unnecessary uses	 [v4]
In-Reply-To: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
References: <pVNen8R_HxTUhsUt0yEHp6TApDODUTQpJAolmdKiPaY=.09ceeca5-3ddd-4293-8026-4a0d6eb5e798@github.com>
Message-ID: <40uuidQshCOFVs9ptZYLfxiesDU-8sVW6rU_bpLeGa8=.e53d49eb-5b31-4916-8ad7-0d1872947b2d@github.com>

> Hi,
> 
> When a single string without formatting arguments is provided to `err_msg`, it's redundancy, as the same message could be used without any err_msg. This is a follow-up to the discussion https://github.com/openjdk/jdk/pull/812#discussion_r511784050
> 
> Please review a change that makes `err_msg` with a single string to fail compilation. 
> 
> Detected uses of err_msg with a single string were eliminated as well.

Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:

 - Unlink err_msg interface from FormatBuffer
 - Remove implementation of the dummy ctor

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/905/files
  - new: https://git.openjdk.java.net/jdk/pull/905/files/8a99cdcc..47ff851e

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

  Stats: 11 lines in 4 files changed: 4 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/905.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/905/head:pull/905

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

From rkennke at openjdk.java.net  Fri Oct 30 11:13:52 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Oct 2020 11:13:52 GMT
Subject: RFR: 8255614: Shenandoah: Consolidate/streamline runtime LRBs
Message-ID: <3CaMGD6aXUxD8SxDhn1XxU-c0I1NM6r-iosxLLScZT0=.8a0e96ba-17a8-4d59-bcac-7febc85970a1@github.com>

Currently, our various LRB entry points are a mess, and quite inefficient too.
- We have three entry points, one is checking for null, and calls a non-null version, but that checks for null again
- We don't have to check for null at all: it can be subsumed in the cset-check
- The LRB resolves forwardee even though has_forwarded_objects() and in_cset() has not been checked
- The LRB entry is not inlineable

The proposed change coalesces the 3 entries into one, moves it to shenandoahBarrierSet.inline.hpp and make it inlineable, rearranges the impl to allow cset-check to subsume the NULL-check. As a bonus, it pushes the NULL-check around keep-alive down after the (compile-time) check for weak-ref, so that this path becomes a no-op in the majority of cases.

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

Commit messages:
 - 8255614: Shenandoah: Consolidate/streamline runtime LRBs

Changes: https://git.openjdk.java.net/jdk/pull/953/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=953&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255614
  Stats: 105 lines in 7 files changed: 36 ins; 51 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/953.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/953/head:pull/953

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

From zgu at openjdk.java.net  Fri Oct 30 13:12:05 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 30 Oct 2020 13:12:05 GMT
Subject: RFR: 8255614: Shenandoah: Consolidate/streamline runtime LRBs
In-Reply-To: <3CaMGD6aXUxD8SxDhn1XxU-c0I1NM6r-iosxLLScZT0=.8a0e96ba-17a8-4d59-bcac-7febc85970a1@github.com>
References: <3CaMGD6aXUxD8SxDhn1XxU-c0I1NM6r-iosxLLScZT0=.8a0e96ba-17a8-4d59-bcac-7febc85970a1@github.com>
Message-ID: <breyJIstAnCF46jgqv5QXXNScd26QMOlnh4mmsWa-u8=.27a4b7ff-bd4d-4ff0-990c-89f6dfaf53e3@github.com>

On Fri, 30 Oct 2020 11:06:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, our various LRB entry points are a mess, and quite inefficient too.
> - We have three entry points, one is checking for null, and calls a non-null version, but that checks for null again
> - We don't have to check for null at all: it can be subsumed in the cset-check
> - The LRB resolves forwardee even though has_forwarded_objects() and in_cset() has not been checked
> - The LRB entry is not inlineable
> 
> The proposed change coalesces the 3 entries into one, moves it to shenandoahBarrierSet.inline.hpp and make it inlineable, rearranges the impl to allow cset-check to subsume the NULL-check. As a bonus, it pushes the NULL-check around keep-alive down after the (compile-time) check for weak-ref, so that this path becomes a no-op in the majority of cases.

src/hotspot/share/gc/shenandoah/shenandoahBarrierSet.inline.hpp line 83:

> 81:     return obj;
> 82:   }
> 83:   if (_heap->has_forwarded_objects() &&

Please add an assertion for obj != NULL

src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp line 49:

> 47: bool ShenandoahCollectionSet::is_in_loc(void* p) const {
> 48:   assert(p == NULL || _heap->is_in(p), "Must be in the heap");
> 49:   uintx index = ((uintx) p) >> _region_size_bytes_shift;

Is this right? if heap is not zero-based

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

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

From rkennke at openjdk.java.net  Fri Oct 30 13:33:12 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Oct 2020 13:33:12 GMT
Subject: RFR: 8255614: Shenandoah: Consolidate/streamline runtime LRBs [v2]
In-Reply-To: <breyJIstAnCF46jgqv5QXXNScd26QMOlnh4mmsWa-u8=.27a4b7ff-bd4d-4ff0-990c-89f6dfaf53e3@github.com>
References: <3CaMGD6aXUxD8SxDhn1XxU-c0I1NM6r-iosxLLScZT0=.8a0e96ba-17a8-4d59-bcac-7febc85970a1@github.com>
 <breyJIstAnCF46jgqv5QXXNScd26QMOlnh4mmsWa-u8=.27a4b7ff-bd4d-4ff0-990c-89f6dfaf53e3@github.com>
Message-ID: <Si0f6NNPtkagAOMS3SLHK7rdvYfbba3scOAzWa28tCE=.3de9f5e5-7264-450c-abb7-e31cdbe65604@github.com>

On Fri, 30 Oct 2020 13:05:23 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add null-check
>
> src/hotspot/share/gc/shenandoah/shenandoahCollectionSet.inline.hpp line 49:
> 
>> 47: bool ShenandoahCollectionSet::is_in_loc(void* p) const {
>> 48:   assert(p == NULL || _heap->is_in(p), "Must be in the heap");
>> 49:   uintx index = ((uintx) p) >> _region_size_bytes_shift;
> 
> Is this right? if heap is not zero-based

Yes. The biased cset-map is allocated such that NULL object maps to a special page that always yields false when checking in_cset(NULL). We use that same technique in JIT-compiled code to avoid explicit NULL-checks.

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

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

From rkennke at openjdk.java.net  Fri Oct 30 13:33:11 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Oct 2020 13:33:11 GMT
Subject: RFR: 8255614: Shenandoah: Consolidate/streamline runtime LRBs [v2]
In-Reply-To: <3CaMGD6aXUxD8SxDhn1XxU-c0I1NM6r-iosxLLScZT0=.8a0e96ba-17a8-4d59-bcac-7febc85970a1@github.com>
References: <3CaMGD6aXUxD8SxDhn1XxU-c0I1NM6r-iosxLLScZT0=.8a0e96ba-17a8-4d59-bcac-7febc85970a1@github.com>
Message-ID: <S1Av_p43IffQGr4RjPCcDrOKTF2I-AiGPfUORzvWalc=.3756c7fe-43aa-4e30-a557-81b929d2e42d@github.com>

> Currently, our various LRB entry points are a mess, and quite inefficient too.
> - We have three entry points, one is checking for null, and calls a non-null version, but that checks for null again
> - We don't have to check for null at all: it can be subsumed in the cset-check
> - The LRB resolves forwardee even though has_forwarded_objects() and in_cset() has not been checked
> - The LRB entry is not inlineable
> 
> The proposed change coalesces the 3 entries into one, moves it to shenandoahBarrierSet.inline.hpp and make it inlineable, rearranges the impl to allow cset-check to subsume the NULL-check. As a bonus, it pushes the NULL-check around keep-alive down after the (compile-time) check for weak-ref, so that this path becomes a no-op in the majority of cases.

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Add null-check

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/953/files
  - new: https://git.openjdk.java.net/jdk/pull/953/files/f2b87253..99db8d30

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

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

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

From zgu at openjdk.java.net  Fri Oct 30 14:12:59 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 30 Oct 2020 14:12:59 GMT
Subject: RFR: 8255614: Shenandoah: Consolidate/streamline runtime LRBs [v2]
In-Reply-To: <S1Av_p43IffQGr4RjPCcDrOKTF2I-AiGPfUORzvWalc=.3756c7fe-43aa-4e30-a557-81b929d2e42d@github.com>
References: <3CaMGD6aXUxD8SxDhn1XxU-c0I1NM6r-iosxLLScZT0=.8a0e96ba-17a8-4d59-bcac-7febc85970a1@github.com>
 <S1Av_p43IffQGr4RjPCcDrOKTF2I-AiGPfUORzvWalc=.3756c7fe-43aa-4e30-a557-81b929d2e42d@github.com>
Message-ID: <qbtJM8OhqwICO8C1kNmhhXdNZMZ_Ni9NYh_2Ptq5FVs=.8db75074-a29a-4969-ae9e-4912cde9fe08@github.com>

On Fri, 30 Oct 2020 13:33:11 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Currently, our various LRB entry points are a mess, and quite inefficient too.
>> - We have three entry points, one is checking for null, and calls a non-null version, but that checks for null again
>> - We don't have to check for null at all: it can be subsumed in the cset-check
>> - The LRB resolves forwardee even though has_forwarded_objects() and in_cset() has not been checked
>> - The LRB entry is not inlineable
>> 
>> The proposed change coalesces the 3 entries into one, moves it to shenandoahBarrierSet.inline.hpp and make it inlineable, rearranges the impl to allow cset-check to subsume the NULL-check. As a bonus, it pushes the NULL-check around keep-alive down after the (compile-time) check for weak-ref, so that this path becomes a no-op in the majority of cases.
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add null-check

Marked as reviewed by zgu (Reviewer).

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

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

From rkennke at openjdk.java.net  Fri Oct 30 17:15:56 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Oct 2020 17:15:56 GMT
Subject: Integrated: 8255614: Shenandoah: Consolidate/streamline runtime LRBs
In-Reply-To: <3CaMGD6aXUxD8SxDhn1XxU-c0I1NM6r-iosxLLScZT0=.8a0e96ba-17a8-4d59-bcac-7febc85970a1@github.com>
References: <3CaMGD6aXUxD8SxDhn1XxU-c0I1NM6r-iosxLLScZT0=.8a0e96ba-17a8-4d59-bcac-7febc85970a1@github.com>
Message-ID: <I_X_jkgOgzhAg9rk_GEtsfHyCZ5Z34taiVleXCCJsfo=.42f11389-75e3-476f-9406-cc920dc8a029@github.com>

On Fri, 30 Oct 2020 11:06:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Currently, our various LRB entry points are a mess, and quite inefficient too.
> - We have three entry points, one is checking for null, and calls a non-null version, but that checks for null again
> - We don't have to check for null at all: it can be subsumed in the cset-check
> - The LRB resolves forwardee even though has_forwarded_objects() and in_cset() has not been checked
> - The LRB entry is not inlineable
> 
> The proposed change coalesces the 3 entries into one, moves it to shenandoahBarrierSet.inline.hpp and make it inlineable, rearranges the impl to allow cset-check to subsume the NULL-check. As a bonus, it pushes the NULL-check around keep-alive down after the (compile-time) check for weak-ref, so that this path becomes a no-op in the majority of cases.

This pull request has now been integrated.

Changeset: 8600d0d9
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8600d0d9
Stats:     106 lines in 7 files changed: 37 ins; 51 del; 18 mod

8255614: Shenandoah: Consolidate/streamline runtime LRBs

Reviewed-by: zgu

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

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

From nevgeniev at gmail.com  Fri Oct 30 17:54:13 2020
From: nevgeniev at gmail.com (Nick Evgeniev)
Date: Fri, 30 Oct 2020 12:54:13 -0500
Subject: C2 compiler fails with shenandoah enabled in jdk8 build 262
Message-ID: <CAEyj=Y4QLBYgScYnX6YpQZ+kg5=qzm8gUGK3jPQSJGZL-hyn9g@mail.gmail.com>

Hi,

I'm running jdk8 build 262 from redhat. And C2 fails to compile a  method
(have a replay file from prod crash).

When I replay that file with CMS instead of Shenandoah everything is fine.
With shenandoah it dumps core with:

# assert(Compile::current()->live_nodes() <
Compile::current()->max_node_limit()) failed: Live Node limit exceeded limit

I found https://bugs.openjdk.java.net/browse/JDK-8237950 by Alexei Shipelev
which seems to be relevant. Not sure if it's applicable to jdk8 though.

My question is should the fix under the link above be backported to jdk8
(when?)  or it's not relevant? It's a show stopper for us to adopt
shenandoah :)

From rkennke at openjdk.java.net  Fri Oct 30 18:20:00 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Oct 2020 18:20:00 GMT
Subject: RFR: 8255691: Shenandoah: Invoke native-LRB only on non-strong refs
Message-ID: <2O7ZS_-HyPZpm5m2sMTf-dZv8Qkw3tB47hMgORkckoU=.a58d7945-a2ea-4f76-9e01-540521bd77ea@github.com>

The way that current native LRB is implemented is wrong (but non-fatal) and misleading. It's purpose is to prevent resurrection of unreachable non-strong references, and it should only be invoked on non-strong references, not all native references. This distinction will become even more important once we get concurrent reference processing: then we also want to invoke this barrier on referent-loads.

This changes the runtime-part of native-LRB so that it is only invoked when it's invoked with non-strong reference decorator. Otherwise it acts as regular LRB.

Testing: hotspot_gc_shenandoah

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

Commit messages:
 - 8255691: Shenandoah: Invoke native-LRB only on non-strong refs

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

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

From rkennke at openjdk.java.net  Fri Oct 30 18:44:09 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Oct 2020 18:44:09 GMT
Subject: RFR: 8255691: Shenandoah: Invoke native-LRB only on non-strong
 refs [v2]
In-Reply-To: <2O7ZS_-HyPZpm5m2sMTf-dZv8Qkw3tB47hMgORkckoU=.a58d7945-a2ea-4f76-9e01-540521bd77ea@github.com>
References: <2O7ZS_-HyPZpm5m2sMTf-dZv8Qkw3tB47hMgORkckoU=.a58d7945-a2ea-4f76-9e01-540521bd77ea@github.com>
Message-ID: <dwuQyWcGj2Hb4y1Q6DtAEj0lZierzABDU2EWifHXuVw=.e81b37cc-f82e-4753-bf9a-003103cf74cb@github.com>

> The way that current native LRB is implemented is wrong (but non-fatal) and misleading. It's purpose is to prevent resurrection of unreachable non-strong references, and it should only be invoked on non-strong references, not all native references. This distinction will become even more important once we get concurrent reference processing: then we also want to invoke this barrier on referent-loads.
> 
> This changes the runtime-part of native-LRB so that it is only invoked when it's invoked with non-strong reference decorator. Otherwise it acts as regular LRB.
> 
> Testing: hotspot_gc_shenandoah

Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:

 - Fix condition in SBS::use_load_reference_barrier_native()
 - Invoke native LRB only on non-strong native refs from interpreter and compiler too

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/961/files
  - new: https://git.openjdk.java.net/jdk/pull/961/files/34a0d0e9..9911e5b5

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

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

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

From zgu at openjdk.java.net  Fri Oct 30 18:44:10 2020
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Fri, 30 Oct 2020 18:44:10 GMT
Subject: RFR: 8255691: Shenandoah: Invoke native-LRB only on non-strong
 refs [v2]
In-Reply-To: <dwuQyWcGj2Hb4y1Q6DtAEj0lZierzABDU2EWifHXuVw=.e81b37cc-f82e-4753-bf9a-003103cf74cb@github.com>
References: <2O7ZS_-HyPZpm5m2sMTf-dZv8Qkw3tB47hMgORkckoU=.a58d7945-a2ea-4f76-9e01-540521bd77ea@github.com>
 <dwuQyWcGj2Hb4y1Q6DtAEj0lZierzABDU2EWifHXuVw=.e81b37cc-f82e-4753-bf9a-003103cf74cb@github.com>
Message-ID: <mRzRJC5TOiNr2L_I8EFgQovZRfc882FM5BZ1xkFZZvg=.60ffdfe6-35e5-4088-904a-94796b2e6f66@github.com>

On Fri, 30 Oct 2020 18:41:34 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> The way that current native LRB is implemented is wrong (but non-fatal) and misleading. It's purpose is to prevent resurrection of unreachable non-strong references, and it should only be invoked on non-strong references, not all native references. This distinction will become even more important once we get concurrent reference processing: then we also want to invoke this barrier on referent-loads.
>> 
>> This changes the runtime-part of native-LRB so that it is only invoked when it's invoked with non-strong reference decorator. Otherwise it acts as regular LRB.
>> 
>> Testing: hotspot_gc_shenandoah
>
> Roman Kennke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix condition in SBS::use_load_reference_barrier_native()
>  - Invoke native LRB only on non-strong native refs from interpreter and compiler too

Just a quick scan. 
We probably should also rename ShenandoahRuntime::load_reference_barrier_native() to something like load_reference_barrier_on_weak()(?)  also BS::use_load_reference_barrier_native()

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

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

From rkennke at openjdk.java.net  Fri Oct 30 19:39:07 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 30 Oct 2020 19:39:07 GMT
Subject: RFR: 8255691: Shenandoah: Invoke native-LRB only on non-strong
 refs [v3]
In-Reply-To: <2O7ZS_-HyPZpm5m2sMTf-dZv8Qkw3tB47hMgORkckoU=.a58d7945-a2ea-4f76-9e01-540521bd77ea@github.com>
References: <2O7ZS_-HyPZpm5m2sMTf-dZv8Qkw3tB47hMgORkckoU=.a58d7945-a2ea-4f76-9e01-540521bd77ea@github.com>
Message-ID: <2wI5SLQjP_SmJOstjPHk3ct5b1Pr3nZEvi97NWCbo-E=.39961cac-4a3b-48c4-b608-425f024020b0@github.com>

> The way that current native LRB is implemented is wrong (but non-fatal) and misleading. It's purpose is to prevent resurrection of unreachable non-strong references, and it should only be invoked on non-strong references, not all native references. This distinction will become even more important once we get concurrent reference processing: then we also want to invoke this barrier on referent-loads.
> 
> This changes the runtime-part of native-LRB so that it is only invoked when it's invoked with non-strong reference decorator. Otherwise it acts as regular LRB.
> 
> Testing: hotspot_gc_shenandoah

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Rename LRB-native -> LRB-weak

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/961/files
  - new: https://git.openjdk.java.net/jdk/pull/961/files/9911e5b5..86c80228

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

  Stats: 65 lines in 13 files changed: 0 ins; 0 del; 65 mod
  Patch: https://git.openjdk.java.net/jdk/pull/961.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/961/head:pull/961

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

From coleenp at openjdk.java.net  Fri Oct 30 20:31:10 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 30 Oct 2020 20:31:10 GMT
Subject: RFR: 8212879: Make JVMTI TagMap table not hash on oop address
Message-ID: <wRMAEoPWqRvAMnc3F8_t1E79O6UxCDl76pvDC3upSfg=.bba0d609-281c-4b1a-abbf-610726652f32@github.com>

This change turns the HashTable that JVMTI uses for object tagging into a regular Hotspot hashtable - the one in hashtable.hpp with resizing and rehashing.   Instead of pointing directly to oops so that GC has to walk the table to follow oops and then to rehash the table, this table points to WeakHandle.  GC walks the backing OopStorages concurrently.

The hash function for the table is a hash of the lower 32 bits of the address.  A flag is set during GC (gc_notification if in a safepoint, and through a call to JvmtiTagMap::needs_processing()) so that the table is rehashed at the next use.

The gc_notification mechanism of weak oop processing is used to notify Jvmti to post ObjectFree events.  In concurrent GCs there can be a window of time between weak oop marking where the oop is unmarked, so dead (the phantom load in peek returns NULL) but the gc_notification hasn't been done yet.  In this window, a heap walk or GetObjectsWithTags call would not find an object before the ObjectFree event is posted.  This is dealt with in two ways:

1. In the Heap walk, there's an unconditional table walk to post events if events are needed to post.
2. For GetObjectWithTags, if a dead oop is found in the table and posting is required, we use the VM thread to post the event.

Event posting cannot be done in a JavaThread because the posting needs to be done while holding the table lock, so that the JvmtiEnv state doesn't change before posting is done.  ObjectFree callbacks are limited in what they can do as per the JVMTI Specification.  The allowed callbacks to the VM already have code to allow NonJava threads.

To avoid rehashing, I also tried to use object->identity_hash() but this breaks because entries can be added to the table during heapwalk, where the objects use marking.  The starting markWord is saved and restored.  Adding a hashcode during this operation makes restoring the former markWord (locked, inflated, etc) too complicated.  Plus we don't want all these objects to have hashcodes because locking operations after tagging would have to always use inflated locks.

Much of this change is to remove serial weak oop processing for the weakProcessor, ZGC and Shenandoah.  The GCs have been stress tested with jvmti code.

It has also been tested with tier1-6.

Thank you to Stefan, Erik and Kim for their help with this change.

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

Commit messages:
 - 8212879: Make JVMTI TagMap table not hash on oop address

Changes: https://git.openjdk.java.net/jdk/pull/967/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=967&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8212879
  Stats: 1737 lines in 41 files changed: 631 ins; 990 del; 116 mod
  Patch: https://git.openjdk.java.net/jdk/pull/967.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/967/head:pull/967

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

From erikj at openjdk.java.net  Fri Oct 30 20:48:57 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Fri, 30 Oct 2020 20:48:57 GMT
Subject: RFR: 8212879: Make JVMTI TagMap table not hash on oop address
In-Reply-To: <wRMAEoPWqRvAMnc3F8_t1E79O6UxCDl76pvDC3upSfg=.bba0d609-281c-4b1a-abbf-610726652f32@github.com>
References: <wRMAEoPWqRvAMnc3F8_t1E79O6UxCDl76pvDC3upSfg=.bba0d609-281c-4b1a-abbf-610726652f32@github.com>
Message-ID: <OPBOkOwYCpaoMic1YZnMz4mWBhWihywNcJInzM_UW2o=.aaac99d7-c097-4e1f-882c-f373edcfd262@github.com>

On Fri, 30 Oct 2020 20:23:04 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> This change turns the HashTable that JVMTI uses for object tagging into a regular Hotspot hashtable - the one in hashtable.hpp with resizing and rehashing.   Instead of pointing directly to oops so that GC has to walk the table to follow oops and then to rehash the table, this table points to WeakHandle.  GC walks the backing OopStorages concurrently.
> 
> The hash function for the table is a hash of the lower 32 bits of the address.  A flag is set during GC (gc_notification if in a safepoint, and through a call to JvmtiTagMap::needs_processing()) so that the table is rehashed at the next use.
> 
> The gc_notification mechanism of weak oop processing is used to notify Jvmti to post ObjectFree events.  In concurrent GCs there can be a window of time between weak oop marking where the oop is unmarked, so dead (the phantom load in peek returns NULL) but the gc_notification hasn't been done yet.  In this window, a heap walk or GetObjectsWithTags call would not find an object before the ObjectFree event is posted.  This is dealt with in two ways:
> 
> 1. In the Heap walk, there's an unconditional table walk to post events if events are needed to post.
> 2. For GetObjectWithTags, if a dead oop is found in the table and posting is required, we use the VM thread to post the event.
> 
> Event posting cannot be done in a JavaThread because the posting needs to be done while holding the table lock, so that the JvmtiEnv state doesn't change before posting is done.  ObjectFree callbacks are limited in what they can do as per the JVMTI Specification.  The allowed callbacks to the VM already have code to allow NonJava threads.
> 
> To avoid rehashing, I also tried to use object->identity_hash() but this breaks because entries can be added to the table during heapwalk, where the objects use marking.  The starting markWord is saved and restored.  Adding a hashcode during this operation makes restoring the former markWord (locked, inflated, etc) too complicated.  Plus we don't want all these objects to have hashcodes because locking operations after tagging would have to always use inflated locks.
> 
> Much of this change is to remove serial weak oop processing for the weakProcessor, ZGC and Shenandoah.  The GCs have been stress tested with jvmti code.
> 
> It has also been tested with tier1-6.
> 
> Thank you to Stefan, Erik and Kim for their help with this change.

Build changes look ok.

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

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

From nevgeniev at gmail.com  Sat Oct 31 02:16:29 2020
From: nevgeniev at gmail.com (Nick Evgeniev)
Date: Fri, 30 Oct 2020 21:16:29 -0500
Subject: shenandoah c2 compiler crash in jdk8
Message-ID: <CAEyj=Y5W1D-w=kLP26M02MkdOnP1WiPwVyXkqsNSdu6kT8SqaQ@mail.gmail.com>

hi,

pls disregard previous email it's not related to existing jdk bug

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error
(/home/buildbot/worker/build-jdk8u-redhat-linux/build/hotspot/src/share/vm/opto/node.cpp:75),
pid=101496, tid=0x00007fd2b0cb1700
#  assert(Compile::current()->live_nodes() <
Compile::current()->max_node_limit()) failed: Live Node limit exceeded limit
#
# JRE version: OpenJDK Runtime Environment (8.0) (build
1.8.0-builds.shipilev.net-openjdk-jdk8-redhat-b175-20201026-debug-testing-b00)
# Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode linux-amd64
compressed oops)
# Core dump written. Default location:
/home/e21170/Downloads/core/segv/core or core.101496
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00007fd2ac204830):  JavaThread "C2 CompilerThread0"
daemon [_thread_in_native, id=101889,
stack(0x00007fd2b0bb2000,0x00007fd2b0cb2000)]

Stack: [0x00007fd2b0bb2000,0x00007fd2b0cb2000],  sp=0x00007fd2b0cab2a0,
 free space=996k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
code)
V  [libjvm.so+0xe0a497]  VMError::report(outputStream*)+0xf0d
V  [libjvm.so+0xe0b903]  VMError::report_and_die()+0x475
V  [libjvm.so+0x68cef0]  report_vm_error(char const*, int, char const*,
char const*)+0xa5
V  [libjvm.so+0xb92ec3]  Node::verify_construction()+0x155
V  [libjvm.so+0xb93d18]  Node::Node(Node*, Node*)+0x62
V  [libjvm.so+0x3dc8a1]  CastX2PNode::CastX2PNode(Node*)+0x25
V  [libjvm.so+0xd1381f]
 ShenandoahBarrierC2Support::pin_and_expand(PhaseIdealLoop*)+0x2629
V  [libjvm.so+0xab474c]  PhaseIdealLoop::build_and_optimize(bool,
bool)+0xc82
V  [libjvm.so+0x61eb88]  PhaseIdealLoop::PhaseIdealLoop(PhaseIterGVN&,
bool, bool)+0xac
V  [libjvm.so+0xd0b2b9]  ShenandoahBarrierC2Support::expand(Compile*,
PhaseIterGVN&)+0x67
V  [libjvm.so+0x614694]  Compile::Optimize()+0xf22
V  [libjvm.so+0x60dc0e]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*,
int, bool, bool, bool)+0x12ba
V  [libjvm.so+0x53f1ad]  C2Compiler::compile_method(ciEnv*, ciMethod*,
int)+0x119
V  [libjvm.so+0x626c2f]
 CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4d3
V  [libjvm.so+0x626051]  CompileBroker::compiler_thread_loop()+0x32b
V  [libjvm.so+0xdae72c]  compiler_thread_entry(JavaThread*, Thread*)+0x57

From nevgeniev at gmail.com  Sat Oct 31 20:03:47 2020
From: nevgeniev at gmail.com (Nick Evgeniev)
Date: Sat, 31 Oct 2020 15:03:47 -0500
Subject: shenandoah c2 compiler crash in jdk8
In-Reply-To: <CAEyj=Y5W1D-w=kLP26M02MkdOnP1WiPwVyXkqsNSdu6kT8SqaQ@mail.gmail.com>
References: <CAEyj=Y5W1D-w=kLP26M02MkdOnP1WiPwVyXkqsNSdu6kT8SqaQ@mail.gmail.com>
Message-ID: <CAEyj=Y7Gjk8N8iNTz766cgtWcxnOW-MY=J4EyN0iKr4UeA6oQQ@mail.gmail.com>

Hi,

It stops crashing if I add `-XX:MaxNodeLimit=100000` option.. Is it true
that Shenandoah needs substantially more nodes compared to CMS? If so,
default (75000) probably needs to be adjusted... as crash in release
version has less than obvious stacktrace

Pls confirm it's not a bug :)

On Fri, 30 Oct 2020 at 21:16, Nick Evgeniev <nevgeniev at gmail.com> wrote:

> hi,
>
> pls disregard previous email it's not related to existing jdk bug
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error
> (/home/buildbot/worker/build-jdk8u-redhat-linux/build/hotspot/src/share/vm/opto/node.cpp:75),
> pid=101496, tid=0x00007fd2b0cb1700
> #  assert(Compile::current()->live_nodes() <
> Compile::current()->max_node_limit()) failed: Live Node limit exceeded limit
> #
> # JRE version: OpenJDK Runtime Environment (8.0) (build
> 1.8.0-builds.shipilev.net-openjdk-jdk8-redhat-b175-20201026-debug-testing-b00)
> # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode
> linux-amd64 compressed oops)
> # Core dump written. Default location:
> /home/e21170/Downloads/core/segv/core or core.101496
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> #
>
> ---------------  T H R E A D  ---------------
>
> Current thread (0x00007fd2ac204830):  JavaThread "C2 CompilerThread0"
> daemon [_thread_in_native, id=101889,
> stack(0x00007fd2b0bb2000,0x00007fd2b0cb2000)]
>
> Stack: [0x00007fd2b0bb2000,0x00007fd2b0cb2000],  sp=0x00007fd2b0cab2a0,
>  free space=996k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native
> code)
> V  [libjvm.so+0xe0a497]  VMError::report(outputStream*)+0xf0d
> V  [libjvm.so+0xe0b903]  VMError::report_and_die()+0x475
> V  [libjvm.so+0x68cef0]  report_vm_error(char const*, int, char const*,
> char const*)+0xa5
> V  [libjvm.so+0xb92ec3]  Node::verify_construction()+0x155
> V  [libjvm.so+0xb93d18]  Node::Node(Node*, Node*)+0x62
> V  [libjvm.so+0x3dc8a1]  CastX2PNode::CastX2PNode(Node*)+0x25
> V  [libjvm.so+0xd1381f]
>  ShenandoahBarrierC2Support::pin_and_expand(PhaseIdealLoop*)+0x2629
> V  [libjvm.so+0xab474c]  PhaseIdealLoop::build_and_optimize(bool,
> bool)+0xc82
> V  [libjvm.so+0x61eb88]  PhaseIdealLoop::PhaseIdealLoop(PhaseIterGVN&,
> bool, bool)+0xac
> V  [libjvm.so+0xd0b2b9]  ShenandoahBarrierC2Support::expand(Compile*,
> PhaseIterGVN&)+0x67
> V  [libjvm.so+0x614694]  Compile::Optimize()+0xf22
> V  [libjvm.so+0x60dc0e]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*,
> int, bool, bool, bool)+0x12ba
> V  [libjvm.so+0x53f1ad]  C2Compiler::compile_method(ciEnv*, ciMethod*,
> int)+0x119
> V  [libjvm.so+0x626c2f]
>  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4d3
> V  [libjvm.so+0x626051]  CompileBroker::compiler_thread_loop()+0x32b
> V  [libjvm.so+0xdae72c]  compiler_thread_entry(JavaThread*, Thread*)+0x57
>

From rkennke at redhat.com  Sat Oct 31 20:16:05 2020
From: rkennke at redhat.com (Roman Kennke)
Date: Sat, 31 Oct 2020 21:16:05 +0100
Subject: shenandoah c2 compiler crash in jdk8
In-Reply-To: <CAEyj=Y7Gjk8N8iNTz766cgtWcxnOW-MY=J4EyN0iKr4UeA6oQQ@mail.gmail.com>
References: <CAEyj=Y5W1D-w=kLP26M02MkdOnP1WiPwVyXkqsNSdu6kT8SqaQ@mail.gmail.com>
 <CAEyj=Y7Gjk8N8iNTz766cgtWcxnOW-MY=J4EyN0iKr4UeA6oQQ@mail.gmail.com>
Message-ID: <e41a0e68e233def764b9dba9d926148275cdea1e.camel@redhat.com>

Hello Nick,

thanks for reporting the problem!

Yes, it is possible and likely that Shenandoah needs more nodes in C2
than CMS. We will investigate the problem next week.

Thanks and best regards,
Roman

> It stops crashing if I add `-XX:MaxNodeLimit=100000` option.. Is it
> true
> that Shenandoah needs substantially more nodes compared to CMS? If
> so,
> default (75000) probably needs to be adjusted... as crash in release
> version has less than obvious stacktrace
> 
> Pls confirm it's not a bug :)
> 
> On Fri, 30 Oct 2020 at 21:16, Nick Evgeniev <nevgeniev at gmail.com>
> wrote:
> 
> > hi,
> > 
> > pls disregard previous email it's not related to existing jdk bug
> > 
> > #
> > # A fatal error has been detected by the Java Runtime Environment:
> > #
> > #  Internal Error
> > (/home/buildbot/worker/build-jdk8u-redhat-
> > linux/build/hotspot/src/share/vm/opto/node.cpp:75),
> > pid=101496, tid=0x00007fd2b0cb1700
> > #  assert(Compile::current()->live_nodes() <
> > Compile::current()->max_node_limit()) failed: Live Node limit
> > exceeded limit
> > #
> > # JRE version: OpenJDK Runtime Environment (8.0) (build
> > 1.8.0-builds.shipilev.net-openjdk-jdk8-redhat-b175-20201026-debug-
> > testing-b00)
> > # Java VM: OpenJDK 64-Bit Server VM (25.71-b00-debug mixed mode
> > linux-amd64 compressed oops)
> > # Core dump written. Default location:
> > /home/e21170/Downloads/core/segv/core or core.101496
> > #
> > # If you would like to submit a bug report, please visit:
> > #   http://bugreport.java.com/bugreport/crash.jsp
> > #
> > 
> > ---------------  T H R E A D  ---------------
> > 
> > Current thread (0x00007fd2ac204830):  JavaThread "C2
> > CompilerThread0"
> > daemon [_thread_in_native, id=101889,
> > stack(0x00007fd2b0bb2000,0x00007fd2b0cb2000)]
> > 
> > Stack:
> > [0x00007fd2b0bb2000,0x00007fd2b0cb2000],  sp=0x00007fd2b0cab2a0,
> >  free space=996k
> > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
> > C=native
> > code)
> > V  [libjvm.so+0xe0a497]  VMError::report(outputStream*)+0xf0d
> > V  [libjvm.so+0xe0b903]  VMError::report_and_die()+0x475
> > V  [libjvm.so+0x68cef0]  report_vm_error(char const*, int, char
> > const*,
> > char const*)+0xa5
> > V  [libjvm.so+0xb92ec3]  Node::verify_construction()+0x155
> > V  [libjvm.so+0xb93d18]  Node::Node(Node*, Node*)+0x62
> > V  [libjvm.so+0x3dc8a1]  CastX2PNode::CastX2PNode(Node*)+0x25
> > V  [libjvm.so+0xd1381f]
> >  ShenandoahBarrierC2Support::pin_and_expand(PhaseIdealLoop*)+0x2629
> > V  [libjvm.so+0xab474c]  PhaseIdealLoop::build_and_optimize(bool,
> > bool)+0xc82
> > V  [libjvm.so+0x61eb88]  PhaseIdealLoop::PhaseIdealLoop(PhaseIterGV
> > N&,
> > bool, bool)+0xac
> > V  [libjvm.so+0xd0b2b9]  ShenandoahBarrierC2Support::expand(Compile
> > *,
> > PhaseIterGVN&)+0x67
> > V  [libjvm.so+0x614694]  Compile::Optimize()+0xf22
> > V  [libjvm.so+0x60dc0e]  Compile::Compile(ciEnv*, C2Compiler*,
> > ciMethod*,
> > int, bool, bool, bool)+0x12ba
> > V  [libjvm.so+0x53f1ad]  C2Compiler::compile_method(ciEnv*,
> > ciMethod*,
> > int)+0x119
> > V  [libjvm.so+0x626c2f]
> >  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4d3
> > V  [libjvm.so+0x626051]  CompileBroker::compiler_thread_loop()+0x32
> > b
> > V  [libjvm.so+0xdae72c]  compiler_thread_entry(JavaThread*,
> > Thread*)+0x57
> > 


From rkennke at openjdk.java.net  Thu Oct  8 13:37:07 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 08 Oct 2020 13:37:07 -0000
Subject: RFR: 8254103: Shenandoah: Move updating thread roots to
 concurrent phase [v2]
In-Reply-To: <u0qvQKyM8kqMrk6Kpa_73kIJpb63SsZG3sjkk4QS2sM=.c58d436e-d4f2-4d02-bfbf-7d95b044cb29@github.com>
References: <cJ807ZYdMJrdvA1uZfiaysdcm0HB63EBzlyL3PRZhtk=.24ab7e33-488a-40bb-ac2f-b47264e363c2@github.com>
 <u0qvQKyM8kqMrk6Kpa_73kIJpb63SsZG3sjkk4QS2sM=.c58d436e-d4f2-4d02-bfbf-7d95b044cb29@github.com>
Message-ID: <Z8NEZE1-GpsrZ5UOErYTLFqXzj_cEfKpfWmdeDqItPs=.9ae8130f-8021-47d8-b78c-703ec7e66eda@github.com>

On Wed, 7 Oct 2020 16:57:23 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

>> Due to non-atomic LRB, there can be from-space oops in thread roots after evacuation.
>> To enforce to-space invariant, Shenandoah updates thread roots during final reference updating pause, but it can be
>> done outside pause via thread handshake.
>> Test:
>> 
>> - [x] hotspot_gc_shenandoah
>
> Zhengyu Gu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update

Looks good to me! Thanks!

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

Marked as reviewed by rkennke (Reviewer).

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