From dholmes at openjdk.java.net  Mon Aug  2 01:32:47 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 2 Aug 2021 01:32:47 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <4BScf_-Ipx7eEH5LNCXAjhCn7j-JoCikldXnPzX1xZ0=.4827e655-7e70-4174-97af-2f6649e616e9@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev 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.

Hi Igor,

This set of changes seems much more manageable to me.

Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class?

Thanks,
David

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/290

From jiefu at openjdk.java.net  Mon Aug  2 01:48:33 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 2 Aug 2021 01:48:33 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <5SYAFqMrZzYAv1C1HVLm7ehQ22NmC401c5hiRA0KfsY=.bad74f4b-2787-44d8-9639-a809be6133ea@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev 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 12 new commits since the last revision:
> 
>  - fixed ctw build
>  - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
>  - updated requires.VMProps
>  - updated TEST.ROOT
>  - adjusted hotspot source
>  - added test
>  - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
>  - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
>  - removed sun/hotspot/parser/DiagnosticCommand
>  - deprecated sun/hotspot classes
>    disallowed s.h.WhiteBox w/ security manager
>  - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860

Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java?
Thanks.

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From kvn at openjdk.java.net  Mon Aug  2 15:59:36 2021
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 2 Aug 2021 15:59:36 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <Sd7psaMNOzPgXn6MXO4nqbYOar95nebcGeDQ7TUYZCo=.156f24b1-bce1-4ab8-bd21-414aa51d8839@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev 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.

I agree with these revised changes for JDK 17.

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

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk17/pull/290

From iignatyev at openjdk.java.net  Mon Aug  2 16:25:21 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 2 Aug 2021 16:25:21 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
Message-ID: <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>

On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>> 
>> the majority of the patch is the following substitutions:
>>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>> 
>> testing: tier1-4
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev 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 12 new commits since the last revision:
> 
>  - fixed ctw build
>  - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
>  - updated requires.VMProps
>  - updated TEST.ROOT
>  - adjusted hotspot source
>  - added test
>  - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
>  - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
>  - removed sun/hotspot/parser/DiagnosticCommand
>  - deprecated sun/hotspot classes
>    disallowed s.h.WhiteBox w/ security manager
>  - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860

Hi David,

> This set of changes seems much more manageable to me.

thank you for your review, David.

> Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class?

the deprecation warnings (hopefully) will help people not to forget that they should use the new WB class in new tests. 

Thanks,
-- Igor

Hi Jie,
> Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java?

we most certainly shall, just pushed the commit that updates the copyright years in the touched files.

Cheers,
-- Igor

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From iignatyev at openjdk.java.net  Mon Aug  2 16:25:19 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 2 Aug 2021 16:25:19 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v3]
In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
Message-ID: <loW4C0OHE9UVTbpoyDspljVodi4xA8xKi2spS1AALyc=.bff9a367-c923-45ef-a9e5-f5fe8df547af@github.com>

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

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

 - copyright update
 - fixed typo in ClassFileInstaller

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

Changes:
  - all: https://git.openjdk.java.net/jdk17/pull/290/files
  - new: https://git.openjdk.java.net/jdk17/pull/290/files/237e8860..fcaf41f8

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

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk17/pull/290.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk17 pull/290/head:pull/290

PR: https://git.openjdk.java.net/jdk17/pull/290

From iignatyev at openjdk.java.net  Mon Aug  2 16:26:33 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 2 Aug 2021 16:26:33 GMT
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <Sd7psaMNOzPgXn6MXO4nqbYOar95nebcGeDQ7TUYZCo=.156f24b1-bce1-4ab8-bd21-414aa51d8839@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
 <Sd7psaMNOzPgXn6MXO4nqbYOar95nebcGeDQ7TUYZCo=.156f24b1-bce1-4ab8-bd21-414aa51d8839@github.com>
Message-ID: <h5CHlSF_Cj70P2Y6laxQMT2SpslrjXfEv_jl45W8A_U=.2c44b77c-b57c-4bb1-8f75-db555212e33f@github.com>

On Mon, 2 Aug 2021 15:56:39 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> I agree with these revised changes for JDK 17.

Thanks for your review, Vladimir. 

I'll rerun my testing before integrating (just for good luck).

-- Igor

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From iignatyev at openjdk.java.net  Mon Aug  2 20:47:35 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 2 Aug 2021 20:47:35 GMT
Subject: [jdk17] Integrated: 8067223: [TESTBUG] Rename Whitebox API package
In-Reply-To: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
Message-ID: <7NcTTjXdOT2FGyik79Who_BkmchG225aO4-ufpU1eZk=.9b2f1a53-7739-49ce-b2b8-f587d78f55e4@github.com>

On Wed, 28 Jul 2021 17:13:49 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
> 
> the majority of the patch is the following substitutions:
>  - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>  - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>  - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>  - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>  - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>  - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
> 
> testing: tier1-4
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: ada58d13
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk17/commit/ada58d13f78eb8a240220c45c573335eeb47cf07
Stats:     532 lines in 36 files changed: 449 ins; 0 del; 83 mod

8067223: [TESTBUG] Rename Whitebox API package

Reviewed-by: dholmes, kvn

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

PR: https://git.openjdk.java.net/jdk17/pull/290

From david.holmes at oracle.com  Mon Aug  2 22:00:36 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 3 Aug 2021 08:00:36 +1000
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
 <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>
Message-ID: <b3283810-5f7e-7161-3bca-5f064dda8441@oracle.com>

On 3/08/2021 2:25 am, Igor Ignatyev wrote:
> On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:
> 
>>> Hi all,
>>>
>>> could you please review this big tedious and trivial(-ish) patch which moves `sun.hotspot.WhiteBox` and related classes to `jdk.test.whitebox` package?
>>>
>>> the majority of the patch is the following substitutions:
>>>   - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>>   - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>>   - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>>   - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>>   - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>>   - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>>>
>>> testing: tier1-4
>>>
>>> Thanks,
>>> -- Igor
>>
>> Igor Ignatyev 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 12 new commits since the last revision:
>>
>>   - fixed ctw build
>>   - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's inner class
>>   - updated requires.VMProps
>>   - updated TEST.ROOT
>>   - adjusted hotspot source
>>   - added test
>>   - moved and adjusted WhiteBox tests (test/lib-test/sun/hotspot/whitebox)
>>   - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
>>   - removed sun/hotspot/parser/DiagnosticCommand
>>   - deprecated sun/hotspot classes
>>     disallowed s.h.WhiteBox w/ security manager
>>   - ... and 2 more: https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860
> 
> Hi David,
> 
>> This set of changes seems much more manageable to me.
> 
> thank you for your review, David.
> 
>> Not sure about the new deprecation warnings for the old WB classes .. might that not itself trigger some failures? If not then I don't see how the deprecation warnings help with transitioning to the new WB class?
> 
> the deprecation warnings (hopefully) will help people not to forget that they should use the new WB class in new tests.

If the test passes it is unlikely people will actually notice these in 
the jtr file - and even if they see them they may just ignore them 
thinking they are similar to all the security manager warnings that we 
ignore.

But as long as it does no harm.

Cheers,
David

> Thanks,
> -- Igor
> 
> Hi Jie,
>> Shall we also update the copyright year like test/lib/sun/hotspot/cpuinfo/CPUInfo.java?
> 
> we most certainly shall, just pushed the commit that updates the copyright years in the touched files.
> 
> Cheers,
> -- Igor
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk17/pull/290
> 

From shade at openjdk.java.net  Tue Aug  3 12:13:32 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 3 Aug 2021 12:13:32 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v3]
In-Reply-To: <6m_sTEtwhTj1zH7SK6fdyzjavt9cykNU48ktFB96CmM=.a32e4a69-80b7-42f6-90ca-984a88209211@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <OeK5Ff0cZaQ7qV2HFv8IsffVTbME9-ozEXSSu-gWsO8=.72593252-988a-478d-9360-51282530b8a6@github.com>
 <6m_sTEtwhTj1zH7SK6fdyzjavt9cykNU48ktFB96CmM=.a32e4a69-80b7-42f6-90ca-984a88209211@github.com>
Message-ID: <RmbV6o6_ND26X7ORiA1MS9J9APAkiQSnOS9I1m7E-t8=.6c5c98a4-bfef-451d-820d-a0e1bdc5da7a@github.com>

On Fri, 19 Mar 2021 11:32:52 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase.
>
> Looks good to me.

I actually wanted to see if @rkennke has troubles with keeping current mark word accesses at "relaxed".

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

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

From wkemper at openjdk.java.net  Tue Aug  3 16:48:33 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 3 Aug 2021 16:48:33 GMT
Subject: RFR: Generational support for weak roots and references [v2]
In-Reply-To: <nrdggiU8yIr-GDCzeTupmMsGP68fA-_h6ABd7ViQews=.8eb38892-ebec-4432-84b0-68e2e5cccb1d@github.com>
References: <nrdggiU8yIr-GDCzeTupmMsGP68fA-_h6ABd7ViQews=.8eb38892-ebec-4432-84b0-68e2e5cccb1d@github.com>
Message-ID: <J41Relyv2oL1hp_839bTKiIzS-WJq0XZojvOvElnTCg=.79ce5a5f-7a45-4a1a-ba64-45b09ad5b99d@github.com>

> ### Summary
> The LRB for non-strong references is modified to permit resurrection of objects outside the generation being collected. In other words, resurrection is only blocked for unmarked objects in the generation being collected.
> 
> Each `ShenandoahGeneration` has its own reference processor instance. In some cases, a reference from the old generation may end up on the young generation discovered list if the reference points to a young referent (this would happen if the old reference is in the remembered set). However, young references that point to referents in the old generation are _not_ discovered. This has the effect of strongly marking the old generation referent. This also avoids the case of having young references on the old generation discovered list being evacuated/relocated while they wait for old generation reference processing (although we believe this case would be handled correctly by the existing update references code).

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

 - Prepare for concurrent root processing in old generation final mark
 - Clear cards and object registrations when region is recycled
   
   This fixes an error when humongous regions are allocated and when ensures registrations are correct when regions are promoted.
 - Check that pointer is in heap before looking up affiliation
 - Guard assert from cross-generation handle

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/53/files
  - new: https://git.openjdk.java.net/shenandoah/pull/53/files/80821d08..314c6550

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

  Stats: 24 lines in 6 files changed: 14 ins; 5 del; 5 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/53.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/53/head:pull/53

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

From david.holmes at oracle.com  Wed Aug  4 04:34:34 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 4 Aug 2021 14:34:34 +1000
Subject: [jdk17] RFR: 8067223: [TESTBUG] Rename Whitebox API package [v2]
In-Reply-To: <b3283810-5f7e-7161-3bca-5f064dda8441@oracle.com>
References: <39PNb3wa-43yB5IFR3XroqFf4vMNZPitzF85lO1Gw58=.f2587741-d2c4-467d-b722-b17269587e7a@github.com>
 <aLR3YLrRbGBPBTqkWXIkfzse3vaVRtoVRBXVdDGHVZg=.f5f7811e-32b7-45ee-8fba-db1de599649c@github.com>
 <gLiHwnjyHZocgtJJSFk1q98oV4Ffqz7e5VWhgI1Ld0o=.8555b8c4-05ca-42bf-96d6-a0e70bd04056@github.com>
 <b3283810-5f7e-7161-3bca-5f064dda8441@oracle.com>
Message-ID: <d28fe872-89a1-e7be-f8f9-a9b3b2330fa2@oracle.com>

Skara email test - please ignore.

David

On 3/08/2021 8:00 am, David Holmes wrote:
> On 3/08/2021 2:25 am, Igor Ignatyev wrote:
>> On Sat, 31 Jul 2021 20:42:10 GMT, Igor Ignatyev 
>> <iignatyev at openjdk.org> wrote:
>>
>>>> Hi all,
>>>>
>>>> could you please review this big tedious and trivial(-ish) patch 
>>>> which moves `sun.hotspot.WhiteBox` and related classes to 
>>>> `jdk.test.whitebox` package?
>>>>
>>>> the majority of the patch is the following substitutions:
>>>> ? - `s~sun/hotspot/WhiteBox~jdk/test/whitebox/WhiteBox~g`
>>>> ? - `s/sun.hotspot.parser/jdk.test.whitebox.parser/g`
>>>> ? - `s/sun.hotspot.cpuinfo/jdk.test.whitebox.cpuinfo/g`
>>>> ? - `s/sun.hotspot.code/jdk.test.whitebox.code/g`
>>>> ? - `s/sun.hotspot.gc/jdk.test.whitebox.gc/g`
>>>> ? - `s/sun.hotspot.WhiteBox/jdk.test.whitebox.WhiteBox/g`
>>>>
>>>> testing: tier1-4
>>>>
>>>> Thanks,
>>>> -- Igor
>>>
>>> Igor Ignatyev 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 12 new commits since the last revision:
>>>
>>> ? - fixed ctw build
>>> ? - updated runtime/cds/appcds/JarBuilder to copy j.t.w.WhiteBox's 
>>> inner class
>>> ? - updated requires.VMProps
>>> ? - updated TEST.ROOT
>>> ? - adjusted hotspot source
>>> ? - added test
>>> ? - moved and adjusted WhiteBox tests 
>>> (test/lib-test/sun/hotspot/whitebox)
>>> ? - updated ClassFileInstaller to copy j.t.w.WhiteBox's inner class
>>> ? - removed sun/hotspot/parser/DiagnosticCommand
>>> ? - deprecated sun/hotspot classes
>>> ??? disallowed s.h.WhiteBox w/ security manager
>>> ? - ... and 2 more: 
>>> https://git.openjdk.java.net/jdk17/compare/8f12f2cf...237e8860
>>
>> Hi David,
>>
>>> This set of changes seems much more manageable to me.
>>
>> thank you for your review, David.
>>
>>> Not sure about the new deprecation warnings for the old WB classes .. 
>>> might that not itself trigger some failures? If not then I don't see 
>>> how the deprecation warnings help with transitioning to the new WB 
>>> class?
>>
>> the deprecation warnings (hopefully) will help people not to forget 
>> that they should use the new WB class in new tests.
> 
> If the test passes it is unlikely people will actually notice these in 
> the jtr file - and even if they see them they may just ignore them 
> thinking they are similar to all the security manager warnings that we 
> ignore.
> 
> But as long as it does no harm.
> 
> Cheers,
> David
> 
>> Thanks,
>> -- Igor
>>
>> Hi Jie,
>>> Shall we also update the copyright year like 
>>> test/lib/sun/hotspot/cpuinfo/CPUInfo.java?
>>
>> we most certainly shall, just pushed the commit that updates the 
>> copyright years in the touched files.
>>
>> Cheers,
>> -- Igor
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk17/pull/290
>>

From rkennke at openjdk.java.net  Fri Aug  6 13:53:59 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 6 Aug 2021 13:53:59 GMT
Subject: RFR: Check that pointer is in heap before checking the
 affiliation of owning region [v2]
In-Reply-To: <ij5qXaIDd62pjfe68Wwvzt1ABt7UIb2Ci7rvT0Uqu-s=.fb73cd78-0bdd-4067-99f7-09c10a66327a@github.com>
References: <RRcFCCmt2P0KiOmkG58vXv1N3lFtQnXVZ7lOuPxsz1c=.cfb96973-bced-4484-b0d5-41dd234dd3e4@github.com>
 <ij5qXaIDd62pjfe68Wwvzt1ABt7UIb2Ci7rvT0Uqu-s=.fb73cd78-0bdd-4067-99f7-09c10a66327a@github.com>
Message-ID: <GXry5f2u27bBXvZrs1mZ7hN5WEfPbHYrY-ctZ98dSM0=.d780a9c1-6aec-423a-8fa2-ef040b6f5702@github.com>

On Thu, 22 Jul 2021 17:46:51 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> This is a small bug fix that was meant to go in with the concurrent remembered set scanning changes
>
> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unrelated change to comment

Ok.

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

Marked as reviewed by rkennke (Lead).

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

From rkennke at redhat.com  Fri Aug  6 13:59:09 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Fri, 6 Aug 2021 15:59:09 +0200
Subject: Result: New Shenandoah Committer: Kelvin Nilsen
Message-ID: <ca01fdc2-324a-c1e3-288e-2efae35e6627@redhat.com>

Voting for Kelvin Nilsen [1] is now closed.

Yes: 4
Veto: 0
Abstain: 0

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

Roman Kennke

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


From rkennke at openjdk.java.net  Fri Aug  6 14:51:09 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 6 Aug 2021 14:51:09 GMT
Subject: RFR: Generational support for weak roots and references [v2]
In-Reply-To: <J41Relyv2oL1hp_839bTKiIzS-WJq0XZojvOvElnTCg=.79ce5a5f-7a45-4a1a-ba64-45b09ad5b99d@github.com>
References: <nrdggiU8yIr-GDCzeTupmMsGP68fA-_h6ABd7ViQews=.8eb38892-ebec-4432-84b0-68e2e5cccb1d@github.com>
 <J41Relyv2oL1hp_839bTKiIzS-WJq0XZojvOvElnTCg=.79ce5a5f-7a45-4a1a-ba64-45b09ad5b99d@github.com>
Message-ID: <Oee2CBEcCDZaqfTBNCvmWOIbvFVzssOhjW5ODIvo1ZM=.791df0c0-2889-45a3-9e44-c8b93ae3f64e@github.com>

On Tue, 3 Aug 2021 16:48:33 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> ### Summary
>> The LRB for non-strong references is modified to permit resurrection of objects outside the generation being collected. In other words, resurrection is only blocked for unmarked objects in the generation being collected.
>> 
>> Each `ShenandoahGeneration` has its own reference processor instance. In some cases, a reference from the old generation may end up on the young generation discovered list if the reference points to a young referent (this would happen if the old reference is in the remembered set). However, young references that point to referents in the old generation are _not_ discovered. This has the effect of strongly marking the old generation referent. This also avoids the case of having young references on the old generation discovered list being evacuated/relocated while they wait for old generation reference processing (although we believe this case would be handled correctly by the existing update references code).
>
> William Kemper has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Prepare for concurrent root processing in old generation final mark
>  - Clear cards and object registrations when region is recycled
>    
>    This fixes an error when humongous regions are allocated and when ensures registrations are correct when regions are promoted.
>  - Check that pointer is in heap before looking up affiliation
>  - Guard assert from cross-generation handle

Looks good. I only have a few remarks/questions.

src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.hpp line 29:

> 27: 
> 28: #include "gc/shenandoah/mode/shenandoahMode.hpp"
> 29: #include "oops/oop.hpp"

I believe the proper way to get 'oop' into scope is to include oopsHierarchy.hpp

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

> 137: 
> 138:   // Concurrent stack processing
> 139:   if (heap->is_evacuation_in_progress()) {

Where has this gone?

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

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

From wkemper at openjdk.java.net  Fri Aug  6 16:24:09 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 6 Aug 2021 16:24:09 GMT
Subject: Integrated: Check that pointer is in heap before checking the
 affiliation of owning region
In-Reply-To: <RRcFCCmt2P0KiOmkG58vXv1N3lFtQnXVZ7lOuPxsz1c=.cfb96973-bced-4484-b0d5-41dd234dd3e4@github.com>
References: <RRcFCCmt2P0KiOmkG58vXv1N3lFtQnXVZ7lOuPxsz1c=.cfb96973-bced-4484-b0d5-41dd234dd3e4@github.com>
Message-ID: <3MxpNiqIJjOQ7KU7ixC0rWBMRxbmDZc-z221bGqa2yA=.1ba3c7d4-e928-473a-9d1d-cc327010fd3d@github.com>

On Thu, 22 Jul 2021 15:48:08 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This is a small bug fix that was meant to go in with the concurrent remembered set scanning changes

This pull request has now been integrated.

Changeset: 5ebe8d10
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/5ebe8d10b61e783807648e827a87f0d3a5126cfe
Stats:     3 lines in 2 files changed: 0 ins; 0 del; 3 mod

Check that pointer is in heap before checking the affiliation of owning region

Reviewed-by: rkennke

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

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

From wkemper at openjdk.java.net  Fri Aug  6 16:25:00 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 6 Aug 2021 16:25:00 GMT
Subject: RFR: Generational support for weak roots and references [v2]
In-Reply-To: <Oee2CBEcCDZaqfTBNCvmWOIbvFVzssOhjW5ODIvo1ZM=.791df0c0-2889-45a3-9e44-c8b93ae3f64e@github.com>
References: <nrdggiU8yIr-GDCzeTupmMsGP68fA-_h6ABd7ViQews=.8eb38892-ebec-4432-84b0-68e2e5cccb1d@github.com>
 <J41Relyv2oL1hp_839bTKiIzS-WJq0XZojvOvElnTCg=.79ce5a5f-7a45-4a1a-ba64-45b09ad5b99d@github.com>
 <Oee2CBEcCDZaqfTBNCvmWOIbvFVzssOhjW5ODIvo1ZM=.791df0c0-2889-45a3-9e44-c8b93ae3f64e@github.com>
Message-ID: <uLl1JnXA8XeNodHmkxls6ajSBNuSfzUUnEtpLGhsg3Q=.aca30dfa-a086-47fa-aa30-a039abfd668b@github.com>

On Fri, 6 Aug 2021 14:37:04 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Prepare for concurrent root processing in old generation final mark
>>  - Clear cards and object registrations when region is recycled
>>    
>>    This fixes an error when humongous regions are allocated and when ensures registrations are correct when regions are promoted.
>>  - Check that pointer is in heap before looking up affiliation
>>  - Guard assert from cross-generation handle
>
> src/hotspot/share/gc/shenandoah/mode/shenandoahGenerationalMode.hpp line 29:
> 
>> 27: 
>> 28: #include "gc/shenandoah/mode/shenandoahMode.hpp"
>> 29: #include "oops/oop.hpp"
> 
> I believe the proper way to get 'oop' into scope is to include oopsHierarchy.hpp

Sure, will make this change.

> src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp line 139:
> 
>> 137: 
>> 138:   // Concurrent stack processing
>> 139:   if (heap->is_evacuation_in_progress()) {
> 
> Where has this gone?

This was unreachable code (see assert just above on line 136). The old generation defers all evacuation to _mixed_ collections.

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

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

From wkemper at openjdk.java.net  Fri Aug  6 17:09:21 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 6 Aug 2021 17:09:21 GMT
Subject: RFR: Generational support for weak roots and references [v3]
In-Reply-To: <nrdggiU8yIr-GDCzeTupmMsGP68fA-_h6ABd7ViQews=.8eb38892-ebec-4432-84b0-68e2e5cccb1d@github.com>
References: <nrdggiU8yIr-GDCzeTupmMsGP68fA-_h6ABd7ViQews=.8eb38892-ebec-4432-84b0-68e2e5cccb1d@github.com>
Message-ID: <Q0LtlgV3It5rJKV1snC0GUi10yJubFJqZcSIlcYwB24=.632327f6-9d81-417e-b31a-f062538771d6@github.com>

> ### Summary
> The LRB for non-strong references is modified to permit resurrection of objects outside the generation being collected. In other words, resurrection is only blocked for unmarked objects in the generation being collected.
> 
> Each `ShenandoahGeneration` has its own reference processor instance. In some cases, a reference from the old generation may end up on the young generation discovered list if the reference points to a young referent (this would happen if the old reference is in the remembered set). However, young references that point to referents in the old generation are _not_ discovered. This has the effect of strongly marking the old generation referent. This also avoids the case of having young references on the old generation discovered list being evacuated/relocated while they wait for old generation reference processing (although we believe this case would be handled correctly by the existing update references code).

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

 - Merge branch 'master' into generational-weak-refs
 - Include oopHierarchy.hpp, rather than oop.hpp
 - Prepare for concurrent root processing in old generation final mark
 - Clear cards and object registrations when region is recycled
   
   This fixes an error when humongous regions are allocated and when ensures registrations are correct when regions are promoted.
 - Check that pointer is in heap before looking up affiliation
 - Guard assert from cross-generation handle
 - Configure soft reference policy for old generation
 - Merge branch 'shenandoah' into generational-weak-refs
 - Perform coalesce and fill after class unloading
 - Formatting fixes, remove TODO
 - ... and 12 more: https://git.openjdk.java.net/shenandoah/compare/5ebe8d10...9892fcce

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

Changes: https://git.openjdk.java.net/shenandoah/pull/53/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=53&range=02
  Stats: 164 lines in 23 files changed: 90 ins; 26 del; 48 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/53.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/53/head:pull/53

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

From rkennke at openjdk.java.net  Mon Aug  9 15:23:26 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 9 Aug 2021 15:23:26 GMT
Subject: RFR: Generational support for weak roots and references [v3]
In-Reply-To: <Q0LtlgV3It5rJKV1snC0GUi10yJubFJqZcSIlcYwB24=.632327f6-9d81-417e-b31a-f062538771d6@github.com>
References: <nrdggiU8yIr-GDCzeTupmMsGP68fA-_h6ABd7ViQews=.8eb38892-ebec-4432-84b0-68e2e5cccb1d@github.com>
 <Q0LtlgV3It5rJKV1snC0GUi10yJubFJqZcSIlcYwB24=.632327f6-9d81-417e-b31a-f062538771d6@github.com>
Message-ID: <XYmEIrPL0Z-s0VoyRHe2afkfL0bL3QIxyZlp9Hrxo6w=.6fd4f463-55cc-48d1-9a6e-289765ce939b@github.com>

On Fri, 6 Aug 2021 17:09:21 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> ### Summary
>> The LRB for non-strong references is modified to permit resurrection of objects outside the generation being collected. In other words, resurrection is only blocked for unmarked objects in the generation being collected.
>> 
>> Each `ShenandoahGeneration` has its own reference processor instance. In some cases, a reference from the old generation may end up on the young generation discovered list if the reference points to a young referent (this would happen if the old reference is in the remembered set). However, young references that point to referents in the old generation are _not_ discovered. This has the effect of strongly marking the old generation referent. This also avoids the case of having young references on the old generation discovered list being evacuated/relocated while they wait for old generation reference processing (although we believe this case would be handled correctly by the existing update references code).
>
> William Kemper has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into generational-weak-refs
>  - Include oopHierarchy.hpp, rather than oop.hpp
>  - Prepare for concurrent root processing in old generation final mark
>  - Clear cards and object registrations when region is recycled
>    
>    This fixes an error when humongous regions are allocated and when ensures registrations are correct when regions are promoted.
>  - Check that pointer is in heap before looking up affiliation
>  - Guard assert from cross-generation handle
>  - Configure soft reference policy for old generation
>  - Merge branch 'shenandoah' into generational-weak-refs
>  - Perform coalesce and fill after class unloading
>  - Formatting fixes, remove TODO
>  - ... and 12 more: https://git.openjdk.java.net/shenandoah/compare/5ebe8d10...9892fcce

Marked as reviewed by rkennke (Lead).

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

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

From wkemper at openjdk.java.net  Mon Aug  9 16:11:17 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 9 Aug 2021 16:11:17 GMT
Subject: Integrated: Generational support for weak roots and references
In-Reply-To: <nrdggiU8yIr-GDCzeTupmMsGP68fA-_h6ABd7ViQews=.8eb38892-ebec-4432-84b0-68e2e5cccb1d@github.com>
References: <nrdggiU8yIr-GDCzeTupmMsGP68fA-_h6ABd7ViQews=.8eb38892-ebec-4432-84b0-68e2e5cccb1d@github.com>
Message-ID: <OPfxLjmF199CgjPcJmhLVRw_fVWbyBznTXTzX0TfBMQ=.4523506f-2432-4cb6-af86-5ddba8262c1f@github.com>

On Thu, 22 Jul 2021 22:53:56 GMT, William Kemper <wkemper at openjdk.org> wrote:

> ### Summary
> The LRB for non-strong references is modified to permit resurrection of objects outside the generation being collected. In other words, resurrection is only blocked for unmarked objects in the generation being collected.
> 
> Each `ShenandoahGeneration` has its own reference processor instance. In some cases, a reference from the old generation may end up on the young generation discovered list if the reference points to a young referent (this would happen if the old reference is in the remembered set). However, young references that point to referents in the old generation are _not_ discovered. This has the effect of strongly marking the old generation referent. This also avoids the case of having young references on the old generation discovered list being evacuated/relocated while they wait for old generation reference processing (although we believe this case would be handled correctly by the existing update references code).

This pull request has now been integrated.

Changeset: be67d449
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/be67d449b903e28b47771e12c6f01c2e15693140
Stats:     164 lines in 23 files changed: 90 ins; 26 del; 48 mod

Generational support for weak roots and references

Reviewed-by: rkennke

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

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

From wkemper at openjdk.java.net  Mon Aug  9 23:52:12 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 9 Aug 2021 23:52:12 GMT
Subject: RFR: Enable skip update references
Message-ID: <0p_W5lffueIXm8TiM_Jfj7qaNLGg_4lozy0RUSQo0XE=.70395ca6-af2f-4275-8d6f-4317b039bba2@github.com>

This feature of Shenandoah was disabled for generational mode for the reasons described in [PR 50](https://github.com/openjdk/shenandoah/pull/50). Old objects which are no longer reachable and _not_ included in the collection set are filled in at the end of final marking for the old generation so we no longer require the update references phase to perform this task.

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

Commit messages:
 - Merge branch 'shenandoah' into test-skip-update-references
 - Re-enable immediate collection of 100% garbage regions

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

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

From wkemper at openjdk.java.net  Mon Aug  9 23:54:17 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 9 Aug 2021 23:54:17 GMT
Subject: RFR: Re-enable class unloading
Message-ID: <W2A4IYtH_4Am83KwLtlPzNJYRi-aHoY7Q_27l1sWew0=.d2f16b4a-8bab-4ad8-bbd8-be7f9debec00@github.com>

Class unloading was disabled for generational mode for the reasons described in [PR 50](https://github.com/openjdk/shenandoah/pull/50). However, the code has since evolved to avoid using `oop::size` when filling in dead objects so we no longer require classes for unreachable objects to remain loaded.

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

Commit messages:
 - Re-enable class unloading

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

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

From rkennke at openjdk.java.net  Tue Aug 10 11:56:51 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 10 Aug 2021 11:56:51 GMT
Subject: RFR: Enable skip update references
In-Reply-To: <0p_W5lffueIXm8TiM_Jfj7qaNLGg_4lozy0RUSQo0XE=.70395ca6-af2f-4275-8d6f-4317b039bba2@github.com>
References: <0p_W5lffueIXm8TiM_Jfj7qaNLGg_4lozy0RUSQo0XE=.70395ca6-af2f-4275-8d6f-4317b039bba2@github.com>
Message-ID: <6lFpT1ZAi5mUF55v56CTqY0R7f48bD8kRdGwpCi7SmE=.ef165b3e-3b74-4225-bcff-e6af19f380c3@github.com>

On Mon, 9 Aug 2021 23:46:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This feature of Shenandoah was disabled for generational mode for the reasons described in [PR 50](https://github.com/openjdk/shenandoah/pull/50). Old objects which are no longer reachable and _not_ included in the collection set are filled in at the end of final marking for the old generation so we no longer require the update references phase to perform this task.

Marked as reviewed by rkennke (Lead).

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

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

From rkennke at openjdk.java.net  Tue Aug 10 11:58:06 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 10 Aug 2021 11:58:06 GMT
Subject: RFR: Re-enable class unloading
In-Reply-To: <W2A4IYtH_4Am83KwLtlPzNJYRi-aHoY7Q_27l1sWew0=.d2f16b4a-8bab-4ad8-bbd8-be7f9debec00@github.com>
References: <W2A4IYtH_4Am83KwLtlPzNJYRi-aHoY7Q_27l1sWew0=.d2f16b4a-8bab-4ad8-bbd8-be7f9debec00@github.com>
Message-ID: <JKnlAZWOZk5oZTbLoe2zslw0SeXLUUvcTgTT0TBRa_8=.d380bb4c-fa5d-4a7f-a6fa-7c27da739d1a@github.com>

On Mon, 9 Aug 2021 23:48:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Class unloading was disabled for generational mode for the reasons described in [PR 50](https://github.com/openjdk/shenandoah/pull/50). However, the code has since evolved to avoid using `oop::size` when filling in dead objects so we no longer require classes for unreachable objects to remain loaded.

Marked as reviewed by rkennke (Lead).

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

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

From wkemper at openjdk.java.net  Tue Aug 10 17:43:18 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 10 Aug 2021 17:43:18 GMT
Subject: Integrated: Enable skip update references
In-Reply-To: <0p_W5lffueIXm8TiM_Jfj7qaNLGg_4lozy0RUSQo0XE=.70395ca6-af2f-4275-8d6f-4317b039bba2@github.com>
References: <0p_W5lffueIXm8TiM_Jfj7qaNLGg_4lozy0RUSQo0XE=.70395ca6-af2f-4275-8d6f-4317b039bba2@github.com>
Message-ID: <QpmuCiA4-4ZOJF_StPLx3bF_X4F3XkUxt_ycGfJr7bo=.dce560ff-6c5d-4866-a541-0ada580fc23a@github.com>

On Mon, 9 Aug 2021 23:46:29 GMT, William Kemper <wkemper at openjdk.org> wrote:

> This feature of Shenandoah was disabled for generational mode for the reasons described in [PR 50](https://github.com/openjdk/shenandoah/pull/50). Old objects which are no longer reachable and _not_ included in the collection set are filled in at the end of final marking for the old generation so we no longer require the update references phase to perform this task.

This pull request has now been integrated.

Changeset: 6ee74582
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/6ee7458222bf92540867d66ef6d41f58ac0f1137
Stats:     3 lines in 2 files changed: 0 ins; 1 del; 2 mod

Enable skip update references

Reviewed-by: rkennke

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

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

From wkemper at openjdk.java.net  Tue Aug 10 17:43:21 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Tue, 10 Aug 2021 17:43:21 GMT
Subject: Integrated: Re-enable class unloading
In-Reply-To: <W2A4IYtH_4Am83KwLtlPzNJYRi-aHoY7Q_27l1sWew0=.d2f16b4a-8bab-4ad8-bbd8-be7f9debec00@github.com>
References: <W2A4IYtH_4Am83KwLtlPzNJYRi-aHoY7Q_27l1sWew0=.d2f16b4a-8bab-4ad8-bbd8-be7f9debec00@github.com>
Message-ID: <7_SR05teAj7FuWPZ1oAj7BV7JRxwcaJ09TBZcok4RM4=.fdb61bf6-582a-4ec7-8dfe-8bc99ea596a7@github.com>

On Mon, 9 Aug 2021 23:48:04 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Class unloading was disabled for generational mode for the reasons described in [PR 50](https://github.com/openjdk/shenandoah/pull/50). However, the code has since evolved to avoid using `oop::size` when filling in dead objects so we no longer require classes for unreachable objects to remain loaded.

This pull request has now been integrated.

Changeset: b96a883f
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/b96a883fb138c410900beb773dd7b0593dcd53e2
Stats:     9 lines in 1 file changed: 0 ins; 9 del; 0 mod

Re-enable class unloading

Reviewed-by: rkennke

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

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

From zgu at openjdk.java.net  Thu Aug 12 00:20:37 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Thu, 12 Aug 2021 00:20:37 GMT
Subject: RFR: 8272327: Shenandoah: Avoid enqueuing duplicate string candidates
Message-ID: <HWtvzhd_JU49IAxhM56kxX5tz3nfHWTOQx-gZZtlTgY=.0c14f8df-f783-43c5-9dcc-6d7d8ce5a31f@github.com>

Now, there is a new API java_lang_String::test_and_set_deduplication_requested() that can help to identify if a string candidate has been enqueued, so that we can avoid enqueuing duplicate entries.

Test:
- [x] hotspot_gc_shenandoah

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

Commit messages:
 - 8272327: Shenandoah: Avoid enqueuing duplicate string candidates

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

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

From rkennke at openjdk.java.net  Mon Aug 16 09:17:28 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 16 Aug 2021 09:17:28 GMT
Subject: RFR: 8272327: Shenandoah: Avoid enqueuing duplicate string
 candidates
In-Reply-To: <HWtvzhd_JU49IAxhM56kxX5tz3nfHWTOQx-gZZtlTgY=.0c14f8df-f783-43c5-9dcc-6d7d8ce5a31f@github.com>
References: <HWtvzhd_JU49IAxhM56kxX5tz3nfHWTOQx-gZZtlTgY=.0c14f8df-f783-43c5-9dcc-6d7d8ce5a31f@github.com>
Message-ID: <kRlLhyXYJLnj8t76pH__Yvrx7bmkjC9w2v_7Ma1Lh5I=.fd9ac8c6-04d2-4bcb-b1eb-5e135838fc56@github.com>

On Thu, 12 Aug 2021 00:12:14 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Now, there is a new API java_lang_String::test_and_set_deduplication_requested() that can help to identify if a string candidate has been enqueued, so that we can avoid enqueuing duplicate entries.
> 
> Test:
> - [x] hotspot_gc_shenandoah

Looks good to me, thanks!

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

Marked as reviewed by rkennke (Reviewer).

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

From ayang at openjdk.java.net  Mon Aug 16 13:15:43 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 16 Aug 2021 13:15:43 GMT
Subject: RFR: 8272520: Inline GenericTaskQueue::initialize() to the constructor
Message-ID: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>

Simple refactoring of GenericTaskQueue initialization API.

Test: tier1_gc

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

Commit messages:
 - ctor-init

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

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

From kbarrett at openjdk.java.net  Mon Aug 16 14:33:23 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 16 Aug 2021 14:33:23 GMT
Subject: RFR: 8272520: Inline GenericTaskQueue::initialize() to the
 constructor
In-Reply-To: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
References: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
Message-ID: <PTYFBUmPHkqvhUvQ5GVoYGXqs-Uf0Q7CL3suykllpT8=.75ac88ee-1903-4bbf-8197-d7c42f4768d8@github.com>

On Mon, 16 Aug 2021 13:09:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring of GenericTaskQueue initialization API.
> 
> Test: tier1_gc

Looks good.  Just a couple minor nits.

src/hotspot/share/gc/shared/taskqueue.inline.hpp line 53:

> 51: template<class E, MEMFLAGS F, unsigned int N>
> 52: inline GenericTaskQueue<E, F, N>::GenericTaskQueue() : _last_stolen_queue_id(InvalidQueueId), _seed(17 /* random number */) {
> 53:   assert(sizeof(Age) == sizeof(size_t), "Depends on this.");

[pre-existing] This assert is over-constraining.  The real requirement is static-asserted in the Age class.

src/hotspot/share/gc/shared/taskqueue.inline.hpp line 54:

> 52: inline GenericTaskQueue<E, F, N>::GenericTaskQueue() : _last_stolen_queue_id(InvalidQueueId), _seed(17 /* random number */) {
> 53:   assert(sizeof(Age) == sizeof(size_t), "Depends on this.");
> 54:   _elems = ArrayAllocator<E>::allocate(N, F);

`_elems` could be initialized in the mem-initializer-list.

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

Marked as reviewed by kbarrett (Reviewer).

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

From ayang at openjdk.java.net  Mon Aug 16 14:46:52 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 16 Aug 2021 14:46:52 GMT
Subject: RFR: 8272520: Inline GenericTaskQueue::initialize() to the
 constructor [v2]
In-Reply-To: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
References: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
Message-ID: <wIXYpEbbWghHPpkbFtk_5qqV8SoARhdEVorHfnY9LaM=.adf42c23-17e4-482a-b43b-f1b441b1046c@github.com>

> Simple refactoring of GenericTaskQueue initialization API.
> 
> Test: tier1_gc

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

  review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5125/files
  - new: https://git.openjdk.java.net/jdk/pull/5125/files/70f8c7c1..5376e921

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

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

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

From ayang at openjdk.java.net  Mon Aug 16 14:46:53 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 16 Aug 2021 14:46:53 GMT
Subject: RFR: 8272520: Inline GenericTaskQueue::initialize() to the
 constructor [v2]
In-Reply-To: <PTYFBUmPHkqvhUvQ5GVoYGXqs-Uf0Q7CL3suykllpT8=.75ac88ee-1903-4bbf-8197-d7c42f4768d8@github.com>
References: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
 <PTYFBUmPHkqvhUvQ5GVoYGXqs-Uf0Q7CL3suykllpT8=.75ac88ee-1903-4bbf-8197-d7c42f4768d8@github.com>
Message-ID: <tTg9KS3WhrVWl2T3TzbW2Ec2PZYU_aP0fQhbGTzLbRc=.5b869b5e-62fa-41e0-a9ed-418ec053aca1@github.com>

On Mon, 16 Aug 2021 14:28:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review
>
> src/hotspot/share/gc/shared/taskqueue.inline.hpp line 53:
> 
>> 51: template<class E, MEMFLAGS F, unsigned int N>
>> 52: inline GenericTaskQueue<E, F, N>::GenericTaskQueue() : _last_stolen_queue_id(InvalidQueueId), _seed(17 /* random number */) {
>> 53:   assert(sizeof(Age) == sizeof(size_t), "Depends on this.");
> 
> [pre-existing] This assert is over-constraining.  The real requirement is static-asserted in the Age class.

Removed.

> src/hotspot/share/gc/shared/taskqueue.inline.hpp line 54:
> 
>> 52: inline GenericTaskQueue<E, F, N>::GenericTaskQueue() : _last_stolen_queue_id(InvalidQueueId), _seed(17 /* random number */) {
>> 53:   assert(sizeof(Age) == sizeof(size_t), "Depends on this.");
>> 54:   _elems = ArrayAllocator<E>::allocate(N, F);
> 
> `_elems` could be initialized in the mem-initializer-list.

Fixed.

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

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

From wkemper at openjdk.java.net  Mon Aug 16 15:21:09 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 16 Aug 2021 15:21:09 GMT
Subject: RFR: Make immediate trash of old regions with no live objects
Message-ID: <A83h7tHbb3N-X6XVhLhbEmJ1sT39UHuTsONC0b71wWA=.fc86eed8-2216-4daa-89f0-8f95d2f28d5d@github.com>

At the end of old marking we can immediately recycle regions with no live objects. This optimization is already done for young/global collects, but it was missing from old collections. This fixes an assertion during preparation for evacuation that _all_ cset regions have _some_ live data.

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

Commit messages:
 - Make immediate trash of old regions with no live objects

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

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

From rkennke at openjdk.java.net  Mon Aug 16 16:36:58 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 16 Aug 2021 16:36:58 GMT
Subject: RFR: Make immediate trash of old regions with no live objects
In-Reply-To: <A83h7tHbb3N-X6XVhLhbEmJ1sT39UHuTsONC0b71wWA=.fc86eed8-2216-4daa-89f0-8f95d2f28d5d@github.com>
References: <A83h7tHbb3N-X6XVhLhbEmJ1sT39UHuTsONC0b71wWA=.fc86eed8-2216-4daa-89f0-8f95d2f28d5d@github.com>
Message-ID: <8JUrvxxGpN1qEz-9wL-TNA7bDVMCfapLliRbdS1i8vY=.c4c1521c-54b9-42ba-886a-df7588c4d012@github.com>

On Mon, 16 Aug 2021 15:15:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

> At the end of old marking we can immediately recycle regions with no live objects. This optimization is already done for young/global collects, but it was missing from old collections. This fixes an assertion during preparation for evacuation that _all_ cset regions have _some_ live data.

Looks good! Thanks!

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

Marked as reviewed by rkennke (Lead).

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

From wkemper at openjdk.java.net  Mon Aug 16 17:15:04 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Mon, 16 Aug 2021 17:15:04 GMT
Subject: Integrated: Make immediate trash of old regions with no live objects
In-Reply-To: <A83h7tHbb3N-X6XVhLhbEmJ1sT39UHuTsONC0b71wWA=.fc86eed8-2216-4daa-89f0-8f95d2f28d5d@github.com>
References: <A83h7tHbb3N-X6XVhLhbEmJ1sT39UHuTsONC0b71wWA=.fc86eed8-2216-4daa-89f0-8f95d2f28d5d@github.com>
Message-ID: <dQ2AJ34rc3qxgjKJ4BZRRGbjItRCe_S7uZ4tBHg-v3c=.946bf62f-93e5-4a32-b469-37f254b2a4e7@github.com>

On Mon, 16 Aug 2021 15:15:10 GMT, William Kemper <wkemper at openjdk.org> wrote:

> At the end of old marking we can immediately recycle regions with no live objects. This optimization is already done for young/global collects, but it was missing from old collections. This fixes an assertion during preparation for evacuation that _all_ cset regions have _some_ live data.

This pull request has now been integrated.

Changeset: df8c0562
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/df8c05626d465451c511bdc8f2c664cf7696676f
Stats:     7 lines in 1 file changed: 4 ins; 0 del; 3 mod

Make immediate trash of old regions with no live objects

Reviewed-by: rkennke

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

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

From zgu at openjdk.java.net  Tue Aug 17 00:38:28 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 17 Aug 2021 00:38:28 GMT
Subject: Integrated: 8272327: Shenandoah: Avoid enqueuing duplicate string
 candidates
In-Reply-To: <HWtvzhd_JU49IAxhM56kxX5tz3nfHWTOQx-gZZtlTgY=.0c14f8df-f783-43c5-9dcc-6d7d8ce5a31f@github.com>
References: <HWtvzhd_JU49IAxhM56kxX5tz3nfHWTOQx-gZZtlTgY=.0c14f8df-f783-43c5-9dcc-6d7d8ce5a31f@github.com>
Message-ID: <00vLItF5y9KgKb3g-eOhSLXTyyF95OwyLTUEwp37IYk=.653b291d-24d8-4d47-b3c8-4ffa37b5758b@github.com>

On Thu, 12 Aug 2021 00:12:14 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Now, there is a new API java_lang_String::test_and_set_deduplication_requested() that can help to identify if a string candidate has been enqueued, so that we can avoid enqueuing duplicate entries.
> 
> Test:
> - [x] hotspot_gc_shenandoah

This pull request has now been integrated.

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

8272327: Shenandoah: Avoid enqueuing duplicate string candidates

Reviewed-by: rkennke

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

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

From kbarrett at openjdk.java.net  Tue Aug 17 02:03:27 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 17 Aug 2021 02:03:27 GMT
Subject: RFR: 8272520: Inline GenericTaskQueue::initialize() to the
 constructor [v2]
In-Reply-To: <wIXYpEbbWghHPpkbFtk_5qqV8SoARhdEVorHfnY9LaM=.adf42c23-17e4-482a-b43b-f1b441b1046c@github.com>
References: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
 <wIXYpEbbWghHPpkbFtk_5qqV8SoARhdEVorHfnY9LaM=.adf42c23-17e4-482a-b43b-f1b441b1046c@github.com>
Message-ID: <3_bUhZAWBbYbVX953szkIP8Ulmke0865odp6crbELB4=.cb721896-63a9-44d4-bdbd-3c48f1e16d18@github.com>

On Mon, 16 Aug 2021 14:46:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of GenericTaskQueue initialization API.
>> 
>> Test: tier1_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Looks even better.

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

Marked as reviewed by kbarrett (Reviewer).

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

From iwalulya at openjdk.java.net  Tue Aug 17 08:35:31 2021
From: iwalulya at openjdk.java.net (Ivan Walulya)
Date: Tue, 17 Aug 2021 08:35:31 GMT
Subject: RFR: 8272520: Inline GenericTaskQueue::initialize() to the
 constructor [v2]
In-Reply-To: <wIXYpEbbWghHPpkbFtk_5qqV8SoARhdEVorHfnY9LaM=.adf42c23-17e4-482a-b43b-f1b441b1046c@github.com>
References: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
 <wIXYpEbbWghHPpkbFtk_5qqV8SoARhdEVorHfnY9LaM=.adf42c23-17e4-482a-b43b-f1b441b1046c@github.com>
Message-ID: <k7TVow7vZaAqnZe6zAFdM9Xb2Qo1x9rTwj1zFHE9R3E=.f46a1f96-0673-43e5-9a1a-c1d54d41a3e1@github.com>

On Mon, 16 Aug 2021 14:46:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of GenericTaskQueue initialization API.
>> 
>> Test: tier1_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Marked as reviewed by iwalulya (Committer).

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

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

From ayang at openjdk.java.net  Tue Aug 17 12:46:33 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 17 Aug 2021 12:46:33 GMT
Subject: RFR: 8272520: Inline GenericTaskQueue::initialize() to the
 constructor [v2]
In-Reply-To: <wIXYpEbbWghHPpkbFtk_5qqV8SoARhdEVorHfnY9LaM=.adf42c23-17e4-482a-b43b-f1b441b1046c@github.com>
References: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
 <wIXYpEbbWghHPpkbFtk_5qqV8SoARhdEVorHfnY9LaM=.adf42c23-17e4-482a-b43b-f1b441b1046c@github.com>
Message-ID: <XGyNxGGiJDcFCILTmMuefBRlJEmnj6Pq5jGmn4Lg5SE=.98647b6b-c38a-454f-af56-55ce23b53078@github.com>

On Mon, 16 Aug 2021 14:46:52 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple refactoring of GenericTaskQueue initialization API.
>> 
>> Test: tier1_gc
>
> Albert Mingkun Yang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review

Thanks for the review.

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

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

From ayang at openjdk.java.net  Tue Aug 17 12:46:34 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Tue, 17 Aug 2021 12:46:34 GMT
Subject: Integrated: 8272520: Inline GenericTaskQueue::initialize() to the
 constructor
In-Reply-To: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
References: <YLeUp70FQz6XcnTMn92PURiOVkdgTtyl1ZX7cA96OKk=.39e802da-9fae-4a04-8851-fa90c32f0141@github.com>
Message-ID: <vky0Es-EA2Erra74dfwGpDS-8kQems3tV1d6D54dKP0=.7d84c802-4b16-489a-9dd5-75f58c5edc9b@github.com>

On Mon, 16 Aug 2021 13:09:03 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple refactoring of GenericTaskQueue initialization API.
> 
> Test: tier1_gc

This pull request has now been integrated.

Changeset: 2aaf7952
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2aaf795270eb07eb155df9a7f5e1d6901f09d8f0
Stats:     24 lines in 10 files changed: 1 ins; 20 del; 3 mod

8272520: Inline GenericTaskQueue::initialize() to the constructor

Reviewed-by: kbarrett, iwalulya

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

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

From zgu at openjdk.java.net  Tue Aug 17 18:39:37 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Tue, 17 Aug 2021 18:39:37 GMT
Subject: RFR: 8267188: gc/stringdedup/TestStringDeduplicationInterned.java
 fails with Shenandoah
Message-ID: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>

Shenandoah currently enqueues deduplication candidates when marks object gray.

However, it can not do so when it scans roots, as it can potentially result lock rank inversion between stack watermark lock and dedup request buffer lock.

As the result, it can not enqueue as many as candidates as it should be able to, I believe JDK-8271834 is due to the same problem. I purpose we switch to enqueue candidates when we mark object black.

We are still not able to enqueue all candidates, only when they have displaced headers or have monitor inflating in progress. Upstream is working on removing displaced headers, we should revisit the logic afterward, or we can choose to deduplicate all string regardless their ages.



Test:
- [x] hotspot_gc_shenandoah
- [x] tier1 with -XX:+UseShenandoahGC and -XX:+UseStringDeduplication

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

Commit messages:
 - fix format
 - v0
 - Merge branch 'master' into JDK-8267188-string-intern
 - v0

Changes: https://git.openjdk.java.net/jdk/pull/5151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5151&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8267188
  Stats: 112 lines in 8 files changed: 35 ins; 28 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5151/head:pull/5151

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

From shade at openjdk.java.net  Wed Aug 18 07:27:07 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 18 Aug 2021 07:27:07 GMT
Subject: RFR: Fix Zero builds
Message-ID: <lOaLI4yGbHxXWMnFuVZbnL0EfZW6XsLgtdGDU4zjyeI=.f1a8e12a-6768-43b0-a692-286555914128@github.com>

There are many build failures in Zero configurations, all look like this:

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

Commit messages:
 - Fix Zero builds

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

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

From wkemper at openjdk.java.net  Wed Aug 18 17:00:56 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Wed, 18 Aug 2021 17:00:56 GMT
Subject: RFR: Fix Zero builds
In-Reply-To: <lOaLI4yGbHxXWMnFuVZbnL0EfZW6XsLgtdGDU4zjyeI=.f1a8e12a-6768-43b0-a692-286555914128@github.com>
References: <lOaLI4yGbHxXWMnFuVZbnL0EfZW6XsLgtdGDU4zjyeI=.f1a8e12a-6768-43b0-a692-286555914128@github.com>
Message-ID: <D1NQzEj6sNZynGtIDY_cASqhbUsBTceQNL_tyVwiDB0=.f0ff9eeb-fba3-403d-a3e2-fbb92e2b736f@github.com>

On Wed, 18 Aug 2021 07:21:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are many build failures in Zero configurations, all look like this:

Looks good to me. Apologies for breaking the zero build. We'll add this configuration to our build pipeline.

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

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

From rkennke at openjdk.java.net  Wed Aug 18 18:58:26 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 18 Aug 2021 18:58:26 GMT
Subject: RFR: 8270554: Shenandoah: Optimize heap scan loop
In-Reply-To: <eADDeXXW0aSHzwkJ4PaUKFDSZTBOlI33lEYI2gfl1RQ=.d288baea-4f1a-4c7b-862e-0b2904be1df7@github.com>
References: <eADDeXXW0aSHzwkJ4PaUKFDSZTBOlI33lEYI2gfl1RQ=.d288baea-4f1a-4c7b-862e-0b2904be1df7@github.com>
Message-ID: <CDkToQsNfh8BeZ54eAijnjvwdG001NE6xg0nuPQzBrA=.8d675e8b-7b73-4ba4-87cc-f96615689aa2@github.com>

On Thu, 15 Jul 2021 14:37:26 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is a fall-out from Lilliput. I noticed that in the heap scan loop, we load the size of objects in the size-based object scanner, even though all of the object closures already load the size, or at least in some cases, the Klass* which is necessary to determine the size. We can optimize that by making the scan loop co-operate with the closures. In other words, this changes the loop to avoid double-loading the Klass* in most cases in the size-based part of the scan loop.
> 
> Note: the motivation in Lilliput is not performance, but correctness, because there loading the Klass* means loading the header, and this needs to be done carefully because of concurrent evacuation and concurrent locking code both messing with the header, and thus depends a lot on the actual closures to do it correctly. 
> 
> Implementation notes:
> - SH::evacuate_object() has been changed so that it can return both the forwardee and the size. I opted to return the size as return-value because otherwise I'd have to null check an incoming pointer in the cases when we're not interested in the size. The way it is done, it can simply be ignored (and optimized-out) by the compiler.
> - I added a do_object_size() variant to all affected iterators. I tried to do it with templates, but could not figure out how to please the compiler.
> - While I was at it, I marked all do_object() methods as 'inline'.
> - I ran some benchmarks. I think I see consistent but small improvements in evac and update-refs times, but it's not large enough to say that it is a definite improvement.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 (+UseShenandoahGC)
>  - [x] specjvm testing

Ping? Any opinions?

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

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

From shade at openjdk.java.net  Thu Aug 19 08:38:57 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Aug 2021 08:38:57 GMT
Subject: RFR: Fix Zero builds
In-Reply-To: <lOaLI4yGbHxXWMnFuVZbnL0EfZW6XsLgtdGDU4zjyeI=.f1a8e12a-6768-43b0-a692-286555914128@github.com>
References: <lOaLI4yGbHxXWMnFuVZbnL0EfZW6XsLgtdGDU4zjyeI=.f1a8e12a-6768-43b0-a692-286555914128@github.com>
Message-ID: <LjHS26IGVzfWuSiMNTqYzctPrK1aHuDA7-qFNRu8C5Q=.195ba1d1-87ca-47c0-889f-569e58e26190@github.com>

On Wed, 18 Aug 2021 07:21:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are many build failures in Zero configurations, all look like this:

Nothing to worry about. These build configs are for sanity checking, you are not expected to run them in your workflows.

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

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

From xcheng.dev at gmail.com  Wed Aug 18 23:58:11 2021
From: xcheng.dev at gmail.com (Xi Cheng)
Date: Wed, 18 Aug 2021 16:58:11 -0700
Subject: JVM Crashes after switching from G1GC to Shenandoah
Message-ID: <CAAJwpyYOiq_KkcX-fn8wj693TYpsXXbM07Upk_72qdcngs1gDw@mail.gmail.com>

Hi, after we have switched from G1GC to Shenandoah for JDK 11.0.11 on
Aarch64,
We start frequently encounter JVM crashes with the following messages:

#

# A fatal error has been detected by the Java Runtime Environment:

#

#  SIGSEGV (0xb) at pc=0x0000ffff7485b424, pid=9, tid=1661

#

# JRE version: OpenJDK Runtime Environment (11.0.11+9) (build
11.0.11+9-Ubuntu-0ubuntu2.18.04)

# Java VM: OpenJDK 64-Bit Server VM (11.0.11+9-Ubuntu-0ubuntu2.18.04, mixed
mode, tiered, shenandoah gc, linux-aarch64)

# Problematic frame:

# J 22198 c1
java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;
java.base at 11.0.11 (380 bytes) @ 0x0000ffff7485b424
[0x0000ffff74856d00+0x0000000000004724]

#

# Core dump will be written. Default location: Core dumps may be processed
with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping
to ...)

#

# An error report file with more information is saved as:

# /java_error.log

Compiled method (c1) 4020651 22198       3
java.util.concurrent.SynchronousQueue$TransferStack::transfer
(380 bytes)

 total in heap  [0x0000ffff74855b90,0x0000ffff748609c8] = 44600

 relocation     [0x0000ffff74855d00,0x0000ffff74856cd0] = 4048

 main code      [0x0000ffff74856d00,0x0000ffff7485dd80] = 28800

 stub code      [0x0000ffff7485dd80,0x0000ffff7485e890] = 2832

 oops           [0x0000ffff7485e890,0x0000ffff7485e8d0] = 64

 metadata       [0x0000ffff7485e8d0,0x0000ffff7485eb70] = 672

 scopes data    [0x0000ffff7485eb70,0x0000ffff7485fc78] = 4360

 scopes pcs     [0x0000ffff7485fc78,0x0000ffff74860978] = 3328

 dependencies   [0x0000ffff74860978,0x0000ffff74860980] = 8

 nul chk table  [0x0000ffff74860980,0x0000ffff748609c8] = 72

Could not load hsdis-aarch64.so; library not loadable; PrintAssembly is
disabled

#

# If you would like to submit a bug report, please visit:

#   https://bugs.launchpad.net/ubuntu/+source/openjdk-lts

#


It is not too clear to us why this happens, our JVM arg is as follows:


-XX:+UnlockExperimentalVMOptions -XX:+PreserveFramePointer
-XX:+UseShenandoahGC -XX:+AggressiveOpts -XX:ReservedCodeCacheSize=500M
-XX:PerMethodRecompilationCutoff=10000
-XX:PerBytecodeRecompilationCutoff=10000 -Xms157286m -Xmx157286m
-XX:MaxGCPauseMillis=1000 -XX:NativeMemoryTracking=detail
-XX:InitiatingHeapOccupancyPercent=5 -XX:OnOutOfMemoryError="kill -9 %p"
-XX:G1NewSizePercent=1 -XX:ParallelGCThreads=40 -XX:ConcGCThreads=24


Curious what may lead to the error above and what should we look for in the
error and gc logs?


Thanks

From rkennke at openjdk.java.net  Thu Aug 19 10:58:51 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 19 Aug 2021 10:58:51 GMT
Subject: RFR: Fix Zero builds
In-Reply-To: <lOaLI4yGbHxXWMnFuVZbnL0EfZW6XsLgtdGDU4zjyeI=.f1a8e12a-6768-43b0-a692-286555914128@github.com>
References: <lOaLI4yGbHxXWMnFuVZbnL0EfZW6XsLgtdGDU4zjyeI=.f1a8e12a-6768-43b0-a692-286555914128@github.com>
Message-ID: <LJwoFgBpFlx5WWQ4SgGx61-uuS406QZRW9KYIejkWlY=.dfff5e57-1d4c-4d12-ac0d-f0e8b854d787@github.com>

On Wed, 18 Aug 2021 07:21:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are many build failures in Zero configurations, all look like this:

Marked as reviewed by rkennke (Lead).

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

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

From shade at openjdk.java.net  Thu Aug 19 11:02:01 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Aug 2021 11:02:01 GMT
Subject: Integrated: Fix Zero builds
In-Reply-To: <lOaLI4yGbHxXWMnFuVZbnL0EfZW6XsLgtdGDU4zjyeI=.f1a8e12a-6768-43b0-a692-286555914128@github.com>
References: <lOaLI4yGbHxXWMnFuVZbnL0EfZW6XsLgtdGDU4zjyeI=.f1a8e12a-6768-43b0-a692-286555914128@github.com>
Message-ID: <Bs2n_G1H9LiPaASPx6Ooqgt87rERACRaf0G_xFG3U5k=.379bd93c-fecc-4faa-94b1-a1bfb88eeafd@github.com>

On Wed, 18 Aug 2021 07:21:01 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> There are many build failures in Zero configurations, all look like this:

This pull request has now been integrated.

Changeset: c02907e5
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/c02907e53ea63fa7fe30961c3d917d7a5874f30b
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

Fix Zero builds

Reviewed-by: rkennke

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

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

From rkennke at redhat.com  Thu Aug 19 11:19:32 2021
From: rkennke at redhat.com (Roman Kennke)
Date: Thu, 19 Aug 2021 13:19:32 +0200
Subject: JVM Crashes after switching from G1GC to Shenandoah
In-Reply-To: <CAAJwpyYOiq_KkcX-fn8wj693TYpsXXbM07Upk_72qdcngs1gDw@mail.gmail.com>
References: <CAAJwpyYOiq_KkcX-fn8wj693TYpsXXbM07Upk_72qdcngs1gDw@mail.gmail.com>
Message-ID: <fe350828-d349-c904-2679-8227005a4ecc@redhat.com>

Hi Xi Cheng,

Thanks for the report!

This looks like a problem in the C1 cas-obj barrier of Shenandoah.

Could you run this with a fastdebug build, and send us resulting hs_err* 
file?

https://builds.shipilev.net/openjdk-jdk11/

In the meantime we'll look for possible bugs / fixes.

Thanks,
Roman

> Hi, after we have switched from G1GC to Shenandoah for JDK 11.0.11 on
> Aarch64,
> We start frequently encounter JVM crashes with the following messages:
> 
> #
> 
> # A fatal error has been detected by the Java Runtime Environment:
> 
> #
> 
> #  SIGSEGV (0xb) at pc=0x0000ffff7485b424, pid=9, tid=1661
> 
> #
> 
> # JRE version: OpenJDK Runtime Environment (11.0.11+9) (build
> 11.0.11+9-Ubuntu-0ubuntu2.18.04)
> 
> # Java VM: OpenJDK 64-Bit Server VM (11.0.11+9-Ubuntu-0ubuntu2.18.04, mixed
> mode, tiered, shenandoah gc, linux-aarch64)
> 
> # Problematic frame:
> 
> # J 22198 c1
> java.util.concurrent.SynchronousQueue$TransferStack.transfer(Ljava/lang/Object;ZJ)Ljava/lang/Object;
> java.base at 11.0.11 (380 bytes) @ 0x0000ffff7485b424
> [0x0000ffff74856d00+0x0000000000004724]
> 
> #
> 
> # Core dump will be written. Default location: Core dumps may be processed
> with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping
> to ...)
> 
> #
> 
> # An error report file with more information is saved as:
> 
> # /java_error.log
> 
> Compiled method (c1) 4020651 22198       3
> java.util.concurrent.SynchronousQueue$TransferStack::transfer
> (380 bytes)
> 
>   total in heap  [0x0000ffff74855b90,0x0000ffff748609c8] = 44600
> 
>   relocation     [0x0000ffff74855d00,0x0000ffff74856cd0] = 4048
> 
>   main code      [0x0000ffff74856d00,0x0000ffff7485dd80] = 28800
> 
>   stub code      [0x0000ffff7485dd80,0x0000ffff7485e890] = 2832
> 
>   oops           [0x0000ffff7485e890,0x0000ffff7485e8d0] = 64
> 
>   metadata       [0x0000ffff7485e8d0,0x0000ffff7485eb70] = 672
> 
>   scopes data    [0x0000ffff7485eb70,0x0000ffff7485fc78] = 4360
> 
>   scopes pcs     [0x0000ffff7485fc78,0x0000ffff74860978] = 3328
> 
>   dependencies   [0x0000ffff74860978,0x0000ffff74860980] = 8
> 
>   nul chk table  [0x0000ffff74860980,0x0000ffff748609c8] = 72
> 
> Could not load hsdis-aarch64.so; library not loadable; PrintAssembly is
> disabled
> 
> #
> 
> # If you would like to submit a bug report, please visit:
> 
> #   https://bugs.launchpad.net/ubuntu/+source/openjdk-lts
> 
> #
> 
> 
> It is not too clear to us why this happens, our JVM arg is as follows:
> 
> 
> -XX:+UnlockExperimentalVMOptions -XX:+PreserveFramePointer
> -XX:+UseShenandoahGC -XX:+AggressiveOpts -XX:ReservedCodeCacheSize=500M
> -XX:PerMethodRecompilationCutoff=10000
> -XX:PerBytecodeRecompilationCutoff=10000 -Xms157286m -Xmx157286m
> -XX:MaxGCPauseMillis=1000 -XX:NativeMemoryTracking=detail
> -XX:InitiatingHeapOccupancyPercent=5 -XX:OnOutOfMemoryError="kill -9 %p"
> -XX:G1NewSizePercent=1 -XX:ParallelGCThreads=40 -XX:ConcGCThreads=24
> 
> 
> Curious what may lead to the error above and what should we look for in the
> error and gc logs?
> 
> 
> Thanks
> 


From shade at redhat.com  Thu Aug 19 11:51:14 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Thu, 19 Aug 2021 13:51:14 +0200
Subject: JVM Crashes after switching from G1GC to Shenandoah
In-Reply-To: <fe350828-d349-c904-2679-8227005a4ecc@redhat.com>
References: <CAAJwpyYOiq_KkcX-fn8wj693TYpsXXbM07Upk_72qdcngs1gDw@mail.gmail.com>
 <fe350828-d349-c904-2679-8227005a4ecc@redhat.com>
Message-ID: <4c4fb2f9-df12-3c90-0b3c-4598cb4dba05@redhat.com>

On 8/19/21 1:19 PM, Roman Kennke wrote:
> This looks like a problem in the C1 cas-obj barrier of Shenandoah.

Yup, there are a few missing fixes in 11u for C1 cas-obj barrier.

> Could you run this with a fastdebug build, and send us resulting hs_err*
> file?
> 
> https://builds.shipilev.net/openjdk-jdk11/

Better yet:
   https://builds.shipilev.net/openjdk-jdk11-dev/

This would include all current unreleased 11u fixes.

-- 
Thanks,
-Aleksey


From rkennke at openjdk.java.net  Thu Aug 19 12:13:21 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 19 Aug 2021 12:13:21 GMT
Subject: RFR: 8267188: gc/stringdedup/TestStringDeduplicationInterned.java
 fails with Shenandoah
In-Reply-To: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
References: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
Message-ID: <Qe5jcbnB8oAzC0K8nPHx0918R6eSTHKqbrt9Q6dr3cY=.e715f5d4-7888-4aca-a266-af8da6487373@github.com>

On Tue, 17 Aug 2021 18:32:54 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah currently enqueues deduplication candidates when marks object gray.
> 
> However, it can not do so when it scans roots, as it can potentially result lock rank inversion between stack watermark lock and dedup request buffer lock.
> 
> As the result, it can not enqueue as many as candidates as it should be able to, I believe JDK-8271834 is due to the same problem. I purpose we switch to enqueue candidates when we mark object black.
> 
> We are still not able to enqueue all candidates, only when they have displaced headers or have monitor inflating in progress. Upstream is working on removing displaced headers, we should revisit the logic afterward, or we can choose to deduplicate all string regardless their ages.
> 
> 
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with -XX:+UseShenandoahGC and -XX:+UseStringDeduplication

Looks good to me!

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

Marked as reviewed by rkennke (Reviewer).

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

From wkemper at openjdk.java.net  Thu Aug 19 22:42:07 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 19 Aug 2021 22:42:07 GMT
Subject: RFR: Preserve and restore original element count for card table
 barrier
Message-ID: <NBx-XF0RYR1YVpXlx_rCV0WN1znm6WbSdl4A341FXZo=.f5179194-335e-4aa3-ba02-875e9dbb2da0@github.com>

The "pre-write" barrier for Generational Shenandoah was missing a bit of code to store away the original `count` of elements in the array being copied. As the array copy code decrements through the `count` it is reduced to zero. This caused the "post-write" barrier to believe we just copied an empty array and that it would be safe to skip card marking. This change preserves the original `count` in the prologue and restores it in the epilogue.

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

Commit messages:
 - Preserve and restore original element count for card table barrier

Changes: https://git.openjdk.java.net/shenandoah/pull/59/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=59&range=00
  Stats: 33 lines in 1 file changed: 26 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/59.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/59/head:pull/59

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

From wkemper at openjdk.java.net  Thu Aug 19 22:57:52 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Thu, 19 Aug 2021 22:57:52 GMT
Subject: RFR: Update alloc liveness data during final mark of old generation
Message-ID: <hjRgL2EAfAFID-IVuiJ2CFxyshJGC17X6PflkeNBsI8=.607bc4b7-8c99-4486-bd31-355be54b3e78@github.com>

Final mark for old generation was missing the use of `ShenandoahFinalMarkUpdateRegionStateClosure` to update region liveness data with allocated objects. In some cases, this could lead to objects being promoted into old regions that appear to have no live data resulting in these promoted objects being erroneously collected.

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

Commit messages:
 - Update alloc liveness data during final mark of old generation

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

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

From rkennke at openjdk.java.net  Fri Aug 20 10:18:59 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 20 Aug 2021 10:18:59 GMT
Subject: RFR: Preserve and restore original element count for card table
 barrier
In-Reply-To: <NBx-XF0RYR1YVpXlx_rCV0WN1znm6WbSdl4A341FXZo=.f5179194-335e-4aa3-ba02-875e9dbb2da0@github.com>
References: <NBx-XF0RYR1YVpXlx_rCV0WN1znm6WbSdl4A341FXZo=.f5179194-335e-4aa3-ba02-875e9dbb2da0@github.com>
Message-ID: <e7YGEQtJODt1wgOyqFpNLNB7z9HEvRv5a3XacbO6QYU=.59de9cb1-22b3-44bf-b2fe-3ac518b9b9ca@github.com>

On Thu, 19 Aug 2021 22:36:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The "pre-write" barrier for Generational Shenandoah was missing a bit of code to store away the original `count` of elements in the array being copied. As the array copy code decrements through the `count` it is reduced to zero. This caused the "post-write" barrier to believe we just copied an empty array and that it would be safe to skip card marking. This change preserves the original `count` in the prologue and restores it in the epilogue.

Looks good to me! Thanks!

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

Marked as reviewed by rkennke (Lead).

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

From rkennke at openjdk.java.net  Fri Aug 20 10:20:53 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 20 Aug 2021 10:20:53 GMT
Subject: RFR: Update alloc liveness data during final mark of old
 generation
In-Reply-To: <hjRgL2EAfAFID-IVuiJ2CFxyshJGC17X6PflkeNBsI8=.607bc4b7-8c99-4486-bd31-355be54b3e78@github.com>
References: <hjRgL2EAfAFID-IVuiJ2CFxyshJGC17X6PflkeNBsI8=.607bc4b7-8c99-4486-bd31-355be54b3e78@github.com>
Message-ID: <DS5lehT3m3piW3552yxB9h30qP5dvTSMA-izVhS6614=.c0d5934e-e354-4eed-bde5-7f5e86676439@github.com>

On Thu, 19 Aug 2021 22:52:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Final mark for old generation was missing the use of `ShenandoahFinalMarkUpdateRegionStateClosure` to update region liveness data with allocated objects. In some cases, this could lead to objects being promoted into old regions that appear to have no live data resulting in these promoted objects being erroneously collected.

Ok! Thanks!

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

Marked as reviewed by rkennke (Lead).

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

From ayang at openjdk.java.net  Fri Aug 20 13:37:34 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 20 Aug 2021 13:37:34 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
Message-ID: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>

Simple change of merging `is_instance` and `is_instance_inlined`.

Test: build

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

Commit messages:
 - inline

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

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

From redestad at openjdk.java.net  Fri Aug 20 14:19:21 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 Aug 2021 14:19:21 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <iHf3PiQ0Cf3NZJmwyHjHIrq2gVYAZRi4nMYN8pQmJGM=.b0a86042-0fbf-4dbc-b1c4-df04bcfa172b@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

It seems the split between `is_instance` and `is_instance_inlined` was introduced recently (5314d28f8412e9c993880884a3b626f05b590743) and I think the point to actively opt-out of inlining in performance-insensitive places (also makes the generated code a bit less noisy and easier to debug, by some accounts). 

Since it was done intentionally I'd check we don't lose something by consolidating these into a single inlined version. E.g. measure that the static size of libjvm doesn't grow by much.

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

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

From coleenp at openjdk.java.net  Fri Aug 20 15:24:24 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 20 Aug 2021 15:24:24 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <BzNn4LDLe5I7717pVPBp8aPOmqNMoKvtLJNItwZjJQE=.a8c3e232-bf98-4967-a967-9da2f105d208@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

src/hotspot/share/classfile/javaClasses.inline.hpp line 126:

> 124: }
> 125: 
> 126: bool java_lang_String::is_instance(oop obj) {

I don't really see anything wrong with this.  is_instance() is called above in asserts but that shouldn't affect performance by increasing the size of generated code.

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

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

From ayang at openjdk.java.net  Fri Aug 20 18:24:28 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 20 Aug 2021 18:24:28 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <iHf3PiQ0Cf3NZJmwyHjHIrq2gVYAZRi4nMYN8pQmJGM=.b0a86042-0fbf-4dbc-b1c4-df04bcfa172b@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <iHf3PiQ0Cf3NZJmwyHjHIrq2gVYAZRi4nMYN8pQmJGM=.b0a86042-0fbf-4dbc-b1c4-df04bcfa172b@github.com>
Message-ID: <dj7A-OjMV6aOOISqvf68m8zKjHidhJyuc_KuPEN7HjA=.ee305dcd-7044-42df-8bb4-079c9356ecf7@github.com>

On Fri, 20 Aug 2021 14:15:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> It seems the split between is_instance and is_instance_inlined was introduced recently (5314d28)

I believe the split was introduced in [8072911: Remove includes of oop.inline.hpp from .hpp files](https://github.com/openjdk/jdk/commit/4913ad5d7dcc8ae4e034aa110a97ea8313b2b3ee) to address potential circular dependencies.

> measure that the static size of libjvm doesn't grow by much.

Before:


ls -l build/*/images/jdk/lib/server/libjvm.so
-rw-r--r-- 1 albert albert 213664560 Aug 20 19:01 build/linux-x64-debug/images/jdk/lib/server/libjvm.so
-rw-r--r-- 1 albert albert  24243456 Aug 20 19:11 build/linux-x64-release/images/jdk/lib/server/libjvm.so


After:


ls -l build/*/images/jdk/lib/server/libjvm.so
-rw-r--r-- 1 albert albert 213727136 Aug 20 19:12 build/linux-x64-debug/images/jdk/lib/server/libjvm.so
-rw-r--r-- 1 albert albert  24247552 Aug 20 19:12 build/linux-x64-release/images/jdk/lib/server/libjvm.so


In summary:

for fastdebug: 213664560 -> 213727136, +62576 bytes, +0.03%
for release: 24243456 -> 24247552, +4096 bytes, +0.02%

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

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

From ayang at openjdk.java.net  Fri Aug 20 18:24:30 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Fri, 20 Aug 2021 18:24:30 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <BzNn4LDLe5I7717pVPBp8aPOmqNMoKvtLJNItwZjJQE=.a8c3e232-bf98-4967-a967-9da2f105d208@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <BzNn4LDLe5I7717pVPBp8aPOmqNMoKvtLJNItwZjJQE=.a8c3e232-bf98-4967-a967-9da2f105d208@github.com>
Message-ID: <J6afu4W5Vo8H-R1cu7vRXoeGJtpF0P-ADvMNykVMiyc=.6c04d601-7ffb-4310-8b09-50c124c56eae@github.com>

On Fri, 20 Aug 2021 15:20:59 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Simple change of merging `is_instance` and `is_instance_inlined`.
>> 
>> Test: build
>
> src/hotspot/share/classfile/javaClasses.inline.hpp line 126:
> 
>> 124: }
>> 125: 
>> 126: bool java_lang_String::is_instance(oop obj) {
> 
> I don't really see anything wrong with this.  is_instance() is called above in asserts but that shouldn't affect performance by increasing the size of generated code.

`is_instance()` is called in non-assertion code as well, e.g. `ConstantPool::add_dumped_interned_strings`. By merging the two versions, one wouldn't use the potentially slower version by accident, and it's also more consistent with `is_instance` of other classes (e.g. `java_lang_Class`) in the same file.

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

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

From redestad at openjdk.java.net  Fri Aug 20 19:12:23 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 Aug 2021 19:12:23 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <J6afu4W5Vo8H-R1cu7vRXoeGJtpF0P-ADvMNykVMiyc=.6c04d601-7ffb-4310-8b09-50c124c56eae@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <BzNn4LDLe5I7717pVPBp8aPOmqNMoKvtLJNItwZjJQE=.a8c3e232-bf98-4967-a967-9da2f105d208@github.com>
 <J6afu4W5Vo8H-R1cu7vRXoeGJtpF0P-ADvMNykVMiyc=.6c04d601-7ffb-4310-8b09-50c124c56eae@github.com>
Message-ID: <rUn_fQvPClB4ACP81NE56uXif52bWulw-B614d5Ab8Q=.4e50fdda-bff4-41a4-b6be-5f97ea3ae9ca@github.com>

On Fri, 20 Aug 2021 18:20:57 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.inline.hpp line 126:
>> 
>>> 124: }
>>> 125: 
>>> 126: bool java_lang_String::is_instance(oop obj) {
>> 
>> I don't really see anything wrong with this.  is_instance() is called above in asserts but that shouldn't affect performance by increasing the size of generated code.
>
> `is_instance()` is called in non-assertion code as well, e.g. `ConstantPool::add_dumped_interned_strings`. By merging the two versions, one wouldn't use the potentially slower version by accident, and it's also more consistent with `is_instance` of other classes (e.g. `java_lang_Class`) in the same file.

While `ConstantPool::add_dumped_interned_strings` might be an example of something that's not performance sensitive (even with dynamic CDS), the 0.02%/4Kb static size increase is less than concerning. Thanks for checking!

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

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

From coleenp at openjdk.java.net  Fri Aug 20 19:35:27 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 20 Aug 2021 19:35:27 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <-v-YxlutPfjTiwZXazD1wN5ksWkVlkGqCa2Oe4cNYfM=.11450c35-a870-466f-b5fe-987b1c6cbb05@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

Looks good! Thanks for checking for the non-inlined version of is_instance.

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

Marked as reviewed by coleenp (Reviewer).

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

From redestad at openjdk.java.net  Fri Aug 20 19:41:26 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 Aug 2021 19:41:26 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <CIzxUnx85HAmevygZLQ0zK7qMmamG9spgwQhpTWOihc=.de53e41c-5ed4-4b57-87cb-177352a54975@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

FWIW this looks good to me too. ????

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

Marked as reviewed by redestad (Reviewer).

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

From wkemper at openjdk.java.net  Fri Aug 20 21:17:14 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 20 Aug 2021 21:17:14 GMT
Subject: git: openjdk/shenandoah: master: Update alloc liveness data during
 final mark of old generation
Message-ID: <5ed1b241-765d-4208-833b-6d81602a32dd@openjdk.org>

Changeset: 7dc75373
Author:    William Kemper <wkemper at openjdk.org>
Date:      2021-08-20 21:16:54 +0000
URL:       https://git.openjdk.java.net/shenandoah/commit/7dc75373a09d3ca7d0a01ab7f5ece8696590ad6e

Update alloc liveness data during final mark of old generation

Reviewed-by: rkennke

! src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahGeneration.hpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGC.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp
! src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.hpp


From wkemper at openjdk.java.net  Fri Aug 20 21:19:53 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 20 Aug 2021 21:19:53 GMT
Subject: Integrated: Update alloc liveness data during final mark of old
 generation
In-Reply-To: <hjRgL2EAfAFID-IVuiJ2CFxyshJGC17X6PflkeNBsI8=.607bc4b7-8c99-4486-bd31-355be54b3e78@github.com>
References: <hjRgL2EAfAFID-IVuiJ2CFxyshJGC17X6PflkeNBsI8=.607bc4b7-8c99-4486-bd31-355be54b3e78@github.com>
Message-ID: <DJLGxAGT6fOI9B9gyGLS8RUMNa5Visq6onvkK3-SbxA=.2bae2e35-141f-46a7-aa34-e31d2c156291@github.com>

On Thu, 19 Aug 2021 22:52:23 GMT, William Kemper <wkemper at openjdk.org> wrote:

> Final mark for old generation was missing the use of `ShenandoahFinalMarkUpdateRegionStateClosure` to update region liveness data with allocated objects. In some cases, this could lead to objects being promoted into old regions that appear to have no live data resulting in these promoted objects being erroneously collected.

This pull request has now been integrated.

Changeset: 7dc75373
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/7dc75373a09d3ca7d0a01ab7f5ece8696590ad6e
Stats:     42 lines in 5 files changed: 32 ins; 5 del; 5 mod

Update alloc liveness data during final mark of old generation

Reviewed-by: rkennke

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

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

From wkemper at openjdk.java.net  Fri Aug 20 21:21:00 2021
From: wkemper at openjdk.java.net (William Kemper)
Date: Fri, 20 Aug 2021 21:21:00 GMT
Subject: Integrated: Preserve and restore original element count for card
 table barrier
In-Reply-To: <NBx-XF0RYR1YVpXlx_rCV0WN1znm6WbSdl4A341FXZo=.f5179194-335e-4aa3-ba02-875e9dbb2da0@github.com>
References: <NBx-XF0RYR1YVpXlx_rCV0WN1znm6WbSdl4A341FXZo=.f5179194-335e-4aa3-ba02-875e9dbb2da0@github.com>
Message-ID: <DEop1tefqtsePcztIEfpojFKUsNmE1Vg31Hoffmn990=.59c0908e-1d4d-4200-bbd4-4def869331d2@github.com>

On Thu, 19 Aug 2021 22:36:39 GMT, William Kemper <wkemper at openjdk.org> wrote:

> The "pre-write" barrier for Generational Shenandoah was missing a bit of code to store away the original `count` of elements in the array being copied. As the array copy code decrements through the `count` it is reduced to zero. This caused the "post-write" barrier to believe we just copied an empty array and that it would be safe to skip card marking. This change preserves the original `count` in the prologue and restores it in the epilogue.

This pull request has now been integrated.

Changeset: 9f0f23b7
Author:    William Kemper <wkemper at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/9f0f23b719fd90387c4e735ced5b825c4d56ff92
Stats:     33 lines in 1 file changed: 26 ins; 6 del; 1 mod

Preserve and restore original element count for card table barrier

Reviewed-by: rkennke

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

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

From ayang at openjdk.java.net  Mon Aug 23 08:57:01 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 23 Aug 2021 08:57:01 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <mTQrAQLbwaof6-BFlIvNDgUQ30QPdSN3CVobE0iDQJw=.052bc1ae-75fd-4115-831c-def7a02acf31@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

More renaming because of new code from master branch.

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

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

From ayang at openjdk.java.net  Mon Aug 23 08:56:59 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 23 Aug 2021 08:56:59 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String [v2]
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

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

 - more rename
 - Merge branch 'master' into inline
 - inline

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5201/files
  - new: https://git.openjdk.java.net/jdk/pull/5201/files/883cc213..84b218a1

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

  Stats: 721 lines in 34 files changed: 581 ins; 73 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5201.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5201/head:pull/5201

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

From redestad at openjdk.java.net  Mon Aug 23 09:57:32 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 23 Aug 2021 09:57:32 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String [v2]
In-Reply-To: <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
Message-ID: <FafGw1a9CaLjZMUNcxm3g1fZ0h5bT8X1AEl0jGHwdfY=.ed402447-3145-443a-9e47-206de4ceee73@github.com>

On Mon, 23 Aug 2021 08:56:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of merging `is_instance` and `is_instance_inlined`.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - more rename
>  - Merge branch 'master' into inline
>  - inline

Marked as reviewed by redestad (Reviewer).

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

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

From coleenp at openjdk.java.net  Mon Aug 23 12:17:33 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Mon, 23 Aug 2021 12:17:33 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String [v2]
In-Reply-To: <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
Message-ID: <haiYwcwzzzPZNb88Xd_j6fiWUiCXW6OOOZMAm9G0DR8=.a711b7e1-6314-4f76-9f24-72f13f7ddeb4@github.com>

On Mon, 23 Aug 2021 08:56:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of merging `is_instance` and `is_instance_inlined`.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - more rename
>  - Merge branch 'master' into inline
>  - inline

Ok.

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

Marked as reviewed by coleenp (Reviewer).

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

From ayang at openjdk.java.net  Mon Aug 23 14:04:35 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 23 Aug 2021 14:04:35 GMT
Subject: RFR: 8272778: Consolidate is_instance and is_instance_inlined in
 java_lang_String [v2]
In-Reply-To: <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
 <7Ad-ey2I75iDXYQbxxeOlV4jpBmfJ07kOuc5oPFp70Y=.6075d8d0-6591-463d-a546-a40375ac9e30@github.com>
Message-ID: <lOW5QtSUTgNJbdBsI4mJq0G68t7Jsj76_0TYE-trD8A=.19173f4b-63f1-44f9-9e71-d60a1c696096@github.com>

On Mon, 23 Aug 2021 08:56:59 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> Simple change of merging `is_instance` and `is_instance_inlined`.
>> 
>> Test: build
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - more rename
>  - Merge branch 'master' into inline
>  - inline

Thank you for the review.

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

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

From ayang at openjdk.java.net  Mon Aug 23 14:04:36 2021
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Mon, 23 Aug 2021 14:04:36 GMT
Subject: Integrated: 8272778: Consolidate is_instance and is_instance_inlined
 in java_lang_String
In-Reply-To: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
References: <E8yXoLSLv2_PKiOyFx_5NP4pmkHJMdorWOdVifpxCws=.3260b12a-f86a-4cca-8325-f20b866787fc@github.com>
Message-ID: <5YN5gtbgZuu0Es0_0EMWUtYZpxTuRpLBbsw-9T-CTuI=.ef2547fa-98c5-416d-9942-ae22933df8e7@github.com>

On Fri, 20 Aug 2021 13:31:02 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> Simple change of merging `is_instance` and `is_instance_inlined`.
> 
> Test: build

This pull request has now been integrated.

Changeset: 594e5161
Author:    Albert Mingkun Yang <ayang at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/594e5161b48382d61509b4969bc8f52c3c076452
Stats:     16 lines in 11 files changed: 0 ins; 4 del; 12 mod

8272778: Consolidate is_instance and is_instance_inlined in java_lang_String

Reviewed-by: coleenp, redestad

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

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

From shade at openjdk.java.net  Wed Aug 25 12:10:24 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Aug 2021 12:10:24 GMT
Subject: RFR: 8267188: gc/stringdedup/TestStringDeduplicationInterned.java
 fails with Shenandoah
In-Reply-To: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
References: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
Message-ID: <KgJ4Qv2CBWo9gtyMAP4la180ql5xZaOuH0ajpo8BREM=.39f688d3-cbef-4618-8d42-16882e851e10@github.com>

On Tue, 17 Aug 2021 18:32:54 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah currently enqueues deduplication candidates when marks object gray.
> 
> However, it can not do so when it scans roots, as it can potentially result lock rank inversion between stack watermark lock and dedup request buffer lock.
> 
> As the result, it can not enqueue as many as candidates as it should be able to, I believe JDK-8271834 is due to the same problem. I purpose we switch to enqueue candidates when we mark object black.
> 
> We are still not able to enqueue all candidates, only when they have displaced headers or have monitor inflating in progress. Upstream is working on removing displaced headers, we should revisit the logic afterward, or we can choose to deduplicate all string regardless their ages.
> 
> 
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with -XX:+UseShenandoahGC and -XX:+UseStringDeduplication

Looks fine, modulo a few suggestions.

src/hotspot/share/gc/shenandoah/shenandoahMark.cpp line 120:

> 118: }
> 119: 
> 120: template <class T, bool CANCELLABLE,StringDedupMode STRING_DEDUP>

Suggestion:

template <class T, bool CANCELLABLE, StringDedupMode STRING_DEDUP>

src/hotspot/share/gc/shenandoah/shenandoahMark.inline.hpp line 71:

> 69:   if (task->is_not_chunked()) {
> 70:     if (obj->is_instance()) {
> 71:       dedup_string<STRING_DEDUP>(obj, req);

I do wonder if it is faster to _first_ let the closure process the outbound references, and then do dedup for the object? This way, parallel GC workers can do work while we are calling `dedup_string` here. This is one of the reasons why old code did dedup check after the queue push. In other words, move this call at the end of this block.

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

Marked as reviewed by shade (Reviewer).

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

From zgu at openjdk.java.net  Wed Aug 25 12:15:53 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 25 Aug 2021 12:15:53 GMT
Subject: RFR: 8267188: gc/stringdedup/TestStringDeduplicationInterned.java
 fails with Shenandoah [v2]
In-Reply-To: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
References: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
Message-ID: <iX9sEW8JXHgjwDuGqZTwEYze0MHXPxEg7P5s_dMkz40=.953e7d2f-47b0-47b7-8b7b-a63bef26b5a0@github.com>

> Shenandoah currently enqueues deduplication candidates when marks object gray.
> 
> However, it can not do so when it scans roots, as it can potentially result lock rank inversion between stack watermark lock and dedup request buffer lock.
> 
> As the result, it can not enqueue as many as candidates as it should be able to, I believe JDK-8271834 is due to the same problem. I purpose we switch to enqueue candidates when we mark object black.
> 
> We are still not able to enqueue all candidates, only when they have displaced headers or have monitor inflating in progress. Upstream is working on removing displaced headers, we should revisit the logic afterward, or we can choose to deduplicate all string regardless their ages.
> 
> 
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with -XX:+UseShenandoahGC and -XX:+UseStringDeduplication

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

  Aleksey's comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/5151/files
  - new: https://git.openjdk.java.net/jdk/pull/5151/files/98eedbd5..18e59bd5

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

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

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

From zgu at openjdk.java.net  Wed Aug 25 17:43:41 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 25 Aug 2021 17:43:41 GMT
Subject: RFR: 8267188: gc/stringdedup/TestStringDeduplicationInterned.java
 fails with Shenandoah [v3]
In-Reply-To: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
References: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
Message-ID: <3HCBjEN78flEzjy9JCR9Stq7JNgd6v9kbAKjihLUgds=.6a723cd3-8582-484d-93a5-d9b3bb0db77b@github.com>

> Shenandoah currently enqueues deduplication candidates when marks object gray.
> 
> However, it can not do so when it scans roots, as it can potentially result lock rank inversion between stack watermark lock and dedup request buffer lock.
> 
> As the result, it can not enqueue as many as candidates as it should be able to, I believe JDK-8271834 is due to the same problem. I purpose we switch to enqueue candidates when we mark object black.
> 
> We are still not able to enqueue all candidates, only when they have displaced headers or have monitor inflating in progress. Upstream is working on removing displaced headers, we should revisit the logic afterward, or we can choose to deduplicate all string regardless their ages.
> 
> 
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with -XX:+UseShenandoahGC and -XX:+UseStringDeduplication

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

 - Merge branch 'JDK-8267188-string-intern' of github.com:zhengyu123/jdk into JDK-8267188-string-intern
 - Aleksey's comments
 - Merge and fix conflicts
 - fix format
 - v0
 - Merge branch 'master' into JDK-8267188-string-intern
 - v0

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

Changes: https://git.openjdk.java.net/jdk/pull/5151/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=5151&range=02
  Stats: 112 lines in 8 files changed: 35 ins; 28 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/5151.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/5151/head:pull/5151

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

From shade at redhat.com  Wed Aug 25 19:51:29 2021
From: shade at redhat.com (Aleksey Shipilev)
Date: Wed, 25 Aug 2021 21:51:29 +0200
Subject: JVM Crashes after switching from G1GC to Shenandoah
In-Reply-To: <4c4fb2f9-df12-3c90-0b3c-4598cb4dba05@redhat.com>
References: <CAAJwpyYOiq_KkcX-fn8wj693TYpsXXbM07Upk_72qdcngs1gDw@mail.gmail.com>
 <fe350828-d349-c904-2679-8227005a4ecc@redhat.com>
 <4c4fb2f9-df12-3c90-0b3c-4598cb4dba05@redhat.com>
Message-ID: <c15093f7-e486-9219-2c16-c62160d39468@redhat.com>

On 8/19/21 1:51 PM, Aleksey Shipilev wrote:
> Better yet:
>     https://builds.shipilev.net/openjdk-jdk11-dev/

These builds should now include all known AArch64 bugfixes:
   8272909: Shenandoah: streamline post-LRB CAS barrier (aarch64)
   8272896: AArch64: gc/shenandoah/TestVerifyJCStress.java fails intermittently with C1
   8252857: AArch64: Shenandoah C1 CAS is not sequentially consistent

Please try them and shout if they still do not work.

-- 
Thanks,
-Aleksey


From zgu at openjdk.java.net  Wed Aug 25 20:19:29 2021
From: zgu at openjdk.java.net (Zhengyu Gu)
Date: Wed, 25 Aug 2021 20:19:29 GMT
Subject: Integrated: 8267188:
 gc/stringdedup/TestStringDeduplicationInterned.java fails with Shenandoah
In-Reply-To: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
References: <RBMITWpD-3PxUjawMR_06Ts12LuAqDxZnaaDjm6F0Vo=.83d90f6a-f772-4cc1-803a-3e14d79f2d4b@github.com>
Message-ID: <Intgdburu4N5bq1FuPqEXx-EpyIfwvs7-hM4K9oHUCk=.1d60c4c0-7672-46d4-b96e-7da02470a797@github.com>

On Tue, 17 Aug 2021 18:32:54 GMT, Zhengyu Gu <zgu at openjdk.org> wrote:

> Shenandoah currently enqueues deduplication candidates when marks object gray.
> 
> However, it can not do so when it scans roots, as it can potentially result lock rank inversion between stack watermark lock and dedup request buffer lock.
> 
> As the result, it can not enqueue as many as candidates as it should be able to, I believe JDK-8271834 is due to the same problem. I purpose we switch to enqueue candidates when we mark object black.
> 
> We are still not able to enqueue all candidates, only when they have displaced headers or have monitor inflating in progress. Upstream is working on removing displaced headers, we should revisit the logic afterward, or we can choose to deduplicate all string regardless their ages.
> 
> 
> 
> Test:
> - [x] hotspot_gc_shenandoah
> - [x] tier1 with -XX:+UseShenandoahGC and -XX:+UseStringDeduplication

This pull request has now been integrated.

Changeset: 7212561d
Author:    Zhengyu Gu <zgu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7212561dd1ec65d7f31792959f0eaaab6229eaf4
Stats:     112 lines in 8 files changed: 35 ins; 28 del; 49 mod

8267188: gc/stringdedup/TestStringDeduplicationInterned.java fails with Shenandoah

Reviewed-by: rkennke, shade

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

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

From kdnilsen at openjdk.java.net  Fri Aug 27 14:51:09 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 27 Aug 2021 14:51:09 GMT
Subject: RFR: Add generational full gc support
Message-ID: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>

In situations when Generational Shenandoah triggers full-gc, we now allow full gc to run.  The implementation of full gc preserves the distinction between young and old memory regions because premature promotion of young objects into old regions may result in inefficient subsequent old-gc efforts.

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

Commit messages:
 - Fix white space
 - Merge branch 'shenandoah' into full-gc-with-generations
 - Preserve and restore original element count for card table barrier
 - Address reviewer feedback
 - Merge branch 'shenandoah' into full-gc-with-generations
 - Respond to reviewer feedback
 - Fix two errors in Full GC support
 - Instrumentation to help debug
 - Fix some bugs in Full GC
 - Fixup verification at mark and add instrumentation
 - ... and 6 more: https://git.openjdk.java.net/shenandoah/compare/9f0f23b7...c93f9599

Changes: https://git.openjdk.java.net/shenandoah/pull/61/files
 Webrev: https://webrevs.openjdk.java.net/?repo=shenandoah&pr=61&range=00
  Stats: 857 lines in 22 files changed: 656 ins; 155 del; 46 mod
  Patch: https://git.openjdk.java.net/shenandoah/pull/61.diff
  Fetch: git fetch https://git.openjdk.java.net/shenandoah pull/61/head:pull/61

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

From rkennke at openjdk.java.net  Fri Aug 27 15:39:04 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 27 Aug 2021 15:39:04 GMT
Subject: RFR: Add generational full gc support
In-Reply-To: <N2Q1yX7uRXXbl3OirWJdD_rNQdiB2yRCI1FIeimN8_A=.7eb35338-2f32-425a-b72f-dca992510157@github.com>
References: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
 <N2Q1yX7uRXXbl3OirWJdD_rNQdiB2yRCI1FIeimN8_A=.7eb35338-2f32-425a-b72f-dca992510157@github.com>
Message-ID: <gYDuN6TAy7IDuPcfbMuySUzz807xqW687m88Z_VKbT4=.d8469198-0f01-442e-8c21-120cd1f7c9af@github.com>

On Fri, 27 Aug 2021 15:29:41 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In situations when Generational Shenandoah triggers full-gc, we now allow full gc to run.  The implementation of full gc preserves the distinction between young and old memory regions because premature promotion of young objects into old regions may result in inefficient subsequent old-gc efforts.
>
> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 221:
> 
>> 219:       // that the PLAB be disabled for all future purposes.  We may want to introduce a new service to make the
>> 220:       // PLABs parsable while still allowing the PLAB to serve future allocation requests that arise during the
>> 221:       // next evacuation pass.
> 
> If I understand correctly, we already have this in ShenandoahHeap::ensure_parsability(bool retire_tlabs)

Oh wait, probably not available for PLABs.

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

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

From rkennke at openjdk.java.net  Fri Aug 27 15:39:01 2021
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Fri, 27 Aug 2021 15:39:01 GMT
Subject: RFR: Add generational full gc support
In-Reply-To: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
References: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
Message-ID: <N2Q1yX7uRXXbl3OirWJdD_rNQdiB2yRCI1FIeimN8_A=.7eb35338-2f32-425a-b72f-dca992510157@github.com>

On Fri, 27 Aug 2021 13:31:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> In situations when Generational Shenandoah triggers full-gc, we now allow full gc to run.  The implementation of full gc preserves the distinction between young and old memory regions because premature promotion of young objects into old regions may result in inefficient subsequent old-gc efforts.

Looks ok to me, only small comments/questions. (Notice I am on PTO next 2 weeks until Sept 13th.)

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

> 219:       // that the PLAB be disabled for all future purposes.  We may want to introduce a new service to make the
> 220:       // PLABs parsable while still allowing the PLAB to serve future allocation requests that arise during the
> 221:       // next evacuation pass.

If I understand correctly, we already have this in ShenandoahHeap::ensure_parsability(bool retire_tlabs)

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

> 48: #include "utilities/powerOfTwo.hpp"
> 49: 
> 50: #undef KELVIN_VERBOSE

Is this a left-over?

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

> 859:            p2i(top()), p2i(ctx->top_at_mark_start(this)), p2i(this->get_update_watermark()), p2i(ctx->top_bitmap(this)));
> 860:     fflush(stdout);
> 861: #endif

Aha, here it comes. Maybe make this a proper log_trace() or log_debug() ?

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

Marked as reviewed by rkennke (Lead).

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

From kdnilsen at openjdk.java.net  Fri Aug 27 17:20:59 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 27 Aug 2021 17:20:59 GMT
Subject: RFR: Add generational full gc support
In-Reply-To: <gYDuN6TAy7IDuPcfbMuySUzz807xqW687m88Z_VKbT4=.d8469198-0f01-442e-8c21-120cd1f7c9af@github.com>
References: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
 <N2Q1yX7uRXXbl3OirWJdD_rNQdiB2yRCI1FIeimN8_A=.7eb35338-2f32-425a-b72f-dca992510157@github.com>
 <gYDuN6TAy7IDuPcfbMuySUzz807xqW687m88Z_VKbT4=.d8469198-0f01-442e-8c21-120cd1f7c9af@github.com>
Message-ID: <LXajxbX1MEhAaJaKc1_w9mMHq1F1XJR8Vzb0bTILx-0=.68e1e769-2476-4e0d-a7df-a935721b9612@github.com>

On Fri, 27 Aug 2021 15:31:36 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> src/hotspot/share/gc/shenandoah/shenandoahFreeSet.cpp line 221:
>> 
>>> 219:       // that the PLAB be disabled for all future purposes.  We may want to introduce a new service to make the
>>> 220:       // PLABs parsable while still allowing the PLAB to serve future allocation requests that arise during the
>>> 221:       // next evacuation pass.
>> 
>> If I understand correctly, we already have this in ShenandoahHeap::ensure_parsability(bool retire_tlabs)
>
> Oh wait, probably not available for PLABs.

We'll probably come back later and do some "improvement" to this code.  Thanks.

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

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

From kdnilsen at openjdk.java.net  Fri Aug 27 17:21:03 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 27 Aug 2021 17:21:03 GMT
Subject: RFR: Add generational full gc support
In-Reply-To: <N2Q1yX7uRXXbl3OirWJdD_rNQdiB2yRCI1FIeimN8_A=.7eb35338-2f32-425a-b72f-dca992510157@github.com>
References: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
 <N2Q1yX7uRXXbl3OirWJdD_rNQdiB2yRCI1FIeimN8_A=.7eb35338-2f32-425a-b72f-dca992510157@github.com>
Message-ID: <5JLH6ZrcJxzrwpuBbeSpoL4KO1Y_BGlx5LKLzifOumA=.a48b6d2d-0c66-4813-84e6-e0dd1abb879a@github.com>

On Fri, 27 Aug 2021 15:32:54 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In situations when Generational Shenandoah triggers full-gc, we now allow full gc to run.  The implementation of full gc preserves the distinction between young and old memory regions because premature promotion of young objects into old regions may result in inefficient subsequent old-gc efforts.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 50:
> 
>> 48: #include "utilities/powerOfTwo.hpp"
>> 49: 
>> 50: #undef KELVIN_VERBOSE
> 
> Is this a left-over?

Sorry.  I had meant to remove all that code.  Thanks for catching it.

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

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

From kdnilsen at openjdk.java.net  Fri Aug 27 17:26:43 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 27 Aug 2021 17:26:43 GMT
Subject: RFR: Add generational full gc support
In-Reply-To: <N2Q1yX7uRXXbl3OirWJdD_rNQdiB2yRCI1FIeimN8_A=.7eb35338-2f32-425a-b72f-dca992510157@github.com>
References: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
 <N2Q1yX7uRXXbl3OirWJdD_rNQdiB2yRCI1FIeimN8_A=.7eb35338-2f32-425a-b72f-dca992510157@github.com>
Message-ID: <lBrH7tiHjZ8KprU9ogfuJWG0aCNQWaKfGZrCQCVnOxM=.72a87ecb-053e-49a2-a726-528da018b7d7@github.com>

On Fri, 27 Aug 2021 15:33:45 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> In situations when Generational Shenandoah triggers full-gc, we now allow full gc to run.  The implementation of full gc preserves the distinction between young and old memory regions because premature promotion of young objects into old regions may result in inefficient subsequent old-gc efforts.
>
> src/hotspot/share/gc/shenandoah/shenandoahHeapRegion.cpp line 861:
> 
>> 859:            p2i(top()), p2i(ctx->top_at_mark_start(this)), p2i(this->get_update_watermark()), p2i(ctx->top_bitmap(this)));
>> 860:     fflush(stdout);
>> 861: #endif
> 
> Aha, here it comes. Maybe make this a proper log_trace() or log_debug() ?

Removed.

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

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

From kdnilsen at openjdk.java.net  Fri Aug 27 17:34:18 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 27 Aug 2021 17:34:18 GMT
Subject: RFR: Add generational full gc support [v2]
In-Reply-To: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
References: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
Message-ID: <N6Dpoj3PB6sFbVPx-U0mwOZZSpFxe-ndr5PC0poVIPQ=.b7545f6a-0b19-4352-82d0-c566aa652972@github.com>

> In situations when Generational Shenandoah triggers full-gc, we now allow full gc to run.  The implementation of full gc preserves the distinction between young and old memory regions because premature promotion of young objects into old regions may result in inefficient subsequent old-gc efforts.

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

  Remove extraneous debugging infrastructure

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

Changes:
  - all: https://git.openjdk.java.net/shenandoah/pull/61/files
  - new: https://git.openjdk.java.net/shenandoah/pull/61/files/c93f9599..ac520ad8

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

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

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

From kdnilsen at openjdk.java.net  Fri Aug 27 17:49:58 2021
From: kdnilsen at openjdk.java.net (Kelvin Nilsen)
Date: Fri, 27 Aug 2021 17:49:58 GMT
Subject: Integrated: Add generational full gc support
In-Reply-To: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
References: <ErCdEO0ptSieraE_D6vxWesB2LclDL_co9iVpVktdjY=.04ed60cc-7473-4978-af42-d8e98dfb52c9@github.com>
Message-ID: <YY-10JXlXKsYlROHsCmQQUZuTmDsz8zMzgN593hGh4E=.68215c8c-62e4-431d-8435-7d892f439db0@github.com>

On Fri, 27 Aug 2021 13:31:12 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

> In situations when Generational Shenandoah triggers full-gc, we now allow full gc to run.  The implementation of full gc preserves the distinction between young and old memory regions because premature promotion of young objects into old regions may result in inefficient subsequent old-gc efforts.

This pull request has now been integrated.

Changeset: 4d100619
Author:    Kelvin Nilsen <kdnilsen at openjdk.org>
URL:       https://git.openjdk.java.net/shenandoah/commit/4d100619150c5305bce85b578f01bf5068a4f23c
Stats:     843 lines in 22 files changed: 642 ins; 155 del; 46 mod

Add generational full gc support

Reviewed-by: rkennke

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

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

From github.com+39413832+weixlu at openjdk.java.net  Mon Aug 30 11:17:37 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Mon, 30 Aug 2021 11:17:37 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
Message-ID: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>

Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.

baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041

optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579

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

Commit messages:
 - Shenandoah: Adopt relaxed order for update oop

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

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

From shade at openjdk.java.net  Mon Aug 30 11:28:25 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 30 Aug 2021 11:28:25 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
Message-ID: <CrafMMkAz6_8035SgDJOyBJE6yk92Ln4zUL4UJrDpSI=.33985f70-0799-4772-bec3-91b8fc248736@github.com>

On Mon, 30 Aug 2021 11:08:22 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
> This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.
> 
> baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
> baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
> baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041
> 
> optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
> optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
> optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579

This conflicts with #2496, which would use "release" when updating the forwardee. I remember trying this, and "relaxed" was not sufficient, with observable failures (IIRC, in `tier1` with `-XX:+UseShenandoahGC`).

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

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

From shade at openjdk.java.net  Mon Aug 30 12:04:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 30 Aug 2021 12:04:38 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
Message-ID: <JyVULWVQ1cNlnYz7lrWeCmFshv2KG3BB1V7VjjpD4Go=.740fc861-908b-4dbe-bad2-629d8515dd8e@github.com>

On Mon, 30 Aug 2021 11:08:22 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
> This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.
> 
> baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
> baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
> baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041
> 
> optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
> optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
> optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579

Actually, let me think about it a bit more. Maybe if we do `OrderAccess::release()` in fwdptr installation (thus still relaxing it from `conservative`), we can use `relaxed` during concurrent heap updates.

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

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

From shade at openjdk.java.net  Mon Aug 30 16:25:26 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 30 Aug 2021 16:25:26 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
Message-ID: <BvMIXF0tpa6lq4MKkpcJrf4_vGT-oplRpOYGbaqwl7M=.5c70a93a-fdac-4c18-8d0b-54f72b4130cf@github.com>

On Mon, 30 Aug 2021 11:08:22 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
> This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.
> 
> baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
> baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
> baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041
> 
> optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
> optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
> optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579

I believe this is fine, yet I am checking other places and running concurrency-heavy tests. The comment deserves to be updated as well, like this: https://cr.openjdk.java.net/~shade/8273127/update-comments.patch -- what do you think?

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

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

From github.com+39413832+weixlu at openjdk.java.net  Tue Aug 31 07:09:26 2021
From: github.com+39413832+weixlu at openjdk.java.net (Xiaowei Lu)
Date: Tue, 31 Aug 2021 07:09:26 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <BvMIXF0tpa6lq4MKkpcJrf4_vGT-oplRpOYGbaqwl7M=.5c70a93a-fdac-4c18-8d0b-54f72b4130cf@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
 <BvMIXF0tpa6lq4MKkpcJrf4_vGT-oplRpOYGbaqwl7M=.5c70a93a-fdac-4c18-8d0b-54f72b4130cf@github.com>
Message-ID: <PWClDSZoKQMFvRZfd9gcm1SjTkLpFFXy_9A0QSTIoEg=.273ae8eb-cff7-4189-be33-f294d7300589@github.com>

On Mon, 30 Aug 2021 16:22:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
>> This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.
>> 
>> baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
>> baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
>> baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041
>> 
>> optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
>> optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
>> optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579
>
> I believe this is fine, yet I am checking other places and running concurrency-heavy tests. The comment deserves to be updated as well, like this: https://cr.openjdk.java.net/~shade/8273127/update-comments.patch -- what do you think?

@shipilev Thanks for your suggestions. Yes, using memory order release in forwardee installation is reasonable and brings visibly performance improvement. If forwardee installation is ?release?, it is incorrect to use ?relaxed? in updating reference, since updating reference is possible to reorder before object copy. To fix this, I agree to your suggestion that we can use OrderAccess::release (unbounded release) to replace Atomic::cmpxchg release (bounded release). Unbounded release is enough to ensure correctness in ?relaxed? updating reference, but it may result in a little bit side effect in performance, compared to bounded release. 
Besides, could we use memory_order_acq_rel in Atomic::cmpxchg of fwdptr installation? I guess this is also enough for ?relaxed? updating reference, and it is more relax than memory_order_conservative by one membar on AArch64.
In short, we can 
1. use OrderAccess::release in forwardee installation and memory_order_relaxed in updating reference.
2. use memory_order_acq_rel in forwardee installation and memory_order_relaxed in updating reference.

I plan to run specjbb on both cases and see which one gives more performance boost. Looking forward to your suggestions!

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

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

From shade at openjdk.java.net  Tue Aug 31 13:30:30 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 Aug 2021 13:30:30 GMT
Subject: RFR: 8273127: Shenandoah: Adopt relaxed order for update oop
In-Reply-To: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
References: <r1RRF7Wuxvex0Guo3-ksZsi2pRegGEKek_6WwFkdGlc=.897e15bc-16f5-43da-a0fa-655b315abb7d@github.com>
Message-ID: <mKtnUD-AoIumpGUuKeXhmD55jKF1SlIWm32TI2XLfeA=.ec9caf18-66ef-41d9-a760-98e5645ad0dc@github.com>

On Mon, 30 Aug 2021 11:08:22 GMT, Xiaowei Lu <github.com+39413832+weixlu at openjdk.org> wrote:

> Shenandoah evacuates object and then updates the reference in load barriers. Currently, memory order release is adopted in atomic_update_oop(), and we propose to use relaxed instead. Since memory order conservative is adopted in updating forwardee, this membar ensures that object copy is finished before updating the reference. In the scenario when a thread reads self-healed address from forwardee, relaxed is also fine due to the data dependency of the self-healed address.
> This relaxation of memory order brings us some performance improvement. We have run specjbb2015 on AArch64. Critical-JOPS increases by 3% while max-JOPS maintains almost the same.
> 
> baseline_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107513, max-jOPS = 102968, critical-jOPS = 37913
> baseline_2:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 106769, max-jOPS = 101742, critical-jOPS = 37151
> baseline_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 110118, max-jOPS = 101742, critical-jOPS = 37041
> 
> optimized_1:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 111708, max-jOPS = 101742, critical-jOPS = 37687
> optimized_2:RUN RESULT: hbIR (max attempted) = 147077, hbIR (settled) = 122581, max-jOPS = 104425, critical-jOPS = 39663
> optimized_3:RUN RESULT: hbIR (max attempted) = 122581, hbIR (settled) = 107286, max-jOPS = 102968, critical-jOPS = 38579

I think forwardee installation is better done with `acq_rel`, given that two GC threads may try to install it, and the failing thread should consume/acquire the other forwardee. Not sure the `OrderAccess::release` provides the same semantics. I have updated #2496 with more discussion and implementation.

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

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

From shade at openjdk.java.net  Tue Aug 31 19:37:23 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 Aug 2021 19:37:23 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v8]
In-Reply-To: <_IqJ7u4Vk7jF8E--2RzWfdnxYXDQr86TIsxA7sh_3WI=.4d2c4cd9-63c8-4921-b5a1-e77d66c10325@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
 <_IqJ7u4Vk7jF8E--2RzWfdnxYXDQr86TIsxA7sh_3WI=.4d2c4cd9-63c8-4921-b5a1-e77d66c10325@github.com>
Message-ID: <nSw6WOsSd_5D4f0CMKBF-zkuLQhJfHcN3OyQIJHakv8=.035e9c8e-1773-482b-8738-d80f2605a1c5@github.com>

On Mon, 5 Jul 2021 16:23:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.
>> 
>> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough.
>> 
>> The reader side is much more interesting, because we generally want "consume", but it is not available. We can do "acquire", but it regresses performance all too much. The close inspection of the code reveals we need "acquire" on many paths, but not on the most critical one: heap updates. This must explain why current weaker reader side was never seen to fail, and this also opens a way to get `acquire`-in-lieu-of-`consume` without the observable performance penalty.
>> 
>> The relaxation in forwardee installation improves concurrent evacuation quite visibly. See for example GC cycle times with SPECjvm2008, Compiler.sunflow on AArch64:
>> 
>> Before:
>> 
>> 
>> [info][gc,stats] Concurrent Evacuation          =    3.421 s (a =    21247 us) (n =   161)
>> [info][gc,stats] Concurrent Evacuation          =    3.584 s (a =    21080 us) (n =   170)
>> [info][gc,stats] Concurrent Evacuation          =    3.226 s (a =    21088 us) (n =   153)
>> [info][gc,stats] Concurrent Evacuation          =    3.270 s (a =    20827 us) (n =   157)
>> [info][gc,stats] Concurrent Evacuation          =    3.339 s (a =    20742 us) (n =   161)
>> 
>> 
>> After:
>> 
>> [info][gc,stats] Concurrent Evacuation          =    3.109 s (a =    18617 us) (n =   167)
>> [info][gc,stats] Concurrent Evacuation          =    3.027 s (a =    18918 us) (n =   160) 
>> [info][gc,stats] Concurrent Evacuation          =    2.862 s (a =    17669 us) (n =   162) 
>> [info][gc,stats] Concurrent Evacuation          =    2.858 s (a =    17425 us) (n =   164) 
>> [info][gc,stats] Concurrent Evacuation          =    2.883 s (a =    17685 us) (n =   163) 
>> 
>> 
>> Additional testing:
>>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>>  - [ ] Linux x86_64 `tier1` with Shenandoah
>>  - [ ] Linux AArch64 `tier1` with Shenandoah
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add TODO

More work: leave `acquire`-in-lieu-of-`consume` in, and special case the heap update paths to dodge the performance penalty of doing so. Seems to work on x86_64 and AArch64.

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

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

From shade at openjdk.java.net  Tue Aug 31 19:37:00 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 31 Aug 2021 19:37:00 GMT
Subject: RFR: 8261492: Shenandoah: reconsider forwardee accesses memory
 ordering [v9]
In-Reply-To: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
References: <eP3bMKbgFS1MJ1MO2DUcTom0eNJT8zszs4A-PJXIgsI=.3cead947-d093-466a-9cfd-0c312eec592a@github.com>
Message-ID: <iscV74G2qQwcZv_WDsO6BRG3F34wJkgiD9Am4dGMED8=.e70ca24b-af87-4f76-aeb6-e2e79818fe6f@github.com>

> Shenandoah carries forwardee information in object's mark word. Installing the new mark word is effectively "releasing" the object copy, and reading from the new mark word is "acquiring" that object copy.
> 
> For the forwardee update side, Hotspot's default for atomic operations is memory_order_conservative, which emits two-way memory fences around the CASes at least on AArch64 and PPC64. This seems to be excessive for Shenandoah forwardee updates, and "release" is enough.
> 
> The reader side is much more interesting, because we generally want "consume", but it is not available. We can do "acquire", but it regresses performance all too much. The close inspection of the code reveals we need "acquire" on many paths, but not on the most critical one: heap updates. This must explain why current weaker reader side was never seen to fail, and this also opens a way to get `acquire`-in-lieu-of-`consume` without the observable performance penalty.
> 
> The relaxation in forwardee installation improves concurrent evacuation quite visibly. See for example GC cycle times with SPECjvm2008, Compiler.sunflow on AArch64:
> 
> Before:
> 
> 
> [info][gc,stats] Concurrent Evacuation          =    3.421 s (a =    21247 us) (n =   161)
> [info][gc,stats] Concurrent Evacuation          =    3.584 s (a =    21080 us) (n =   170)
> [info][gc,stats] Concurrent Evacuation          =    3.226 s (a =    21088 us) (n =   153)
> [info][gc,stats] Concurrent Evacuation          =    3.270 s (a =    20827 us) (n =   157)
> [info][gc,stats] Concurrent Evacuation          =    3.339 s (a =    20742 us) (n =   161)
> 
> 
> After:
> 
> [info][gc,stats] Concurrent Evacuation          =    3.109 s (a =    18617 us) (n =   167)
> [info][gc,stats] Concurrent Evacuation          =    3.027 s (a =    18918 us) (n =   160) 
> [info][gc,stats] Concurrent Evacuation          =    2.862 s (a =    17669 us) (n =   162) 
> [info][gc,stats] Concurrent Evacuation          =    2.858 s (a =    17425 us) (n =   164) 
> [info][gc,stats] Concurrent Evacuation          =    2.883 s (a =    17685 us) (n =   163) 
> 
> 
> Additional testing:
>  - [x] Linux x86_64 `hotspot_gc_shenandoah`
>  - [x] Linux AArch64 `hotspot_gc_shenandoah`
>  - [ ] Linux x86_64 `tier1` with Shenandoah
>  - [ ] Linux AArch64 `tier1` with Shenandoah

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

 - Doing acquires on most paths, and relaxed on the path that matters: heap update
 - Even more discussion
 - Additional discussion and corner cases
 - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
 - Add TODO
 - "acquire" is too slow on aarch64, and does not seem neccessary anyway
 - Merge branch 'master' into JDK-8261492-shenandoah-forwardee-memord
 - 8261492: Shenandoah: reconsider forwardee accesses memory ordering

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

Changes: https://git.openjdk.java.net/jdk/pull/2496/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2496&range=08
  Stats: 174 lines in 13 files changed: 104 ins; 30 del; 40 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2496.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2496/head:pull/2496

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